 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2006sholud getters/ setters be inside interfaces?
hi.. i'm just wondering should getters and setters (of at least simple types) be included in an inteface? or just inside a class or abstract class? is this ok? public interface person String getName(); void setName(String name); int getId(); void setId(int id); This is okay, but from a design standpoint, an interface should define *behavior* and not the accessor/mutators. More like: public interface Schedulable{ public void schedule(Task t); public void reschedule(Task t); ... } There can be concrete implementations of this interface that can provide different "behavior" but expose/implement the exact same interface. For a setters and getters, there is no behavorial aspect (assuming you are following JavaBeans spec). -cheers, Manish Manish Pandit のメッセージ: > This is okay, but from a design standpoint, an interface should define > *behavior* and not the accessor/mutators. More like: This is usually true. If I want to generate values from a seed number or perlin noise or whatnot I'll need to operate through accessors for this to work. Naturally, if an algorithmic approach is used, the mutators probably won't actually do anything. Like anything, it depends on what you want to do. Do you have a reason to put accessor/mutators in an interface? If the answer is yes, then do it. If the answer is no, then I would not bother. Accessor/mutators can lead people to make assuptions about how something works. People shouldn't make assumptions about how something works- they rarely need to know. When they *do* need to know, assumptions are the wrong approach. -Brendan i'm creating a domain model of an underwriting brief, the model must regualr data (like nam,e age, sum etc..) it's has been decided that the data collection will be developed in anohter module by somone else, and he wanted only interfaces of all my class so he wouldn't have to work with my actuall implemenations, originally i wanted to use abstract classes with getters and setters, with one implemenatin class they would use, (and maybe create with factory) i wanted that some of these classes may have interfaces defined to them, interfaces that would specify behaviour concering attaching child objects, and the abstract classes will implement them. but they said it was not consistent, that they wanted to work only with interfaces (even with value objects, like an object with only getters and setters), and that they didn't want to work part of the time with interfaces and part of the time with concret classes. > Manish Pandit のメッセージ: > > This is okay, but from a design standpoint, an interface should define [quoted text clipped - 16 lines] > > -Brendan > i'm creating a domain model of an underwriting brief, the model must > regualr data (like nam,e age, sum etc..) [quoted text clipped - 15 lines] > and setters), and that they didn't want to work part of the time with > interfaces and part of the time with concret classes. What happens when management dictates the development process. Formally accessors and mutators represent attributes - they are a cover for what would otherwise be public members. They go in a different box in a UML class diagram from the behavioral methods. That said, one could still define an interface for each value object class, but that tells an interesting lie. The interface says, "Make as many implementations of me as you want." The lie is that you really want one, final class for most any entity. From a development standpoint it makes much more sense to create value objects as concrete, final classes. Putting accessors and mutators in an interface is formally equivalent to defining members in interfaces, for which interfaces are not intended. However, someone in your organization got it up their rear end that "designing to interfaces" is a Good Thing, and they are going to shoehorn every aspect of the job into that buzzword irrespective of sense or sensibility. The problem is that it makes for a less clean design, unless you throw away the interfaces before production. Good luck. - Lew but my classes are Persons and Policies, really entities, which i understand should NOT be value objects. i thought value objects are something like an address objects. > > i'm creating a domain model of an underwriting brief, the model must > > regualr data (like nam,e age, sum etc..) [quoted text clipped - 40 lines] > > - Lew >hi.. > [quoted text clipped - 10 lines] >int getId(); >void setId(int id); Getters and setters are associated with instance data fields. Since you can't specify data fields in an interface, IMO, you shouldn't be specifying the standard methods to access them and change them. Maybe an abstract class is really what you want, where you can specify data fields and the getters and setters. Lee Weiner lee AT leeweiner DOT org > hi.. > [quoted text clipped - 10 lines] > int getId(); > void setId(int id); Read "Why getters and setters are evil" (http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1) and then decide. oh i read him, but he is way too extreme, if i follow him, there will no java bean spec, tools like hibernate, spring, and jstl.. > > hi.. > > [quoted text clipped - 14 lines] > (http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1) > and then decide. Top posting corrected... > > > hi.. > > > [quoted text clipped - 16 lines] > oh i read him, but he is way too extreme, if i follow him, there will > no java bean spec, tools like hibernate, spring, and jstl.. Actually, if you read the article more carefully, he does talk about the javabean spec (which was intended to be used in automated tools, such as hibernate and spring), and how most programmers abuse it. In any case, I was discussing this "extreme" point of view with a friend of mine, and we discovered that it makes sense for some classes of objects to have observable properties, but novice OO programmers tend to expose too much through getters/setters. An example. Say I have a Robot class. A Robot has its internal state, which is mostly hidden from the world. It makes sense that you can query the location of a Robot, so that is one of its observable properties. A gettter is appropriate for this. The state of the robots program (assuming there isn't a debugger attached) is a hidden state (implementation detail). The article also talks about this concept, but in different words. Without saying "primitive obsession", he describes the solution to that bad smell. If you absolutely must return a value property, it should be returned by interface, not by primitive. If you get used to refactoring code, you'll realize that you can avoide a lot of indecent exposure just by moving a method to the class it probably belongs in. the issue here ,is that i must expose getters and setters for another module which will collet data from legacy systems. now this module runs into trouble becouse my model is based on many-to-many relations ship ,so in order to indert an insurance, you have to insert a person and a policy first, and then place an insurnace, link to that policy and insurance. since that module has not context (no global variables or passing paramters) it cannot give me that link. i suggested that they should feed that interface of that module into that my model and that i should obtain the data i want by myself > Top posting corrected... > > > > hi.. [quoted text clipped - 42 lines] > a lot of indecent exposure just by moving a method to the class it > probably belongs in. > hi.. > [quoted text clipped - 10 lines] > int getId(); > void setId(int id); I think it depends on your view, and treatment, of getters and setters. If you think of them as ways of accessing instance variables, they don't really belong anywhere in an OO design, except possibly in conjunction with some automated tools. If the interface involves the concept of a name, and users of the interface should be able to get and set the name, then getName and setName seem to me to be reasonable names for the methods that get and set the name. The need for an externally accessible attribute may cause the use of a field in an implementing class. The existence of a field in an implementing class should not cause anything in the interface. Patricia Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.