Comments on MXUnit Blog: One Said Getter

Rich business object vs service object. I have be...

2012-01-23T20:43:41.869-05:00

Rich business object vs service object. I have been wrestling with how much delegation should be assigned to each. It's hard to find the balance.

Right now, on one of my projects, I have a business object that has a reference to my DAO. My BO gets the initial query result, and does all kinds of checking and then logs the data into a database table.

From the client page, the implementation looks like this

myBO=new BO();
myBO.setData(data);
myBO.processImage();
myBO.hasErrors();
myBO.getErrors();
myBO.getImageCount();

'processImage' has data validation and invoke DAO method to log the data.

Having a rich business object/bean in this situation feels 'cleaner' and encapsulated, rather than exposing the validation logic on the client page and then once validated, passing data in the service object, which then calls the DAO to log the data.

i just reread your comment, bill. and i would like...

2008-12-22T11:34:00.000-05:00

i just reread your comment, bill. and i would like to submit it to the blogosphere for Comment of the Year award.

well done, sir.

Good stuff, Marc,

I have one major correcti...

2008-10-16T16:45:00.000-04:00

Good stuff, Marc,

I have one major correction: With respect to Wal-mart greetings, shouldn't it be "… is that a return OR EXCHANGE ..."?

The Wal-Mart merchandise exchange/return analogy is actually one of the themes I hear in your well thought-out post. In other words, when we maintain our code (evolve it) we exchange certain parts of it - effectively swapping out implementations. In some cases, we look at the effort associated with evolving something and simply opt for a total "return" - or re-engineering the app from the ground up - "Do you have a receipt"? One thing never changes; and that is nothing stays the same. So, today I cast my vote for adaptability and agility in design. In order to do this, I think our software needs to be testable and testability naturally seems to lead to smaller components, but more of them. It's kind of like dealing with Legos vs. cinder blocks. And I don't think we have any metrics for how much it costs to re-engineer a large procedural legacy system vs. re-engineering a well-designed OO system, but, I would much rather be brought on a project that has a bunch of Legos with tests than a couple big-ass cinder blocks.

When it comes to instance data (set/get), which make up an object's state, accessor methods were suggested in order to control the effective state transition of an object. I think when dealing with certain kinds of data or needs we might need this kind of control, in other kinds of data it's not as important. I also sense the potential thread-safety issues when dealing with instance data ... that is, anything shared and not synchronized, whatever that might be.

I think we all want some simple rules we can follow: "Always use accessor methods and private instance data", or "do this" or "don't do that". It is a pain to wear depends, but we do need to catch that stuff that eeks out of our technical dogmas, deal with it, and admit that we need a changing. So, it depends …

bill

Awesome post! I only read PART I (need to get some...

2008-10-16T13:17:00.000-04:00

Awesome post! I only read PART I (need to get some work done), but am loving it so far. Will return tonight to finish this up. Really good stuff, can't wait to finish.

This is an awesome post and one I think I'll be re...

2008-10-16T11:09:00.000-04:00

This is an awesome post and one I think I'll be reading again. Thanks for taking the time to write it! You've raised some really good points here and made an excellent job of showing that their is not just "one true way".

Holy Crap dude, that was beautiful. I should just ...

2008-10-16T08:45:00.000-04:00

Holy Crap dude, that was beautiful. I should just rant in private to you so you can write stuff like this all the time. After reading some of the other crap circulating I was starting to regret gettting it going, folks linger too much on the part I was being an ass about and not focusing on the other part (my fault). You did a great job Marc. If you use This scope I would hope ctrl space learn would work too but nothing big there. Also I want to point out that while I used YAGNI to defend THIS scope I was mostly going through all that to get to my punch line of just using structures :)