CODEWITHSUNDEEP
oopobject
Tattat
Tattat

Reputation: 15778

Which is a better design?

I have a team leader object, and have lot of team members object own by team leader. Both team leader and team members have a function called "writeDB".

So, design 1:

Have a common writeDB function in DBUtility:
teamLeader.writeDB(); //calling DBUtility like this DBUtility.insert(self);
teamMember.writeDB(); //calling DBUtility like this DBUtility.insert(self);

design 2:

Both implementing a writeDB Interface:
teamLeader.writeDB(); //implement the write DB itself;
teamMember.writeDB(); //implement the write DB itself;

design 1 can centralize the writingDB logic into one single class, if there is any problems in writing DB, I only need to change the DBUtility class, also, if I would like change the DB, I only need to change one place.

design 2 can separate the code into two places. If one developer coding about teamLeader logic, he don't need to update the DBUtility, also, if the code move to somewhere else, he don't need to copy the useless function, for example, the DBUtility's teamMember writeDB function is not needed.

What do you think for better maintain? or the design 3 from you. Thank you.

Upvotes: 4

Views: 101

Answers (6)

Chris McCauley
Chris McCauley

Reputation: 26393

Putting aside my concern that any model level class would have an explicit public method called writeDB, I would go for option 1

Persistence should be considered orthogonal to the core responsibilities of these classes.


The benefit comes in several parts

  • Cleanly separating the responsibilities will result in a more object-oriented design. More object-oriented means more comprehensible and easier to manage over time.

  • In larger teams, you may well have a sub-group working explicitly on the persistence layer and they can have total responsibility for managing and optimising the code.

  • When you inevitably release that database X is better than database Y (or indeed that SQL is a bad idea), the persistence logic is not scattered across the code base


That pesky writeDB() method

Just to go back to my first point, you shouldn't have a public method called writeDB. You also probably don't want a more generic name such as save. The better design would allow the classes themselves to decide when they need to be persisted

Upvotes: 2

SzabV
SzabV

Reputation: 244

The second option is definatly mor OO. Eache type implements the writeDB interface. If it makes sence when writing teamLeader to also write each teamMember then writeDB implomentation for teamLeader can call writeDB on each teamMember.

That would be the most OO solution.

Howerver, this dosen't take into account persistense layer limitations and efficencies.

Upvotes: 0

WW.
WW.

Reputation: 24301

Why do TeamMember and TeamLeader have to know about the database at all? I think this would be better:

DBUtility.write( teamMember );
DBUtility.write( teamLeader );

Better still is if DBUtility is not static, allowing you to see what it really depends on. Static is the same as global. Global puts an assumption in place about only ever doing it one way, and this generally causes problems later.

DBUtility dbUtility = new DBUtility( dbConnection );
dbUtility.write( teamMember );
dbUtility.write( teamLeader );

Then later, you might need to write to disk as XML. You should be able to add this feature without changing your TeamLeader and TeamMember.

XMLUtility xmlUtility = new XMLUtility( stream );
xmlUtility.write( teamMember );
xmlUtility.write( teamLeader );

Upvotes: 2

Lucero
Lucero

Reputation: 60190

It depends. From a Separation-Of-Concerns principle this shouldn't be in the class itself, but having a class which knows about all others violates the Open-Close-Principle.

There is a third option for this kind of operation (e.g. write to DB), that is to use some metadata in the class and then some code which does write the object to the database by using the metadata information.

Upvotes: 0

Ivailo Bardarov
Ivailo Bardarov

Reputation: 3895

I should go with design 2 which will force all my classes to have writeDB method, and I will use design1 to provide this functionality.

This way I will have interface for my objects Leader/Member and will have the actions grouped under on class which knows how to do the actions.

Upvotes: 0

Ghyath Serhal
Ghyath Serhal

Reputation: 7632

I prefer to use the second design because it is more object oriented and you will benefit from separating the code.

Upvotes: 0

Related Questions