Are your objects anemic? It's time to get rich...
I even checked-in a sample for the Persistent Domain Object pattern to the p4j5 repository. The sample is a small, but objectoriented, shoppingcart which can be even started outside the application server/container. There is nothing special the implementation, except it has methods with some logic and only few getters/setters (because they are not needed). A Persistent Domain Object (PDO) is just an object, but is persistent. The reaction of a such objectoriented approach and simplification (actually the activitiy layer and the persistence are collapsed) can be interesting (about 30 comments for my post about "evil" getters and setters). I presented last week this pattern in the Java EE 5 Workshop at oose.de as well. A Java EE beginner ask me: "Actually, you are talking 2 hours about object oriented design - the one and only difference are few strange annotations - so why you are so excited?". Interestingly enough the other more seasoned developers were shocked. They were used to seperate the business logic from the persistence :-).
Java EE 5 brings us a paradigm shift. Dumb persistent objects (Persistent Anemic Objects) should be an exceptional best practice and not the common rule. Also Getters and Setters are optional - complex business logic can be only hardly emphasized with accessors...
All objects should have getters but most of them should be private ;)
kind regards,
Kirk
Posted by Kirk Pepperdine on July 12, 2007 at 10:28 AM CEST #
Kirk,
No should!!
Just like pages said, that let cow extrude milk or let milk self drop out from cow pap , it's a question.
And if you delphied, You (it's really should) should know about, publish fields or publish methods it'a question too.
Given fields public, Yes, you just know people should known, don't know my internal process, by method, or by instance variable, or by compute other states, you not care it, and not be care, and not let you care.
Same sematic to methods.
Which is better, it's just like and interesting.
Just like you like rice, he likes cire, I like 大米, monkey like what he like.
Right?
Regards,
qinxian
Posted by qinxian on July 12, 2007 at 02:57 PM CEST #
Kirk,
you are right in Java-Context. But JavaFX has a very interesting solution: http://www.adam-bien.com/roller/page/abien?entry=java_s_getters_and_setters
regards and thanks for your comment,
adam
Posted by Adam Bien on July 12, 2007 at 07:25 PM CEST #
Qinxian,
I like really your comment-style, especially 大米 :-). I will try to explain it with your style:
getters/setters are motivated by the technology, not business. Domain Objects have to expose business not technology. So getters/setters are at least questionable in domain objects, right? :-),
I'm already looking forward for your comments!,
regards,
adam
Posted by Adam Bien on July 12, 2007 at 07:28 PM CEST #
I must disagree... I find it's rare that business logic over a domain model is only done one way. For example, I was part of a team building an enterprise accounts payable / accounts receivable system. You'd think that calculating the sum of line items and checking if an invoice or receipt balanced to its header total would be an area where you'd put it on your model... Unfortunately there were 3 different strategy / calculators for doing that calculation dependent on several different factors. Also, what if you need to use your domain model as DTO's to send somewhere else? Do you want to carry along all of the wired-in dependencies? I'd rather not have to map them to another set of dumb models.
Posted by Jason Carreira on July 13, 2007 at 01:26 AM CEST #
many here will probably disagree with me (my brother included ;) ) but getter/setters are no doers! No one would expect a getter calculating (eventually expensive) stuff. They are just representing the current state of an object (think of a state machine).
The IMO main reason for getter/setter is, if the object needs to be aware of state changes (eg. hook in listeners).
If they do more than that, they are regular methods and need to be renamed...
but back on topic
in my world ;) Jason's getHeaderWidth() method is not representing the model and therefore not representing the state of the Object => is no getter
problem solved ;)
Posted by Michael Bien on July 13, 2007 at 04:02 AM CEST #
Adam,
Thanks and Happy to hear you and your some words with praise(I cannot translate 溢美之词 to english or german) which make me fly upto sky:)（and nor 飘飘欲仙）.
Hi all,
I think I must give more details for my comments.
Ok, for me, code language more better than other nation language, so seudo it.
There is an object called Person, which has a property money(yes property, it's a property, and it's a attribute), represent by java class :
class Person{
private double money;
public double getMoney(){return money;}
public void setMoney(double money){this.money=money;}
}
I hear JAVA says, the Person has two public feature, you can check out money mount, or change money mount, you cannot know where is the money.
"hei, No, you wrong" somebody roars, "it's a field called money."
"hei, No, you wrong" I roars too., "I can change money field to a String type field or no field".
like this:
class Person{
private String money;
public double getMoney(){return Double.parseDouble(money);
//if no field,
IfIcrazyIRobBank();
}
public void setMoney(double money){this.money=""+money;}
}
Right? Java just tell us public feature method, as to inner thing, NO way.(Just on face, not include object reflection, by the way, as you see, java can do a reflection, why people cannot do reflection?:-)) java says, "Evil people, you just only need to know how, no need to know what".
But In Delphi, like this,(not really delphi code, just in nature, I state it with a java style)
class Person{
property double money read getMoney() write setMoney() field _money;
private double _money;
private void setMoney(double money){
_money=money;
}
private double getMoeny(){return moeny;}
}
As you can see, delphi just tell us a property call money, as to other thing, it not tell us and we not know about. Delphi says, "Evil people, you just only need to know what, no need to know how."
more, try change it with no field, like this:
class Person{
property double money read getMoney() write setMoney();
private void setMoney(double money){
throw new Exception("who care you bum money?");
}
private double getMoeny(){int double count=takeItFromEvilBillsPackets();
if (count==0) throw new Exception("bill to get married from beach to change to an good egg");
return ifThornBushesEmbezzle(count);
}
}
OK, as you can see, this way tell us just what, no how.
So getter/setter and propert syntax can be consider as methodology view. Isn't is?
btw, if java do a property syntax, it would be a good news. but please donot paint tiger by looking at tom cat. I done a prososal, maybe should share now.:)
And from my experiences, getter/setter just only like “the chicken rib”。
so what about Domain Object. It's a methodology view quest too.
How many face? what face is our system focused on?
It's difficut to make a conclusion. So "No Best, just most properest".
And at least I disagree let domain object to be static domain object(so may not be domain object ,but question is what on hell is the domain object?)
To next?
Regards,
qinxian
Posted by qinxian on July 13, 2007 at 09:34 AM CEST #