LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 06-02-2017, 07:42 PM   #1
QueenSvetlana
LQ Newbie
 
Registered: Jun 2017
Posts: 11

Rep: Reputation: Disabled
Interfaces and Getters


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.
 
Old 06-02-2017, 08:36 PM   #2
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,455
Blog Entries: 4

Rep: Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918
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.

Last edited by sundialsvcs; 06-02-2017 at 08:38 PM.
 
1 members found this post helpful.
Old 06-02-2017, 11:07 PM   #3
QueenSvetlana
LQ Newbie
 
Registered: Jun 2017
Posts: 11

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sundialsvcs View Post
Frankly, I have no idea what you mean by "code smell."
It's just another way to say bad practice.
 
Old 06-03-2017, 07:37 AM   #4
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,455
Blog Entries: 4

Rep: Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918
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.

Last edited by sundialsvcs; 06-03-2017 at 07:38 AM.
 
Old 06-03-2017, 10:01 AM   #5
QueenSvetlana
LQ Newbie
 
Registered: Jun 2017
Posts: 11

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sundialsvcs View Post
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?

Last edited by QueenSvetlana; 06-03-2017 at 10:02 AM.
 
Old 06-04-2017, 08:11 AM   #6
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,455
Blog Entries: 4

Rep: Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918
Quote:
Originally Posted by QueenSvetlana View Post
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.)
 
Old 06-08-2017, 03:17 PM   #7
Laserbeak
Member
 
Registered: Jan 2017
Location: Manhattan, NYC NY
Distribution: Mac OS X, iOS, Solaris
Posts: 508

Rep: Reputation: 142Reputation: 142
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;

Last edited by Laserbeak; 06-08-2017 at 03:30 PM.
 
Old 06-08-2017, 07:25 PM   #8
Laserbeak
Member
 
Registered: Jan 2017
Location: Manhattan, NYC NY
Distribution: Mac OS X, iOS, Solaris
Posts: 508

Rep: Reputation: 142Reputation: 142
Quote:
Originally Posted by Laserbeak View Post
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.

Last edited by Laserbeak; 06-08-2017 at 07:33 PM.
 
Old 06-08-2017, 07:27 PM   #9
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,455
Blog Entries: 4

Rep: Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918
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.
 
1 members found this post helpful.
Old 06-09-2017, 02:26 AM   #10
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 3,240

Rep: Reputation: 981Reputation: 981Reputation: 981Reputation: 981Reputation: 981Reputation: 981Reputation: 981Reputation: 981
@OP Could you please provide an example for such an interface?
 
Old 06-09-2017, 06:52 AM   #11
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,455
Blog Entries: 4

Rep: Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918
Not really most every language has them, somehow, and every language is different in exactly how they say it.
 
Old 06-09-2017, 07:40 AM   #12
QueenSvetlana
LQ Newbie
 
Registered: Jun 2017
Posts: 11

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by NevemTeve View Post
@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.

Last edited by QueenSvetlana; 06-09-2017 at 08:27 AM.
 
Old 06-09-2017, 08:37 AM   #13
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian, Arch
Posts: 3,163

Rep: Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370Reputation: 1370
Quote:
Originally Posted by QueenSvetlana View Post
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();
}
 
Old 06-09-2017, 08:40 AM   #14
QueenSvetlana
LQ Newbie
 
Registered: Jun 2017
Posts: 11

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ntubski View Post
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?

Last edited by QueenSvetlana; 06-09-2017 at 08:49 AM.
 
Old 06-09-2017, 02:06 PM   #15
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,455
Blog Entries: 4

Rep: Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918Reputation: 2918
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 . . .

Last edited by sundialsvcs; 06-09-2017 at 02:09 PM.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
3 network interfaces - only works from boot with two interfaces enabled linux_driver Linux - Networking 4 11-26-2014 05:42 PM
ifup: couldn't read interfaces file "/etc/network/interfaces" dobharweim Linux - Networking 1 12-13-2013 11:20 AM
[SOLVED] /etc/network/interfaces configuration for virtual interfaces nonshatter Linux - Networking 4 10-25-2010 06:22 AM
ifup: couldn't read interfaces file "/etc/network/interfaces" debian lenny lorimer73 Linux - Networking 1 08-24-2010 03:47 PM
changing objects parameters via getters inside functions in c++? markhod Programming 1 03-08-2005 05:30 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 11:48 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration