sholud getters/ setters be inside interfaces?

[Elhanan]

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);

 

[Manish Pandit]

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

 

[sgeos]

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

 

[Lee Weiner]

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);

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

 

[Daniel Pitts]

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);

Read "Why getters and setters are evil"
(http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1)
and then decide.

 

[Elhanan]

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..

 

[Elhanan]

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.

 

[Daniel Pitts]

Top posting corrected...

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.

 

[Elhanan]

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

 

[Lew]

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.

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

 

[Elhanan]

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.

 

[Patricia Shanahan]

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);

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