Best way to apply inheritance and code reuse

Question

I have a question regarding the best way to structure code for reuse with inheritance in cases, where some methods in the base class does not make sense in the inheriting class. I think this is a general OOP issue and not only peculair to TypeScript...

So basically, in some form of pseudo code, the issue is similar to this:

class BaseClass makesSenseForA makesSsenseForA .... doesnotMakeSenseForA doesnotMakeSenseForA ....

How then to have a Class A inherit BaseClass . Just direct inheritance means that Class A would have member methods that does not really make sense.

Not using inheritance means the things that code would be duplicated in both BaseClass and Class A

Moving the makesSenseForA methods to an external class and have both BaseClass and it's children class depend on this extracted class (ie using composition) does not work in this particular scenario, because the extracted class should actually be seen as A BaseClass .

How really is the best way to handle this kind of OOP modeling situation?

EDIT: For lack of better example, it is like trying to model Human and Cyborg - this two would share a ton loads of similar implementation and hence first thought might be to have Cyborg extends Human ...

But also there would be a ton of implementation that Human has that Cyborg should not have.

Doing away with inheritance means those similar functionality would have to be duplicated in Human and Cyborg`.

And composition also does not work, because if you extract those implementation that are similar into a separate object, that object, and it's method would have a property of Human , and hence should be seen as a Human in our modelling.

Answer 1

Yes, it indeed is a common issue. But your example isn't a very accurate reference to inheritance. We mostly use inheritance not due to common functions. Common functions, to reuse them, can be written as utilities/utility classes. You inherit a class when it is basically a sub-type of the parent class, and we create interfaces for things that are not actual objects but a type. For example:

• Interface: Animal
• Class: Tiger implements Animal
• Class: Goat implements Animal

Note than Animal as such cannot be objectified. Now even though a lot of the functionalities of both classes Goat and Tiger will be common, but neither should extend the other, since a method hunt() will not make sense to the Goat class, and graze() won't make sense for Tiger . For that, we use interfaces. Now, to move common functions in the same class, you can further break this modularity as:

• class Carnivore extends Animal
• class Herbivore extends Animal

No brownie points for guessing what Goat and Tiger will implement now. In case, there are common functions, that you cannot for some reason write in the Animal class, you can write them as a utility. Suppose you have a robotic goat, that has a lot of common functionalities with an actual goat, you do not extend Goat , but move common functions as a utility, say GoatUtilities .

Edit: Someone pointed out that utility classes aren't exactly OOP but procedural... But they can definitely compliment your classes to help them follow OOP the correct way. That's why they're "Utility" classes. So, here's the point that got missed, what I tried to point out basically was how inheritance was being misinterpreted / misused in the given example that was in a way leading to the issue that kinda violated OOP principles. Having a viable object oriented design doesn't imply that you shouldn't use utility classes, because the objective is to apply inhertence and code reuse.

Answer 2

If you're making the method private it will only be usable in that class. If you make it protected it will be usable in all sub-classes too. So the methods that make no sense in Class A should be private, the others should be protected or public.

In java you can learn about this further here .