Java and interfaces

[Atticus]

I'm learning Java, and am on course of Software design, very simple such, mostly basics of UML and the design principles.

There was discussion on interfaces, and the teacher something puzzling. There are reasons why I didn't ask clarification from him, and I'd suppose multiple views are good anyways, so I'm asking you: He said that interfaces most usually define the getters and setters of class. When I look native interfaces, they make only small portion of the methods.

Furthermore, isn't it bad to define them in interface, since then you're also saying what attributes there should be in the implementing class? And isn't that dangerous on the principle that you have access only to the services of objects, not to their variables (unless necessary).

He also said that objects should communicate mostly or purely by getters and setters. This seems odd to me too. Shouldn't it be methods offered by other objects?

 

[Souron]

The idea behind getters and setters is that an inheriting class or interface implementation can override how the property is derived. For example, you could have a complex number interface that you initially implement as x and y coordinates, but then make another class that implements complex numbers via angle and magnitude. The accessors and mutators for x and y would still stay, but they would be implemented differently.

I'm not sure I agree with the instructor on the other bit.

 

[duckstab]

He said that interfaces most usually define the getters and setters of class. When I look native interfaces, they make only small portion of the methods.

Furthermore, isn't it bad to define them in interface, since then you're also saying what attributes there should be in the implementing class? And isn't that dangerous on the principle that you have access only to the services of objects, not to their variables (unless necessary).

I think it's an overgeneralization on his part. A more typical example for me might be something like java.util.Map, where the interface defines a contract between the caller and the implementation. So the same calling code can call methods on a HashMap, SortedMap, etc., without having to know which one they're dealing with.

But the question of exposing getters and setters is actually a more subtle one. It does tend to increase the coupling among classes because the interface is wider. But it's not always avoidable and it definitely doesn't dictate anything about the implementation details.

For example, the setter could actually set a field on the object implementing the interface, or it could just delegate to another object, e.g.:

Spoiler :

public interface Foo {
String getBar();
void setBar(String bar);
}

...

public class MapBasedFooImpl implements Foo {
private Map<String, String> attrMap = new HashMap<~>();

public String getBar() {
return attrMap.get("bar");
}

public void setBar(String bar) {
attrMap.put("bar", bar);
}
}

He also said that objects should communicate mostly or purely by getters and setters. This seems odd to me too. Shouldn't it be methods offered by other objects?

What he may have been trying to point out is that, with getters and setters, the fields themselves can be private. Getters and setters are methods like any other, albeit fine-grained ones.

 

[Souron]

Yeah, except in the class itself, where it doesn't matter much, you should not access data members directly. Sometimes an exception is made for static-final data members. Note that this practice is unnecessary in languages like D and Python, which have properties, because properties provide the advantages of getters and setters, while using the same interface as regular member access.

 

[duckstab]

Yeah, except in the class itself, where it doesn't matter much, you should not access data members directly. Sometimes an exception is made for static-final data members. Note that this practice is unnecessary in languages like D and Python, which have properties, because properties provide the advantages of getters and setters, while using the same interface as regular member access.

Personally, I consider that a flaw rather than a feature of Python. I once had a job where the app was about 50/50 Python and Java and I remember more than once having debugging issues because some genius decided to do a fancy overload of __get__. To me the saved keystrokes aren't worth it in the long run, especially since modern IDEs have pretty sophisticated autocompletion.

 

[Souron]

Personally, I consider that a flaw rather than a feature of Python. I once had a job where the app was about 50/50 Python and Java and I remember more than once having debugging issues because some genius decided to do a fancy overload of __get__. To me the saved keystrokes aren't worth it in the long run, especially since modern IDEs have pretty sophisticated autocompletion.

That's probably happened because most of the developers were used to the Java way of doing things. If people get used to languages with properties, that won't be a problem.