Still trying to grasp Polymorphism and Inheritance

[tashimoto]

Let's say I have the following abstract class

abstract class Family {
   private String name;
   
   public void someMethod() {
      //...Some code here to do stuff
   }

}

And some classes that extends my abstract class:

public class Dad extends Family {
   
   public Dad() {
   }

   public void methodA () {
   //...code here to do stuff
   }
    
}

Is it correct to have the Family class hold the String name since all subclasses of Family would have a String name variable? And if so, what is the best way to access that variable?

What I've tried that works:
Setting the variable String name as private and creating a protected method that the subclasses can use to access/set/get the variable.

abstract class Family {
   private String name;
   
   public void someMethod() {
      //...Some code here to do stuff
   }

   protected void setName(String string) {
      name = string;
   }

}

public class Dad extends Family {
   
   public Dad() {
   }

   public Dad(String string) {
      setName(string);
   }

   public void methodA () {
   //...code here to do stuff
   }  
    
}

Setting the String name as protected and directly accessing the variable within the subclass.

abstract class Family {
   protected String name;
   
   public void someMethod() {
      //...Some code here to do stuff
   }

}

public class Dad extends Family {
   
   public Dad() {
   }

   public Dad(String string) {
      name = string;
   }

   public void methodA () {
   //...code here to do stuff
   }
    
}

Which way is better... or is there an even better way?? Are there some guidelines to follow when designing abstract and subclasses that would be helpful??

Previous Post:
setting attributes(variables) in an Abstract class

[Zack]

There isn't a better way. It's personal preference. Personally I'd do the second one as I believe in data manipulation over getters and setters. A lot of people will tell you that getters and setters are the best way to do things.

Here's the best guideline I can give you: Make your code understandable, easy to read, work properly, and allow for easy manipulation. This means that you (and anyone you're working with) can read and modify your code easily without having to struggle to understand what it does.

[Fubarable]

As a side note, I'm finding the thrust of most articles I have read lately being towards marginalizing inheritance and polymorphism in favor of composition. There's a place for both, but many say you should do more of the latter and less of the former.

[Zack]

I'm finding the thrust of most articles I have read lately being towards marginalizing inheritance and polymorphism in favor of composition.

Do you have a link to said articles, or can you elaborate on said subject matter?

[tashimoto]

Thank you both for your responses!

Here's the best guideline I can give you: Make your code understandable, easy to read, work properly, and allow for easy manipulation. This means that you (and anyone you're working with) can read and modify your code easily without having to struggle to understand what it does.

Will do! (or at least try my hardest too!)

As a side note, I'm finding the thrust of most articles I have read lately being towards marginalizing inheritance and polymorphism in favor of composition. There's a place for both, but many say you should do more of the latter and less of the former.

Would one of my examples be better than the other in favor of composition? Or could you give me a better code example than mine of what might be in favor of composition over inheritance and polymorphism?

[JosAH]

As a side note, I'm finding the thrust of most articles I have read lately being towards marginalizing inheritance and polymorphism in favor of composition. There's a place for both, but many say you should do more of the latter and less of the former.

Inheritance was/is heavily overrated; in the '80s when OOP went mainstream people liked the 'miracle' of inheritance so much that they forgot that it heavily breaks encapsulation, something we all love so much. Later, when the dust settled and we all found some 'idioms' we saw that composition could also do the job while preserving encapsulation. IMHO OOP isn't the one size fits all yet, I'm waiting for another miracle to be invented ;-)

kind regards,

Jos

[Zack]

IMHO OOP isn't the one size fits all yet, I'm waiting for another miracle to be invented ;-)

I think until they invent computer programs that read your thoughts and put them to code, there will be no more miracles. OOP is as close as I think we'll ever get to "miracle".

[Fubarable]

... I'm waiting for another miracle to be invented ;-)

It's here!


Long live functional programming! Long live Scala!

... until the next programming trend/craze comes along, that is ...

[gcalvin]

Here's a good article on the issue:

Composition vs. Inheritance

-Gary-

[JosAH]

I think until they invent computer programs that read your thoughts and put them to code, there will be no more miracles. OOP is as close as I think we'll ever get to "miracle".

Ken Thompson once said that he couldn't imagine more than a hundred computers in total in the households. (It could've been somebody else); you sound like Ken here ;-)

kind regards,

Jos

[tashimoto]

... we saw that composition could also do the job while preserving encapsulation.

OK. So are both you(Jos) and Furbarable saying that you prefer the protected getter and setter methods over making the instance variables protected and reachable with the dot operator??

I just re-read a section on Encapsulation and it talked about using the setter/getter methods to protect the instance variables such that they could not be changed to a value that was inappropriate for what-ever their usage might be.

Is that what you both are referring to when you say composition over inheritance??

[JosAH]

It's here!


Long live functional programming! Long live Scala!

... until the next programming trend/craze comes along, that is ...

Nah, Scala isn't that revolutionary; it has all been done before in Lisp decades before ...

kind regards,

Jos (<--- likes functional programming (a lot!))

[Fubarable]

OK. So are both you(Jos) and Furbarable saying that you prefer the protected getter and setter methods over making the instance variables protected and reachable with the dot operator??

I can't speak for Jos, but I'm not saying that, and I don't see him or I even discussing it here, but rather we've been discussing the initial over-use of inheritance and the subsequent backlash, a related but somewhat hijack discussion -- sorry. Myself, I've used both getter/setter and protected at different times when I've felt one was better suited than the other, but having said that, I don't use inheritance all that much any more (hence our other discussion).

I just re-read a section on Encapsulation and it talked about using the setter/getter methods to protect the instance variables such that they could not be changed to a value that was inappropriate for what-ever their usage might be.

setter and getter doesn't offer much protection but does allow you to filter mutation events and monitor accessor (setting) events.

Is that what you both are referring to when you say composition over inheritance??

No. Best for you to read the article that is linked in Gary's post above.

[JosAH]

I can't speak for Jos, but I'm not saying that, and I don't see him or I even discussing it here, but rather we've been discussing the initial over-use of inheritance and the subsequent backlash, a related but somewhat hijack discussion -- sorry. Myself, I've used both getter/setter and protected at different times when I've felt one was better suited than the other, but having said that, I don't use inheritance all that much any more (hence our other discussion).

If I were holier than the pope I'd say, yes, use getters and setters even in subclasses because breaking encapsulation is ABT (A Bad Thing (tm)). If the evil world breaks encapsulation we're all screaming on the top of our lungs how bad such a thing is. But I'm not holier than the pope, I'm just an old hacker so my code is sprinkled with protected member variables that I use directly all over the place in subclasses. Until I break my own encapsulation (I simply add another restriction in the superclass) and then I become holier than any pope whatsoever whereever temporarily; but that disappears again ... I don't have an absolute opinion about this matter. I think C# did a nice job here, but I don't like C# much for a lot of other reasons.

kind regards,

Jos

[gcalvin]

I would advise using private instance variables and calling getters and setters. I would say by the time you have good reason to do otherwise, you'll know better than to take advice from me anyway.

-Gary-

[tashimoto]

No. Best for you to read the article that is linked in Gary's post above.

Ok, I read the post. I have a few questions pertaining to it, but I'm going to read more about interfaces first.

Thanks to all for your responses!!