[Tutor] Multiple front-ends in project
dn
PythonList at DancesWithMice.info
Sun Jun 25 20:33:21 EDT 2023
On 24/06/2023 12.50, Alan Gauld via Tutor wrote:
> On 23/06/2023 18:11, trent shipley wrote:
>> I have written the simple core logic for a dice rolling program. It is In
>> ./app/core. I am planning to add more complex helper classes in
>> separate files to do more complex things like rolling different kinds of
>> dice in one throw, or exploding dice.
>>
>> I plan four interfaces, two CLI, and two GUI.
Further to @Alan's analysis, (although not being aware of your level of
ComSc/DataSc expertise) I regularly remind/put the 'circles' diagram in
front of trainees
(https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg)
This illustrates that the code fulfilling the purposes of the outer
'circles' needs to know (a limited amount of) what's going-on 'inside',
but the inner-circle(s) don't need to know where data is coming-from or
going-to! (paralleling @Alan's "MVC" ideas of 'separation')
If interested, please see-also theories such as "Separation of Concerns"
and the "SOLID Principles", specifically the "Single Responsibility
Principle". In short, if the description of the work performed by a
single unit of code (eg function, class, ...) features the word "and",
then that code may contain a 'gotcha' for exercises such as this!
Accordingly, the code which actually includes a call to the
random-library does not need to know if the request has come from a user
using a GUI or the CLI. Yes, other 'outer' logic can take care of that -
and ensure that a request from the GUI will return the results in
similar fashion rather than printing to the 'command-line'.
Considering the 'center' in a bit more detail: what data does the 'core
logic' require from its "External Interface" (regardless of which one)?
This may include:
- how many sides to the die/dice
- how many dice
- home many rolls
...
This is the "API" (Application Programming Interface). More prosaically,
it is probably the 'signature' of one of the existing functions in the
system. (which is another way of getting rid of the high-falutin
terminology)
Once you've identified ("finalised") this, then turn your attention to
the GUI and CLI components. The 'input' part of these must be built to
be as pretty and/or as workable as is appropriate, but ultimately must
provide the information required by the (above) API/signature.
The same, in-reverse, for output...
Referring back to the diagram. The die/dice is an "entity". The number
of sides per die is a "business rule" (the 'business' (ahem) of
statistical distribution). The "Use Cases" are the varieties of
simulations you'd like the dice to be used to perform. The
Web/UI/External Interfaces encompass many of your existing
explanations/intent.
Have enjoyed considering the question. Some additional comment (FWIW):
Further to @Alan's "waffle", may I recommend the "YAGNI Principle", ie
don't 'put stuff in' until you actually receive a solid use-case for it
(in my case: I don't do things until the client has agreed to pay for
them). Just because it might be useful - or might be fun to code-up, is
not a solid reason (it *is* a reason (professional responsibility?) to
go back to the client and ask if (s)he agrees - *and* is prepared to pay
for it!). Most of the time it represents a delay to 'delivery' because
You/They Ain't Going To Need It!
Am also anticipating you will have to put in some 'rework'. Recommend
that you start with (unless you have them already) a set of tests (a
'testing framework'). This will 'prove' (in the logic/mathematical
sense) that the existing code works correctly. This is a 'stable state'.
Now, when something is 'reworked' in order to separate the components
and create the API (between External Interfaces and the Entities and Use
Cases/Controllers), the tests will continue to pass - or will fail and
thereby show that the 'new work' has introduced an error (which, one way
or the other) will need 'fixing'! It seems like more (even, unnecessary)
work up-front, but may pay greater dividends over time...
Looking forward to hearing how the project progresses...
--
Regards,
=dn
More information about the Tutor
mailing list