Lydia<br />~~~~~~~~~~~~<br />I love Italy team.
Lydia<br />~~~~~~~~~~~~<br />I love Italy team.
Posted by Frank Carver:
In good O-O design, there should be no objects which just hold data, objects should be defined by their actions and collaboratons
Frank Carver wrote:
I'd like to explore the situations where you have found such objects useful. Can you give us an example situation where such an object is needed, to base a discussion around?
1. we have several POS machines with an application that holds products, customers, sales and so on. Once a week this data is refreshed/sent from/to the server via modem
Lydia<br />~~~~~~~~~~~~<br />I love Italy team.
use the power of the database to create "views" which are denormalised and more appropriate to your scheduling, but keep the algorithms themselves out in the easily-changed, easily reused, easily understood, easily tested O-O world.
Lydia<br />~~~~~~~~~~~~<br />I love Italy team.
Originally posted by Frank Carver:
I don't think software design decisions should really be driven by fear.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
Eduard Jodas wrote: - the data: Product, Sale, Credit Card, etc. They are objects without responsabilities/associations. Only hold data attributes plus getter/setter methods
Is there any particular reason why these objects can't just be one of the Map classes ? The description of the responsibilities you give sounds just like that to me. In particular I feel that your "data" classes have more similarities than differences, so they should probably share some fundammetal behaviour. All that seems to differ between them is the names and types of the data entries.
For efficiency reasons I have in my own "toolkit", what I call a SharedMap :- it's a class which implements Map, but internally is an Object[] and a reference to another Map of name -> index for lookup. These work well when you have lots of immutable Map-style objects with the same entries, as you don't have to keep duplicating all the entry names.
.
Originally posted by Frank Carver:
If I change the data contained in a Product (I mean the type, name, etc) the compiler will show me an error whenever the Product is used wrong.
The "flip side" of this, of course, is that often even a small change to such a class can mean files to edit across the whole system. I prefer, these days, to decouple such things as much as possible, and deal in standard API classes wherever I can.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
it's a teeny, tiny, wafer thin ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|