The thing is this is the right way only for one sort of objects ... for objects that are (mostly) behaviour containers. Objects that exist to do something and happen to need some (mostly internal) state to provide you with a nice interface.
But there is a totally different sort of objects .... objects that are (mostly) data containers. Objects that exist to store some (mostly externaly accessible) data and provide little behaviour apart from validating the values stored and ensuring the consistency of the data set.
In this case starting with the methods would be pointless. Instead you need to know what data do you need to store, what are the types and constraints and then you may start adding methods that compute something out of the stored data, that change several attributes at once in some way, ...
Most times it's easy to say which sort of object are you designing ... a "worker" or an "intelligent data structure", sometimes the distinction is not so clear. Anyway starting with starting with the code that uses the object is IMHO a good idea.
Jenda
Enoch was right!
Enjoy the last years of Rome.
In reply to Re^2: Psychic Disconnect and Object Systems
by Jenda
in thread Psychic Disconnect and Object Systems
by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |