Architectural practical case (relationships between classes)

[Илья Фофанов]

Currently, I'm working on construction of relationships between classes.

Consider the situation.

We have a working shift. It's duration is 24 hours. A shift has many properties, for instance: IsOpened, IsOver, RevenuePerSession and so on.
Okay. The state is stored in a special device called M100. It has independent memory and it's own low-level interface of interaction.
A shift, truly, shoud be synchronized between M100 and a fiscal registrator (FR - it is a device in several countries which is used to track all financial operations and is forced and controlled by the government). Lay it down as an axiom. Okay.

It's pretty obvious that we must implement two classes which will interact with a fiscal registrator and M100.

We have a Shift class in our domain.

Where should reside OpenShift, CloseShift methods? In FR? In M100? In some kind of synchronizer only? In FR and M100 and synchronizer? I should add that occasionally (and we can't avoid that) we face FR and M100 unsynchronized and in this case we should give a user the ability to synchronize them by hands (explicitly using UI). By the way, FR has it's own independent memory store.

Ha-ha, pretty interesting task, yes?)))

Ok, let's go further.

M100 is a card reader. It can read MIFARE cards, for instance. We have card dispensers. Card dispensers can capture a card given by a user. Card dispenser capture a card abd move it to the position from which M100 can read a card through the external antenna (it has three antennas: internal antenna, external 1 and external 2. The last two antennas are placed above the place to which card dispensers move a card for reading.

The question is where should reside ReadCard method? In CardDispenser class? In M100 class? Should M100 know about card dispensers directly or indirectly?

I'm looking forward for a very interesting discussion :)

[Caio Fernando Bertoldi Paes de Andrade]

Your application example is somewhat similar to the coffee machine example Uncle Bob have in one of his videos. I highly recommend you to search for it and pay close attention, it's very insightful. ;)

Cheers,

Caio

—
Sent from Mailbox for iPhone

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Uncle Bob]

You have described all the devices, but you haven't mentioned the _problem_ you are trying to solve.  What are the business rules?  Try to abstract all the interesting devices away from that problem.  Don' let your business rules know about antennae or card readers.  

[Илья Фофанов]

Hello, Uncle Bob!
Good point! Thanks.

Trying to grasp the relationships between the core concepts of the system I came to point that almost all business logic depends on M100-device.
The overall aim is to sell tickets for suburban trains. M100 is a secure storage with cryprography keys. It stores all information about tickets been sold.
The result is that we can't print a report without it, we can't print a ticket, we can't manage the state of many system entities without it. I mean, yes, we can print without it, I mean that the pursuing of each separate goal touches M100 someway.

And, thank you, Caio Fernando Bertoldi Paes de Andrade, I'll try to analyse Bob Martin's coffee machine example.

вторник, 3 декабря 2013 г., 13:46:46 UTC+4 пользователь Uncle Bob написал: