Reputation: 71
I have got a question in my finished interview that I wouldn't get the right answer.
Assume that we have 3 class, Base, Derivate1 and Derivate 2, Their relations are shown as follow
public class Base {...}
public class Derivate1 extends Base {...}
public class Derivate2 extends Derivate1 {...}
Then we found out that Derivate1 and Derivate2 are unnecessary for our program, but their method implementations are useful. So, how can we get rid of Derivate1 and Derivate2 but still keep their methods? In this case, we are expecting that user cannot create new instance of Derivate1 and Derivate2, but they still can use the method implementations in Derivate1 and Derivate2. Of course, we are allow to change the code in class Base.
What do you think about that and can you tell what they're actually asking?
Thanks a lot.
PS.
There are abit of hints from my interviewer when I have discuss the them.
The derivate classes are from the third party. They are badly design, so we don't want our client to use them, which means user should not allow to create instance from the derivate classes.
The derviate class contains overriding methods that are useful for the Base class, we can create method with different name in the Base to implement those useful behavious in derviated classes.
And thank you for all those interesting answers...
Upvotes: 2
Views: 781
Reputation: 895
Since you do not own the derivate classes you cannot delete them. The base class is all yours so you have control. The client is yours so you have control there. So the best way would be to have an all new class that is exposed to the client. This class essentially creates the derivate instances (note: your client isn't dealing with it anymore) and use their useful functions.
Upvotes: 0
Reputation: 803
From the hints they gave you, I think the answer was adapter pattern, which sometimes is used for legacy code.
You can have a look at it here:
http://en.wikipedia.org/wiki/Adapter_pattern
Upvotes: 2
Reputation: 13564
We could do two things:
Derivate1
and Derivate2
to Base
, when this makes sense (as noted above)Derivate1
and Derivate2
abstract
: this prevents instantiation, but not inheritanceUpvotes: 1
Reputation: 114787
(non-static) Methods from Derivate1
and Derivate2
are only usable if we create Derivate1
and Derivate2
instances. Creating a Base
instance (like with new Base()
) will not give access to (non-static) method declared in subclasses.
So to keep the methods, one could add (refactor) them to the Base
class. If we just don't want public constructors for the sub classes but keep the object graph as it is, on could use a Factory pattern to have them created on demand. But even in this case one had to cast the object returned by the factory to either Derivate1
or Derivate2
to use the (non-static) methods.
I guess I know what they wanted to hear, the common recommendation 'favour composition over inheritance'. So instead of saying Derivate1 is-a Base you do a Derivate1 has-a Base:
public class Derivate1 {
private Base base;
// ... more
}
public class Derivate2 {
private Derivate1 derivate1;
// ... more
}
No more inheritance and both Derivates can still use methods of their former super classes.
Upvotes: 2
Reputation: 49321
The first obvious thing is that each of the classes in the hierarchy is concrete - in general, either a type should be abstract, or a leaf type. Secondly, there isn't quite enough information as to what these methods are - if they override something in Base or Derived1, you can't move them into Base; if they are utility methods which would apply to any Base then they might be moved into Base, if they are independent of Base then then they could be moved into a helper class or a strategy.
But I would question the idea that a class is not required but its behaviour is - it sort of implies that the questioner is looking at designing an ontology rather than an object oriented program - the only reason a class exists is to provide behaviour, and coherently encapsulating a useful behaviour is a sufficient and necessary condition for a class to exist.
Upvotes: 0
Reputation: 165242
Simple refactoring:
Derivate1
and Derivate2
into Base
.Derivate1
and Derivate2
classesDerivate
objects as Base
, you should be good)Even if you have more subclasses such as Derivate3
and Derivate4
down the hierarchy, there should be no problem in having them extend Base
.
Upvotes: 2
Reputation: 1535
If it makes sense, you can directly include these methods in your base class. But it depends on the meanings of this class, of course. If it is possible, you could ty to use static methods in a utility class. By the way, your developers will have to change their use of the API in both cases.
Upvotes: 0