Hank Emery wrote:Basically, getters in interfaces are considered bad design or code smell.
Junilu Lacar wrote:An interface that defines only getter and setter methods is smelly
salvin francis wrote:Look at interface as a behavior. You are setting a standard for how an object behaves. Typically, you should be able to read an interface to a person who does not know java.
Imagine saying:
"My game has a character who can pick up, drop or buy weapons. He can use it to kill his enemies"
vs:
"My game has a character which has mutators for weapons"
In addition to this, You might want to look at Null Object pattern for behaviors which do not make sense for a particular class.
Once you start writing that sort of thing, you start to destroy your own case. But it also gives you all sorts of design possibilities. So now my mind has gone off in flights of fancyHank Emery wrote:. . . So, in my above example, you agree that having a getter that returns the damage would make sense, if I wanted to sort, or do some sort of calculation? . . .
Campbell Ritchie wrote:
Once you start writing that sort of thing, you start to destroy your own case. But it also gives you all sorts of design possibilities. So now my mind has gone off in flights of fancyHank Emery wrote:. . . So, in my above example, you agree that having a getter that returns the damage would make sense, if I wanted to sort, or do some sort of calculation? . . .
Are you going to want to add up all Swordsmen? Are you going to want to sort all Swordsmen? If you have an interface which has a getStrength() method in, that is not only going to affect its public interface, but it is also going to affect its implementation by encouraging you to give (him) a strength field, and determining the type of that field. Giving that method int type makes it impossible to change the field to a long or a double later on.
You can add other interfaces. For sorting, consider the Comparable<Swordsman> interface, comparing strengths. Consider an Addable interface with the getStrength method. Consider giving it Number as its return type, rather than a primitive, or even ? extends Number. Consider a better name than Addable. Consider putting all your warrior classes in one package, making the strength field package‑private and writing a WarriorList class in the same package. You can write a wrapper round a java.util.List implementation. Then its sort() method can access the strength field directly, but it won't be accessible outwith the package. These are simply ideas, but maybe a plain simple getStrength method in the interface isn't the best design.
An interface that defines only getter and setter methods is smelly
Liutauras Vilda wrote:Is your main problem you are trying to solve, how to enforce some entity to have a
behaviourability to provide some information? (in your case getterOfSomething?)
ability to provide some information? (in your case getterOfSomething?)
Is it something similar what you are talking about?
According to theory, interfaces supposed to define a behaviour, what object might do. Getters and Setters aren't really behaviours, they just either tell you a state or sets a state, so such things are better to keep in abstract class in my opinion.
I'd create Employee class and put everything what is common among descendants (name.. and that kind of stuff) while in descendent classes you put specifics.
What do you mean about two classes with the same attributes? Does that mean they are subclasses of the same superclass and only have the fields which the superclass has? Remember that fields should be private and private members aren't inherited, so they would have to have public methods which are inherited. That doesn't necessarily mean getXXX methods.Hank Emery wrote:. . . Lets say I have two classes that share the same attributes. . . . I'm required to have getters for these attributes . . .
Campbell Ritchie wrote:
What do you mean about two classes with the same attributes? Does that mean they are subclasses of the same superclass and only have the fields which the superclass has? Remember that fields should be private and private members aren't inherited, so they would have to have public methods which are inherited. That doesn't necessarily mean getXXX methods.Hank Emery wrote:. . . Lets say I have two classes that share the same attributes. . . . I'm required to have getters for these attributes . . .
Who is requiring you to implement interfaces with only getXXX methods? Have you discussed that with them? Is this an assignment? Unfortunately we see lots of exercises which appear to require strange designs. If your assignment tells you that, you will have to comply if you want full marks.
Liutauras Vilda wrote:
Is it something similar what you are talking about?
Hank Emery wrote:See the getter for the name in the abstract class, won't be better if you made it final? So that the subclass can't override it?
Consider Paul's rocket mass heater. |