Interfaces and Getters

QueenSvetlana · 06-02-2017, 07:42 PM

Is supplying getters/setter in an interface considered code smell?

I was working on a hobby project in Java and came across this thread that had me questioning if the code I was writing was considered code smell.

I understand many developers have different feelings about using getters/setters when it comes to OOP. Some say it doesn't while others say it does break encapsulation. However my question is more specific about getters/setter being supplied in an interface.

sundialsvcs · 06-02-2017, 08:36 PM

Frankly, I have no idea what you mean by "code smell."

The pragmatic decision to use a "getter" and/or a "setter" function is actually very simple: "does it make sense for me to simply allow the Unknown Interested Third-Party to simply 'retrieve the binary value from [my] memory, directly?"

"The programming language in question" is giving you, the designer, "a transparent (from the point-of-view of your client ...) choice." The client's source-code will be identical, one way or the other. Only you will know – and, only you will determine – what actually happens. Will "a function call" happen, when the client's program references a property? Will "a procedure call" happen, when the client's program tries to assign a value to it? (Or, shall either or both of these actions be disallowed?)

The choice is yours alone ... oh Sovereign Designer ... not "his, the Puny Client's."

So ... "what shall you do with this Stupendous Prerogative?"

Aye, "the choice is yours." "(Is that cool, or what?!")

- - -

Now, I would also proffer the opinion that "an interface is typically 'deliberately abstract.'" Basically, "anything that implements this interface," no matter exactly-how it does so, "is cool." Insofar as possible, an 'interface' should be: "what, not how." Hence, the issue of "getters and setters" should not properly apply, since these concerns have to do with "implementation." But you can't always achieve this level of purity.

QueenSvetlana · 06-02-2017, 11:07 PM

Quote:

Originally Posted by sundialsvcs

Frankly, I have no idea what you mean by "code smell."

It's just another way to say bad practice.

sundialsvcs · 06-03-2017, 07:37 AM

In my never-so-humble opinion, there is no such thing as a "de facto good or bad practice." It's simply what makes the most good-sense to the team that is designing it. If the property in question is simply a bit of memory, and there are no "side effects" involved in the act of retrieving or setting it, then getter/setter routines are irrelevant. On the other hand, since they are "subroutine/function calls that don't look like one," they can be handy. For instance, if some piece of code somewhere is trying to retrieve a value that doesn't exist, or is otherwise doing something Very Wrong, then the getter can throw an exception. Likewise if some piece of code somewhere is trying to set a value that is quatch. Other parts of the class can rely on the value with more confidence since the only way to get it or set it (outside of the class itself) is through getter/setter routines that are on the lookout for trouble. Unless the implementation of the class itself is defective, the values are more trustworthy. And that can be a very good thing.

QueenSvetlana · 06-03-2017, 10:01 AM

Quote:

Originally Posted by sundialsvcs

In my never-so-humble opinion, there is no such thing as a "de facto good or bad practice." It's simply what makes the most good-sense to the team that is designing it. If the property in question is simply a bit of memory, and there are no "side effects" involved in the act of retrieving or setting it, then getter/setter routines are irrelevant. On the other hand, since they are "subroutine/function calls that don't look like one," they can be handy. For instance, if some piece of code somewhere is trying to retrieve a value that doesn't exist, or is otherwise doing something Very Wrong, then the getter can throw an exception. Likewise if some piece of code somewhere is trying to set a value that is quatch. Other parts of the class can rely on the value with more confidence since the only way to get it or set it (outside of the class itself) is through getter/setter routines that are on the lookout for trouble. Unless the implementation of the class itself is defective, the values are more trustworthy. And that can be a very good thing.

If I understand you correctly, you're saying that if I provide getters/setters in my interface, with validation logic to make sure any client code that uses it doesn't do anything they aren't supposed to, it's fine?

I usually make my classes immutable anyway, so my question should be, is it okay to provide a getter in an interface?

sundialsvcs · 06-04-2017, 08:11 AM

Quote:

Originally Posted by QueenSvetlana

If I understand you correctly, you're saying that if I provide getters/setters in my interface, with validation logic to make sure any client code that uses it doesn't do anything they aren't supposed to, it's fine?

I usually make my classes immutable anyway, so my question should be, is it okay to provide a getter in an interface?

I'm saying that it can be handy, from a debugging point of view, to insert defensive logic that will help you to detect an otherwise-hidden flaw elsewhere in the code. For instance, if you know that no one should be requesting a property unless they've done some preliminary step, and you find (in a 'getter') that they didn't do that, you can throw an exception. Similarly, if you see (in a 'setter') that the value that's being set is nonsense, or that all of the prerequisites for setting it have not in fact been met, you can also throw an exception. These are "lightweight" things that are done only to reveal the existence of bugs, somewhere else in the code, that might not otherwise see the light of day but which probably would result in "mysterious, unexplained behavior." (Bugs.)

Again, I say that there are no absolute rules here. What makes sense for your situation.

Getters and Setters, insofar as I know, are specified only when you expect a subclass to be able to implement one that will override the default behavior of a parent class. And, languages do vary on this point.

Do what makes sense for your situation, and that is most helpful to future colleagues and the changes that they will be tasked to do. No textbook will ever tell you what you must do, nor that your decision is "right" or "wrong." (If they do, grab another textbook.)

Laserbeak · 06-08-2017, 03:17 PM

I think getters/setters are generally considered good programming practice in object-oriented programming. I know on the Mac/iOS (iPhones, etc) you really have to use them in order to use the dot functionality of Objective-C, i.e.:

Code:

 myObject.thisProperty = something;

or

Code:

something = myObject.thisProperty;

Laserbeak · 06-08-2017, 07:25 PM

Quote:

Originally Posted by Laserbeak

I think getters/setters are generally considered good programming practice in object-oriented programming. I know on the Mac/iOS (iPhones, etc) you really have to use them in order to use the dot functionality of Objective-C, i.e.:

Code:

 myObject.thisProperty = something;

or

Code:

something = myObject.thisProperty;

Plain getter/setters can be generated automatically by Xcode to directly access member variables, or you can code them to return a calculated or otherwise sourced value rather than just a member variable. For example for a triangle object, you may make a getter like this (pseudocode):

Code:

-(double) getHypotenuseLength {
   return sqrt(a * a + b * b);
}

Then you get it like this:

Code:

double myHypotenuseLength = myTriange.hypotenuseLength;

In this case you wouldn't define a setter, so it'd be a read-only property.

sundialsvcs · 06-08-2017, 07:27 PM

Yes, some languages do effectively require them ... and, I must say, "they're damned useful!" Why? Because every attempt to examine the property is going to go through its "getter," and every attempt to set it will go through its "setter." A more perfect debugging point could never be found. Also, as I've said earlier, an excellent place to be suspicious ... and to "blow a nasty bug's cover" with a well-timed Exception throw.

If you design your code to be suspicious, and if you also carefully test that suspicious code, you gain a huge advantage at very little cost: [i]"if the code doesn't blow up, it's likely to be correct that the bug you're looking for "isn't right here." But also, you will quickly(!) flush-out bugs that you never dreamed existed.

In all the software that I write, "assertions," and all such things, remain active in production.

NevemTeve · 06-09-2017, 02:26 AM

@OP Could you please provide an example for such an interface?

sundialsvcs · 06-09-2017, 06:52 AM

Not really – most every language has them, somehow, and every language is different in exactly how they say it.

QueenSvetlana · 06-09-2017, 07:40 AM

Quote:

Originally Posted by NevemTeve

@OP Could you please provide an example for such a interface?

Assume I'm making a media player that plays Audio/Video. Now I could have an (Java)interface like so:

Code:

public interface Media {
 play();
 pause();
 fastfoward();
 rewind();
}

Now, if I wanted to display the name of the media, for example, if I'm watching a movie, and at the side I want to display just the movie title I can alter my interface like so:

Code:

public interface Media {
 play();
 pause();
 fastfoward();
 rewind();
 getMediaTitle();
}

Why not call toString()? Because that might contain unnecessary data, for example, if it was a movie, the movie title, production company, etc. Now I could say displayTitle(); but it's still a getter that returns a String. My problem is, I'm asking a question about intefaces/getters/encapsulation, and of course, I'm going to get many different answers about what is considered correct.

It would seem in this thread the use of getters/setters in general is fine, but the link in my first post is an entire thread of developers that think the opposite.

ntubski · 06-09-2017, 08:37 AM

Quote:

Originally Posted by QueenSvetlana

It would seem in this thread the use of getters/setters in general is fine, but the link in my first post is an entire thread of developers that think the opposite.

I think you misread that other thread, they were saying that an interface having only getters and setters likely indicates a design problem. Taking your Media example, doing it like this would be bad:

Code:

public interface Media {
 getCurrentTime();
 setCurrentTime();
 getPlayingState();
 setPlayingState();
 getMediaTitle();
}

QueenSvetlana · 06-09-2017, 08:40 AM

Quote:

Originally Posted by ntubski

I think you misread that other thread, they were saying that an interface having only getters and setters likely indicates a design problem. Taking your Media example, doing it like this would be bad:

Code:

public interface Media {
 getCurrentTime();
 setCurrentTime();
 getPlayingState();
 setPlayingState();
 getMediaTitle();
}

With that being said, what if I wanted all that information? Would an abstract class with the getters be more appropriate? If so, this might have a side effect of deep inheritance, would composition be suitable for this case?

sundialsvcs · 06-09-2017, 02:06 PM

The whole idea behind "Getters and Setters," in my estimation, is that the language is allowing the users of your class to ignore the details of exactly how the values of any of your properties are retrieved or set. From their point of view, they merely reference the property as they usually do. Meanwhile, the language substitutes a subroutine or function call at each appropriate spot. The end-user's code is none the wiser. In fact, "they neither know nor care!"

Since an "interface" is supposed to be "your class's contract with the public," I would strongly encourage you to simply give them ... "properties." Don't tell them how it actually works, and don't require them to be party to it. ("You want a property? Hey, you got it!" And that's all you need to know. Pay no attention to the little man behind the curtain, who you can't see anyway.)

"Getters and Setters" are properly part of the "implementation." The stuff that goes on behind the curtain. The messy details that they will never have to bother their silly little heads about . . .