[Tutor] Multiple front-ends in project

[dn]

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