Hi,
I’m new to CSLA, reading the book, up to chapter 8. I am trying to work my way out of the relational way of thinking and onto the behavioral model that Rocky is championing. I think I grasp most of what the book expounds upon but have an OOP design question I need help with to validate my thinking.
Say I have a use case that simply states “we need to maintain a person’s information”.
A person has general demographic information (first, last, date of birth, etc.), work authorization information (type, expiration date. etc.), emergency contact information (name, phone, etc.) and more, a bunch more, but this is enough to illustrate my question. So for this question, following SRP, my responsibility/behavior for this class is to update a person’s data.
I guess my bottom line question is, is this just one class with a bazillion properties or is there a reason to normalize this into multiple classes, not one-to-one to match my database normalization (we’ve learned from the book we don’t want to be data-centric anymore) but more from a logical “object” perspective? Say a main class for <<person>> that would then contain <<personWorkAuthorization>> and <<personEmergencyContact>> classes. These additional classes, personWorkAuthorization and personEmergencyContact, would just be data holders. Or…..would I just have a <<person>> class and a <<personWorkAuthorization>> class since these 2 model the “real world” things (objects) and stick the emergency contact info in with person?
Do we ever normalize objects just to get a "cleaner" object model?
Thanks for the help.
Hi
I guess it depends if your use case "we need to maintain a person’s information" always involves all the data you specified. Or do you in reality have use cases like "maintain a persons demographic information", "maintain a persons work authorization information", etc.
If it really is "we need to maintain a person’s information" and that is all the data and you wanted to break up th data into objects and then compose them all that is a possibility.
Say a main class for <<person>> that would then contain <<personWorkAuthorization>> and <<personEmergencyContact>> classes.
This is combination. But to quote Rocky from the thread http://forums.lhotka.net/forums/thread/17230.aspx (have a good read of this thread):
"composition can have some serious downsides in terms of performance, especially when it comes to data access. At least if you view composition as the use of multiple object instances working in a coordinated manner."
Though, depending exactly how you implement the data access I belive you may be able to avoid the performance loss. For instance if you implement the components as children and only have the root contact the db. This is what you talking about here I think:
These additional classes, personWorkAuthorization and personEmergencyContact, would just be data holders
I mentioned this in the http://forums.lhotka.net/forums/thread/17230.aspx thread, search for "dumb object", this should help you choose the most appropriate solution based on pros and cons. Though remember to reconsider the use-case maybe it could bebroken down into maintaining different info about people.
Hope that helps
George
| Design Patterns Explained A New Perspective on Object-Oriented Design Second Edition | ||
| By Alan Shalloway, James R. Trott |
| ISBN |
: 0-321-24714-0 | |
|---|---|---|
let's say that i have a Person object that i want to track it's name and address and ...
the address can vary from time to time (or from a solution to solution). so in a given time I am interesting in the phone number and street name and country. but in another time (or another solution or another time when business requirement change) I am interesting in the mobile phone and region name also and maybe the email address...
so I am now obliged to change my Person object (and then the view).
more that this, Person object have validation rules that is related to Person idea, for example a Person must have a Name and an Address (cannot be null for example), a persone Name must be unique and it's age must be grather than 18 year and so on...
in another hand, the Adress must have a valid phone number and a valid country name ...
So the validation rules for Person are related to Person idea and the validation rules for Address are related to the Address idea. Person have different behavior than Address. the user can access the Person but not the address (authorisation rules)...
So I decide to create another object called Address and encapsulate it in Person object. and maybe I do this for the Name field (because a name can be at a given time as First,Last and on another time First,Middle,Last and each time there is different behavior, for example at a given time Middle name must exist, but in another time it can be null...)
Now Person object know that there is an Address, but does not deal with the details of the Address. and I can now make different type of addresses that inherit from Address, all this without making Person to know anything about the inherited Address.
I can say that I have encapsulated the Address idea in an abstract class, and aggregated this class in Person class.
this also promote the reuse of Person class (one of the OO principles)..
this is my understanding of the book that i refere to it in the begening of this reply, and this is a simple paragraph from the book :
Consider what should be variable in your design. This approach is the opposite of focusing on the cause of redesign. Instead of considering what might force a change to a design, consider what you want to be able to change without redesign. The focus here is on encapsulating the concept that varies, a theme of many design patterns.
Or, as I like to rephrase it, "Find what varies and encapsulate it."
These statements may seem odd if you only think about encapsulation as data hiding. They are much more sensible when you think of encapsulation as hiding classes with an abstract class or interface"type encapsulation."[3] Containing a reference of this abstract class or interface type (aggregation) hides these derived classes that represent variations in behavior. In other words, the using class has a reference to an abstract class or interface that has more than one specialized derivation. These derivations are hidden (encapsulated) from the using class.
[3] Generally speaking, type encapsulation is what the Gang of Four means most often when they just say "encapsulation."
I hope that i show you the solution for this type of problems, and now i think that you can think in a different way how to create your classes...
Ahmad El Kerdi, Lebanon...
George and Ahmad thanks for replying. You've both been helpful in opening my thoughts on these issues.
George - Really good stuff in that post you linked to, it deserves a bookmark. Rocky's statement "Reuse is not the goal. Maintainability is the goal" is enlightening and liberating. How many times have we heard that the goal is reuse, reuse, reuse.
The pros and cons you helped facilitate on the "dumb object" idea are very informative. Rocky's point that the "dumb object" idea is problematic because of losing interactive data binding additionally brings consideration of the UI into the analysis of the design. Previously I would have tried to leave the UI out of my thinking but I can see how this could lead to different design decisions so ultimately it should come into play.
Ahmad - You highlighted a provoking paragraph from the book, thanks for the recommendation I will take a look at it. It looks like it's worth picking up.
Copyright (c) Marimer LLC