I have an abstract class. I want to extend the abstract class by another abstract class and then implement the extended abstract class. Is it possible .If yes, whether it's a good approach in point of view regarding OOPS?
I'm not sure about Java in particular, but it should be valid.
In terms of OOP, if it makes sense, then run with it. To use some old examples, you might have a Vehicle abstract class and then LandVehicle and FlyingVehicle abstract classes. As long as your example makes sense as an abstract class, then you should be fine.
Yes, it is possible, and I don't see a reason not to use it if you need it (disclaimer: but however there are many ways to misuse this, and to over-complicate things, as with everything in programming usually).
One thing to notice is that the second abstract class doesn't need to implement abstract methods from first class, but the first concrete must implement both.
Yes, you can! One abstract class can be extended by another abstract class
Yes!
But it makes sense only if the abstract subclass adds more functionality (abstract or not).
Otherwise, I don't see the point.
Yes you can do it. And it is good practice if your child class adds more functionality. It allows to move toward specification. Your parent class becomes a more general class and child class a more specific one. And you can implement both as per your requirement.
Related
What is the reason that I can't create a concrete class with abstract methods in it?
Is it enforced just to make sure that no object is created without abstract method definition? or is there another plausible reason for this restriction?
An abstract class is, by definition, incomplete. Therefore, you should not be able to instantiate abstract classes. An interesting side effect of this definition is that you can create abstract classes that have all concrete methods. It's just that you think that your class is incomplete and shouldn't be able to be instantiated.
abstract class in the java constext is defined as the class has at least one
abstract method. And an abstract method is just a not implemented method. This is a design decision that was just copied from c++ where it is exactly the same. The only difference is, that in c++ you do not need to tell the compiler that a class is abstract, the compiler knows it even without you telling it. Why this design decision was made in c++ I can't tell you, but having it eleminates a complete class of errors. The error that a method of a class get's called, when the method is not implemented in that sub class.
You are right, the reason is to prevent creating an object with no implementation for a method or more.
Because when you create an Abstract class you are in the middle of your abstractions level. i Mean you have some questions about class responsibilities or this class must to do something but they dont care how, partially. If you dont wanna have an implemented method, you must to create an interface.
In my opinion the answer is in the class responsibilities and abstraction and not in the technology scope.
I want to turn a class I made into an abstract class and get another class to extend it. This is because the class (particle) is leaning heavily on the class I want to make abstract (vector).
I am not sure how I will use all those objects I instantiated with the new keyword or if it will totally mess things up. I am willing to try it to learn something about using the abstract classes in my own example but if anyone can help me understand what I am doing that would be great!
if your new class depends on vector then rather than inheriting it try composition ...
so lets say u want to make ur own Queue then its not good idea to inherit from vector rather have a data member of type vector .
this has many advantage over inheritance . If u need to change the container to some other say set u do not have to worry about changing interface. You still will have some add and remove interface to your class. So client code will be independent of the container you are using to generate Queue.
Just on side notes : Consider using composition over inheritance. And look at some design patterns and try understanding when you need composition and when u can not avoid inheritance.
from wht I understand you are trying to convert class MyClass to abstract class AbstractMyClass
So, If you convert MyClass to an abstract class all the statements like
AbstractMyClass myClass=new AbstractMyClass();
will give you an error as you cannot make an instance of an AbstractMyClass.
Also, if the situation is
abstract class AbstractMyClass
{
}
class ConcreteMyClass extends AbstractMyClass
{
}
then do can do something like
AbstractMyClass abstractMyClass=new ConcreteMyClass();
or the usual
ConcreteMyClass concreteMyClass=new ConcreteMyCLass();
Inheritance : is a relation. More importantly the interface of base class and sub class should be same. Here u do not want client code to add new element using push_back()(for C++) but a mothod like add().So interface is different, a clear indication of wrong use of inheritance.Composition : has a and also "implemented in terms of". This is from Scott Mayer in effective C++. As with your case, u want implement a new DataStrucutre in terms of some thing. So composition is what you need. Now derived class does not need to have same interface. In general if you find interface to be same its more like inheritance and if not composition. There are tons of other advantage of compositon on inheritance. Just google or pick any good design book.
I am going through some Java code and I see lots of abstract classes which contain nothing in them.
For eg. something like this -
public abstract class Processor
{
}
They have concrete implementation classes though. In what situations would such abstract classes make sense?
IMO, an abstract class is preferred over an interface when you want to create a base class with behaviors and state common to all the subclasses. I am not sure of any situation where an empty abstract class would be more useful than an interface. Usually, the marker interfaces are the ones that are empty.
Abstract classes are used when you have some logic which would be common to all possible implementing classes.
Writing an Abstract class with nothing inside and different classes extending it is pretty much useless.The only difference is that you can use the same handle for all the concrete classes.
One of the situation would be, if you don't want your class instantiated using new keyword, then you can define it is abstract.
In some libraries, they will look for implementation of these marker abstract classes using reflection. Also this is kind of a documentation for your code by abstract class name itself.
I inherited some legacy Java (1.4) code and this design decision appears regularly. I can't understand if there's any purpose or reason to it.
public interface SoapFacade extends iConfigurable{ }
public class SoapFacadeBase implements SoapFacade{
...
}
public class SoapFacadeImpl extends SoapFacadeBase implements SoapFacade{
...
}
As I understand interfaces (and my experimentation has reinforced), there is no purpose to having both the parent and the child implement the same interface. In this scenario, everything from SoapFacade is implemented in SoapFacadeBase, but the method in iConfigurable is implemented in SoapFacadeImpl. However, that doesn't create a need to have SoapFacadeImpl implement SoapFacade.
Is there something I don't know about interfaces that would give this pattern some purpose or benefit? Are there underlying costs beyond lack of clarity that should drive refactoring it? Or should it simply be refactored for clarity/simplicity?
As I understand interfaces (and my experimentation has reinforced), there is no purpose to having both the parent and the child implement the same interface.
No. Technically, it is completely redundant.
It does however document the fact that you intend SoapFacadeImpl to be a SoapFacade and it ensures that you get a compile error, if you (or someone else) decides to remove implements SoapFacade from the base class.
You see this pattern everywhere in the standard Java Collections API. ArrayList implements List even though its base class (AbstractList) already, does. Same holds for HashSet / AbstractSet and the Set interface.
If you use the interface also as a marker. Class.getInterfaces(); will only return directly instanced interfaces.
I actually find that design pointless. Implemented interfaces, as you stated, are just inherited, so there's no need to copy and paste "implements SomeInterface" on the children classes.
It's not clearer, smarter, or whatsoever...
It is nonsense, don't do it.
Especially in a public API like java collections. It's absolutely nonsense.
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.