Principal for object behavioral assignment 1

[EdwardJS024]

I wanted to kick off an interesting oo topic to possibly get users feedback on their way of thinking during oo design.

Like many of you, oo books lay read on my desk. None of them have really ever presented any formal principal for assigning appropriate responsibilities/behavior to objects. Or, not that I can recall.

Books, articles and people I talk to say it just comes with experience. Knowing what responsibilites an object is capable of is an interesting thinking process and I wish to share my approach to design. I sparked this session off because I stumbled across a thread that reminded me of a similar situation. The user states his problem as:



"....If I have a 'Staff' class in a Library System and a staff member is able to carry out operations to update the library catalogue (ex: add book, delete book, etc), where exactly do I put these operations? Do they go in the 'Staff' class, or do they go in the 'Book' class?"
--

http://www.tek-tips.com/viewthread.cfm?qid=823115&page=1

I applaud this user for posting such a question. Many times there are engineers who may not ask because they feel it's just too simplistic and commen sense will kick in sooner or later.

Here is a similar Q in the problem domain that i had some time ago:

"I have a student and a class object. The student needs to register with the class. Who should be assigned the Register behavior? Should the student.Register(withClass) or should the Class.Register(aStudent) ??"

Now, some might say that this is a newbie's learning curve to the big game, and they are wrong. As simple as it seem, what principal is there to follow to assign the proper responsibility to a given set of collobrating objects? This simple example scratches the surface of even more complex systems. I really do want you guys to give me feedback on your approach for correct responsibility assignment.



I'll get the ball rolloing by stating my principal for behavioral assignment in containment/collection relationships.

"Objects that controls policy making decisions in a problem domain will have appropriate behavior to act accordingly."

Simply stated, If an object has knowledge of making decisions and controling the policy, then let that object get the behavior to act.

I'll like to mention that this follows true for alot of containment relationships. I am still researching and understanding more about this concept.


Let's take the student class relationship again. In this problem, I realized that student controls no policy on how the registration process works. The class is the object that makes those decisions. The class knows how to register and controls the main policies in this abstraction. Student does not care how registration occurs in the system, student just needs to get into the class.

In the above "Staff member vs. LibraryCatalouge" system. Who controls the policy of how books are added and removed? The engineer further mentions if he should place the adding/removing behavior in the Book or Staff class.


I eliminated Book immediately. Book cannot add itself to the catalouge. A book is a book, standalone and has no knowledge of adding algorithms. Staff members are simply controllers or drivers in the system, they accept books and delegating the real adding to the Catalouge [picture a triangle]. It does not make sense to have staff memers know specifically how to add items to the cataloug. Thats where the delegation comes in, the staff member can delegate the adding to the Catalouge, it's the catalouge that really controls how catalouging, indexing and catagorizing works.

Imagine a staff member handing over a book to the catalouge. The catalouge determins that there are already 20 duplicates in the system and no more should be added, so the book is rejected. Here the Catalouge makes that decision.

What are your opinions ideas? Here i have presented a principal that holds true in containment relationships, Do youguys have any other?

EdwardJS

 

[zooxmusic]

I am new to this thinking but it reminds me of a problem I use to pose to my co-workers. I have a car loan through Chase. I also have other loans outstanding. I also have an Automobile folder. So should I create a Loan folder and hold all of the other loan info in subfolders of the Loan folder? Or should the Chase car loan go in my Automobile folder as a subfolder? Now I would think that the car loan is actually a loan not a car. The fact that it is a car loan is only an attribute of the loan so I would put the car loan in a Loan folder. But then insurance comes up. I have car insurance and also house insurance. Which folder to put that in? I actually put the insurance folder as a subfolder of Automobile only because I have and seem to only have a limited number of insurances. Car, House, Life. But loans, in my case, could be a lot so this is my thinking. I know this is not exactly what you were stating Ed but I feel there is a "feel" of responsiblity of which folder "owns" what. I hope this doesn't sound ridiculous.

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[stevexff]

Extending the library example, the Catalogue must be responsible for adding and removing CatalogueItems. Which may be subclassed into books, magazines, published papers, DVDs, etc. etc. or even be a collection of disparate objects that all implement the ICataloguable interface. If this last one was the case, you certainly wouldn't want a number of different implementations, one in each object.

Staff members shouldn't have the responsibility. Party objects should represent people, and being Staff is a role that a party may hold. The Catalogue may check to see if the Party has a Staff role as part of authorisation when a Catalogue request is processed, but that should be the limit of Staff's involvement. So a Party can also hold a role of Borrower, thus allowing staff members to borrow books from the library as well as checking them in.

 

[dragonwell]

What about this.

A "registrar" object adds and removes students from seminars. The registrar decides if a seminar is full or has vacancies, if a student has completed any pre-requisit seminars, and so forth, by using the properties of students and seminars. The client application will use a singleton instance of a registrar to manage the student/seminar aggregation.