After all ANY java abstract is an abstract subclass of Object. Sometimes we need to force the subclass to implement some methods, but may already have a pretty well defined hierarchy with concrete classes.
For example: I have a well functioning hierarchy with
Vehicle<--- Car
and now I want to add ElectricCar to this hierarchy.
vehicle<--Car<--ElectricCar.
I also want all the different types of electric cars to implement certain behaviors like getBatteryLife or something-
Why would it be a bad idea to make ElectricCar abstract ?
there's nothing wrong in making it abstract. if your business requires you to make it abstract, it's fine. Like you said, lots of classes in Java lib are abstract and still extending Object.
It's not bad, per se. Not common, but not bad. The only thing I can think of is understandability: if I saw a concrete class Car that I could instantiate, I would normally assume that any child of it was also instantiable, because 99% of code works this way.Then I'd be confused, for a second, about not being able to instantiate an ElectricCar.
It could be argued that this pattern breaks the Liskov Substituion Principle since you can't pass "ElectricCar" wherever "Car" is expected if it's declared abstract (you could pass instances of ElectricCar subclasses of course).
In this particular example, the concrete electric cars (hydrogen powered/plug-in/etc?) I would expect to inherit directly from "Car" since they satisfy an "is-a" relationship and are a proper specialisation of "Car". If you wanted to described some common behaviours and traits they should provide then they should also implement an ElectricCar interface.
It seems what you really want is the ability to inherit from Car (since that is what they are) and share/re-use common implementations of electric car related methods. In this case you are looking at a multiple inheritance problem or a need for mixins, neither of which are directly supported in Java.
Providing an abstract class in the middle of a concrete hierarchy may be one way around this, but it's not pretty.
Personally I would prefer to define an Interface for ElectricCar and then allow the implementing class to define the methods. Then you can share the behavior of getBatteryLife through another mechanism.
I've built some pretty deep hierarchies of Inheritance and I tend to avoid them do to the brittle nature they tend to build up over time. One Base class might make sense, but I would think about how you can compose your object model to share behavior w/o inheritance if possible.
In you example I would say that supposedly the Car class should be abstract (or an interface), too. But there is nothing wrong with the ElectricCar being abstract.
Related
I have the main abstract class that is a base for bunch of classes. Some of them does not need all the fields and methods from the main abstract class, so I have created second abstract class and splitted main abstract class into two parts. The main abstract class contains, for example, a, x fields and their getters/setters, the second abstract class inherits from the main and contains additional b, c fields and their getter/setters. There are simple classes that are inheriting from the main class,and more complicated are inheriting from the second class. I want to create objects of each class as instances of the main class. Is it right way to do that? I have to type check and cast when I want to use methods from the second abstract class. It makes my code complicated. How can I solve this problem?
MainAbstractClass ---> SecondAbstractClass ---> MyComplicatedClasses
|
|
V
MySimpleClasses
One of the OO principles is Favor composition over inheritance.
This means that common behavior is not provided through base classes but via Component classes which are passed in via dependency injection (preferably as constructor parameters.
The answer depends on your actual needs.
You can instead choose to store the extended abstract class specific fields in a class that does not implement your base class and make it a member of more complicated classes.
You can choose to keep everything in a single base class and nothing forces you to use all the fields of an interface in every class that implemented your interface.
You can also keep using your approach but since you store the classes as an instance of the base class, it will be hard to read.
I believe that if you think code does not look very good, it is probably not good. However, there is usually no single answer to this kind of design questions and the best solution is relative to your preferences.
I think this need of type cast is a smell of fragile design. Here when we assume MyComplicatedClass ISA KIND OF MainAbstractClass as shown by TJ Crowder then object must behave as MainAbstractClass (meaning it can honor only API of MainAbstractClass). If it expects special treatment as MyComplicatedClass its false commitment and will need Casting. Such casting (by identifying type) goes against OO principles and kills polymorphism. Later this will end up in Ladder of InstanceOf and type casts as in the scenarios rightly pointed out by T.J. Crowder.
I would suggest readdress the design. e.g. though our all user defined type instances ARE KIND OF Object, but we use Object API only for methods defined in Object class. We do not use Object o = new MyClass(). There are occasions in frameworks or like Object.equals() method where type cast is needed as API is defined before even concrete extension is written. But it is not a good idea for such simple complete (without open hooks for extensions) Hierarchies.
I've been wondering what is the difference between them? Is it only in this: abstract class declares what an object is and interface says what object can do? Or there is something more deeper? Thanks.
Whether it can have fields, whether it can have a constructor, whether any of those methods can be protected/package-private/private, whether subtypes can inherit from other abstract classes/interfaces...that about covers it.
The statement "abstract class declares what an object is" refers to the rule that says that a class may inherit from a base class if it has an "is a" relationship to the base class. So, a Sedan may inherit from Car because a Sedan "is a" Car. But that's only part of the story. Usually, we define abstract base classes to inherit from when we want the abstract base class to contain some functionality that restricts derived classes in what they can do, often by exposing final methods which cannot be overridden. So, a hypothetical mail delivery abstract base class may offer a public final prepareAndSend() method which invokes abstract overridables on itself called stuffEnvelope(), lickEnvelope(), mailEnvelope(), in that order. The derived class may override those methods, but it has no power to change the order in which they will be invoked because prepareAndSend() is final. You can't impose such restrictions with interfaces.
Interfaces, on the other hand, describe "capabilities" or "aspects" that an object may have. An object may have many different capabilities, so it may implement many interfaces.
Note that it may seem that the "is a" relationship can apply to interfaces, but it either only happens in certain contrived examples, or it is an illusion caused by the liberal syntax of the English language; it is not generalizable, in many cases it is not even factual, and that's the reason why there is no rule that says that an object should have an "is a" relationship with each interface that it implements.
So, someone may of course make an "ICar" interface, there is nothing wrong with that, in which case there will inevitably be something that "is a Car", but what you are more likely to see is interfaces like "IDrivable", "IInsurable", "ITaxable", "IFuelConsumer", etc. all of which describe traits. The fact that you can then say "a car is a taxable" is a fluke of the English language; a car does not actually bear an "is a" relationship with "taxable" because "taxable" is not even a thing. So then, whoever came up with that "ICar" usually just meant it as a convenience to combine all the characteristics of a car into one common interface.
In Java, there are no pure abstract classes. A class that declares only abstract methods has concrete methods also, because it is a subclass -- directly or indirectly -- of the concrete Object class.
An interface is a better choice for defining an abstract API. Java allows classes to extend at most one class, but implement multiple interfaces.
From the Java tutorial Abstract Methods and Classes (line breaks added):
However, with abstract classes, you can declare fields that are not static and final, and define public, protected, and private concrete methods.
With interfaces, all fields are automatically public, static, and final, and all methods that you declare or define (as default methods) are public.
In addition, you can extend only one class, whether or not it is abstract, whereas you can implement any number of interfaces.
The tutorial also recommends cases when an abstract class or interface are desirable. Paraphrased, it recommends abstract classes when you want to share code or non-static, non-final fields, or use access qualifiers other than public. Usually none of these will apply to a pure abstract class.
It recommends interfaces when you want to specify an API that may be implemented by multiple unrelated classes, or want to take advantage of multiple inheritance of interface types.
In object oriented programming, I have read that you should program to an interface not an implementation but do they mean literal interfaces (no shared code at all)?
Is it okay to program to an abstract base class that would have been an interface except that there were variables in this "interface" that all sub-classes were expected to have? Replicating a variable across sub-classes would have been an inconvenience because if I changed the name of one of the variables in one of the sub-classes I would have to change the name of that variable in all of the sub-classes.
In following the principle of "program to an interface not an implementation", is this okay or would you create another interface on top of the abstract base class and program to that interface?
You want to program to interfaces because it means lower coupling. Note that interfaces in Java are more flexible since they can be implemented by a class anywhere in the class hierarchy unlike abstract classes (as a result of single inheritance). Such flexibility means that your code is reusable to a higher degree.
The important point of "programming to an interface not an implementation" is that of the general principles mentioned above, even if they might cause some minor inconveniences.
Also, even if you program to an interface, you can always implement said interface (or parts of it) by means of abstract classes if you'd like, achieving both low coupling and code reusability at the same time.
It's always okay to program to abstract or even concrete classes, however it's better if you can avoid it.
This discussion might be helpful or this one and of course this one.
Note: C++ doesn't have interfaces. You might argue it doesn't need them.
you should program to an interface not an implementation but do they mean literal interfaces (no shared code at all)?
Possibly. Where it makes sense to do this, it can work very well. Note: in Java interfaces can have code as well.
Is it okay to program to an abstract base class that would have been an interface except that there were variables in this "interface" that all sub-classes were expected to have?
If you need fields in the implementation an abstract class can make sense. You can still use an interface as well.
Replicating a variable across sub-classes would have been an inconvenience because if I changed the name of one of the variables in one of the sub-classes I would have to change the name of that variable in all of the sub-classes.
This is where using an IDE helps. You can change a field, class, method name in all your code with one action.
is this okay or would you create another interface on top of the abstract base class and program to that interface?
You can code your implementation to an abstract class, but the users of that class should be using an interface if possible.
e.g. HashMap extends AbstractMap but implements Map. Most people would use Map not AbstractMap
In an interview it was asked to me to justify when to choose interface and when to choose abstract classes and in which conditions you will choose out of the two only one.. I have come up with my analysis for interface and that is...
Interface is best choice for Type declaration or defining contract
between multiple parties.
If multiple programmers are working in different modules of a project they still use each others API by defining interface and not waiting
for actual implementation to be ready.
This brings us a lot of flexibility and speed in terms of coding and
development. Use of Interface also ensures best practices like
"programming for interfaces than implementation" and results in more
flexible and maintainable code.
But I don't have strong reasons to justify the abstract classes, Please advise..!
Abstract classes are used to group a number of concrete classes under one entity.
For example, take the abstract class Animal.
Animal is not something concrete. it's a family of, well, animals. but they all share certain aspectes, for example, each has a speak() option (well, except fish and sort). but each one implements it differently. this way you can override just the methods which are not the same, for example sleep() or breath() are common (again, fish are differnet :) ).
Interfaces on the other hand are more direct definition of an 'action'. That's why most (if not all) the interfaces in Java ends with 'able' (Comprable, Serializable...)
By implementing the interface, you're telling other programmers or who ever uses your code that this class can do this and this.
A dog, for example, is not, Animable.
Basically, to sum it up, I think that the best definition is this.
Use abstract classes when you have a class that A is kind of B and interface when A can do B.
Hope that's help.
Abstract classes are used when you want to provide partial implementation.
Abstract classes can have default behaviour(implementation) if is required, interfaces cannot.
An abstract class can provide default behaviour for ALL methods or no methods whereas interfaces cannot.
Abstract classes can have state shared with all subclasses, interfaces don't specify state.
You can implement multiple interfaces, you can only extend one (abstract) class.
An interface declares a contract with whatever implements it. It's a guarantee that the class will contain the methods in the interface.
An abstract class is similar in that anything that subclasses it will also have to implement the abstract methods, but you can also have working methods with code in them.
I use interfaces a lot for callbacks with Android programming. Abstract classes I use a lot if I have a lot of similar data to display and just want small changes to implementation. Use an abstract class to cut down on repeated code while still having different implementation.
You are correct on your definition of interfaces.
Abstract classes should serve a completely different purpose. As an example, let's say you are implementing several classes for an animal simulator. 'Animal' defines several behaviours that could already have a basic implementation, but is not itself something that would make sense to have instantiated. Likewise for 'Mamal', a bubclass of 'Animal'. Only a subclass 'Tiger' would not be abstract, but most of what a tiger does that's not tiger specific would be implemented in it's abstract superclasses.
1. If speaking generally, An Abstract class will be needed when we need to force down some features on the Sub-Class from Super-Class, letting the Sub-Class to have the flexibility to add other functinality.
Eg:
Let Car be the Abstract Super-Class, which has 4 Tyres, 1 Steering ,etc...
Now the Sub classes like Santro i10, Maruti-800, Mahindr Bolero etc are Sub classes,
but they need to have 4 Tyres, 1 Steering to be called a car, not they can have a radio or not as an additional feature.
2. Interface was introduced in java, because there is no Multiple Inheritance.
3. Interface is more about providing a role.
Eg:
Let Dog be the Super-Class.
Wild Dogs and Pet Dogs are Sub-Classes.
Wild Behavior and Pet Behavior are Interfaces
Now as both Wild Dog and Pet Dog are dogs, but with different behavious. Then they must implement the Wild Behavior or Pet Behavior respectively
you'd want to use an abstract class when you want your classes to only implement the methods if the situation would call for them.
an example would be if you had a super class vehicle and you wanted your sub-classes to give you number of wheels if they have them. You wouldn't need them if they were boats so the contract would force you to implement still while you could just out right ignore it for your abstract class.
In java, is there ever a case for allowing a non-abstract class to be extended?
It always seems to indicate bad code when there are class hierarchies. Do you agree, and why/ why not?
There are certainly times when it makes sense to have non-final concrete classes. However, I agree with Kent - I believe that classes should be final (sealed in C#) by default, and that Java methods should be final by default (as they are in C#).
As Kent says, inheritance requires careful design and documentation - it's very easy to think you can just override a single method, but not know the situations in which that method may be called from the base class as part of the rest of the implementation.
See "How do you design a class for inheritance" for more discussion on this.
I agree with Jon and Kent but, like Scott Myers (in Effective C++), I go much further. I believe that every class should be either abstract, or final. That is, only leaf classes in any hierarchy are really apt for direct instantiation. All other classes (i.e. inner nodes in the inheritance) are “unfinished” and should consequently be abstract.
It simply makes no sense for usual classes to be further extended. If an aspect of the class is worth extending and/or modifying, the cleaner way would be to take that one class and separate it into one abstract base class and one concrete interchangeable implementation.
there a good reasons to keep your code non-final. many frameworks such as hibernate, spring, guice depend sometimes on non-final classes that they extends dynamically at runtime.
for example, hibernate uses proxies for lazy association fetching.
especially when it comes to AOP, you will want your classes non-final, so that the interceptors can attach to it.
see also the question at SO
This question is equally applicable to other platforms such as C# .NET. There are those (myself included) that believe types should be final/sealed by default and need to be explicitly unsealed to allow inheritance.
Extension via inheritance is something that needs careful design and is not as simple as just leaving a type unsealed. Therefore, I think it should be an explicit decision to allow inheritance.
Your best reference here is Item 15 of Joshua Bloch's excellent book "Effective Java", called "Design and document for inheritance or else prohibit it". However the key to whether extension of a class should be allowed is not "is it abstract" but "was it designed with inheritance in mind". There is sometimes a correlation between the two, but it's the second that is important. To take a simple example most of the AWT classes are designed to be extended, even those that are not abstract.
The summary of Bloch's chapter is that interaction of inherited classes with their parents can be surprising and unpredicatable if the ancestor wasn't designed to be inherited from. Classes should therefore come in two kinds a) classes designed to be extended, and with enough documentation to describe how it should be done b) classes marked final. Classes in (a) will often be abstract, but not always. For
I disagree. If hierarchies were bad, there'd be no reason for object oriented languages to exist. If you look at UI widget libraries from Microsoft and Sun, you're certain to find inheritance. Is that all "bad code" by definition? No, of course not.
Inheritance can be abused, but so can any language feature. The trick is to learn how to do things appropriately.
In some cases you want to make sure there's no subclassing, in other cases you want to ensure subclassing (abstract). But there's always a large subset of classes where you as the original author don't care and shouldn't care. It's part of being open/closed. Deciding that something should be closed is also to be done for a reason.
I couldn't disagree more. Class hierarchies make sense for concrete classes when the concrete classes know the possible return types of methods that they have not marked final. For instance, a concrete class may have a subclass hook:
protected SomeType doSomething() {
return null;
}
This doSomething is guarenteed to be either null or a SomeType instance. Say that you have the ability to process the SomeType instance but don't have a use case for using the SomeType instance in the current class, but know that this functionality would be really good to have in subclasses and most everything is concrete. It makes no sense to make the current class an abstract class if it can be used directly with the default of doing nothing with its null value. If you made it an abstract class, then you would have its children in this type of hierarchy:
Abstract base class
Default class (the class that could have been non-abstract, only implements the protected method and nothing else)
Other subclasses.
You thus have an abstract base class that can't be used directly, when the default class may be the most common case. In the other hierarchy, there is one less class, so that the functionality can be used without making an essentially useless default class because abstraction just had to be forced onto the class.
Default class
Other subclasses.
Now, sure, hierarchies can be used and abused, and if things are not documented clearly or classes not well designed, subclasses can run into problems. But these same problems exist with abstract classes as well, you don't get rid of the problem just because you add "abstract" to your class. For instance, if the contract of the "doSomething()" method above required SomeType to have populated x, y and z fields when they were accessed via getters and setters, your subclass would blow up regardless if you used the concrete class that returned null as your base class or an abstract class.
The general rule of thumb for designing a class hierarchy is pretty much a simple questionaire:
Do I need the behavior of my proposed superclass in my subclass? (Y/N)
This is the first question you need to ask yourself. If you don't need the behavior, there's no argument for subclassing.
Do I need the state of my proposed superclass in my subclass? (Y/N)
This is the second question. If the state fits the model of what you need, this may be a canidate for subclassing.
If the subclass was created from the proposed superclass, would it truly be an IS-A relation, or is it just a shortcut to inherit behavior and state?
This is the final question. If it is just a shortcut and you cannot qualify your proposed subclass "as-a" superclass, then inheritance should be avoided. The state and logic can be copied and pasted into the new class with a different root, or delegation can be used.
Only if a class needs the behavior, state and can be considered that the subclass IS-A(n) instance of the superclass should it be considered to inherit from a superclass. Otherwise, other options exist that would be better suited to the purpose, although it may require a little more work up front, it is cleaner in the long run.
There are a few cases where we dont want to allow to change the behavior. For instance, String class, Math.
I don't like inheritance because there's always a better way to do the same thing but when you're making maintenance changes in a huge system sometimes the best way to fix the code with minimum changes is to extend a class a little. Yes, it's usually leads to a bad code but to a working one and without months of rewriting first. So giving a maintenance man as much flexibility as he can handle is a good way to go.