I'm using an interface in java, that communicates with PureData. In order to do so, my classes have to extend a given class MaxObject. While designing my class, which is a cirular buffer, I discovered that I need to extend java's Iterator class. So I have to extend two classes at the same time.
My guess is that the only solution is to create two different classes and let one of them be a component of the other one. But, is it the only solution? Is it the best one?
Further, whenever I find myself needing inherit from two classes, is it a because of a bad design? Is there a design pattern to solve this class?
Thank you
Iterator is not a class, it's an interface. As such, you don't extend it, you implement it. You can implement any number of interfaces - the only limitation is that you can only extend one class.
In your case:
class MyClass extends MaxObject implements Iterator<Type>
edit: I should have read closer what's being extended. EboMike is right, you don't need to extend the Iterator class.
Sounds like the DDofD: http://javacodeonline.blogspot.com/2009/08/deadly-diamond-of-death.html
Iterator is an interface. From a theoretical point of view there's nothing against extending MaxObject and implementing Iterator.
Due to a lack of information I cannot say if it's a good idea to do this, but I have a bad feeling.
Related
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.
I want to create an interface for collision detection that contains a list of collidable objects but j know that all members of a interface are constant. How would I go about this. I Cannot substitute this for an abstract class because the class I'm creating already inherents from a parent class.
You're trying to put concrete implementation details within an interface, and to do this is a misuse of inheritance. The correct solution is to simply not do this. Use interfaces for redirection, to loosen coupling, to abstract pure behavior, and to help use design patterns, but not to implement concrete aspects of your program.
Can we say that multiple inheritance in Java is made possible by implementing interfaces?
With default methods in interfaces in java8 we will have multiple inheritance :)
No. An interface defines how an implementation should communicate with the outside world you do not define any behavior. You can of course implement multiple interfaces but that doesn't mean that you have multiple inheritance, just that the class implementing the interfaces can appear as different things.
No. You aren't really inheriting anything. You are specifying behavior.
It's not really "multiple-inheritance", you are simply outlining what the class should be able to do.
About as close a "multiple-inheritance" goes I suppose would be interfaces extending interfaces, really.
Nope. When you implement an interface, you are simply making a "promise" to implement certain methods in said class. When you extend another class, you inherit its methods and instance variables. Two completely separate things.
Is it possible to make a child class that extends ArrayList? If so, how?
You can extend any class that is not final in Java. Having said that, you should avoid inheritance if there is no true is-a relationship. Consider composition for reuse. Read about Liskov substitution principle
Yes you can.
public class MyArrayList<E> extends ArrayList<E>
{
}
However, I'm not sure why you would want to do this.
As many other have said, yes, you can extend class ArrayList, but it is not something that you should normally do; it is not considered good practice in Java.
I'm mainly a Java programmer, but the past months I've also been working on C# code. It seems like it's a common idiom in C# to extend the standard collection classes if you need a collection of a specific type (I actually don't know if it is a common idiom in general - at least the people who wrote the code I'm working with are doing this all the time).
So if they have a class Person and they need a list of persons, they'd create a class PersonList that extends the C# equivalent of ArrayList<Person>.
The common idiom in Java would just to use ArrayList<Person> if you need a list of Person objects and not to create a specific subclass for this.
I'd advise you to stick to the common Java way of doing things, and not create your own subclasses of ArrayList or other collection classes.
ArrayList is not final class and it provides public constructor, so technically it can be extended.
But best practice is delegate rather than extend.
See: Decorator pattern
Just try it out. The class is not final, it's constructor is public, so you can. However, it's probably no good idea for a beginner.
Most of the time, it's no good idea for anyone. Imagine you add some functionality and get ExtList1 extends ArrayList. A college of yours adds a different independent functionality, so you have ExtList2 extends ArrayList. Now you want them both at once and you're out of luck.
Or you need the same feature with a different base list implementation (maybe LinkedList, though it's virtually always wrong to use it). Again, out of luck.
These are all cases when delegation wins. It needn't be more verbose when someone has created the base already.
I'd only inherit from ArrayList, if there was a very good reason for doing exactly this. Maybe some really extreme performance requirements based on proper JMH benchmarks.
As others said, extending java lang data structures is a very bad idea.
However, if you have some logic you want to isolate in a collection class, I would suggest bellow solution:
public class ProductCollection{
ArrayList<Product> products;
public Product getByCode(String code) {
// ... your logic goes here.
}
}
Is there a reason to use a 100% abstract class and not an interface ?
Can you give me a good example when to use both so I can grasp the concept a little?
Update:
100% Abstract class -> abstract class with only abstract methods.
I'm curios if there are differences between php and java regarding this aspect.
Update2:
Even if I understand most of the reasons I'm more interested in the conceptual more than technical reasons.
If by "100% abstract class" you mean "abstract class with no concrete methods", then I can think of a reason: visibility.
You can define an abstract method to be protected, and hence not part of the public API of the class. However, that seems like an odd design.
Another thing that came to my mind is when you expect to add common functionality to the base class - i.e. if it is likely to have some utility methods shared by all implementors, but these methods are not implemented.
Another thing - instance variables. You can have inheritable instance variables in the abstract class.
The one case where an "100% abstract class" may be advantageous over an interface is in places where API stability is a key concern.
If you write an API where other people are expected to implement your interface you have to stick to the interface. You can't add any methods to the interface later on because that would break all clients (you would have to work around this by implement a second interface and let your code check againt the usage with instanceof checks and provide an fallback).
If you realize the same with an class you can add (non abstract) methods later on without breaking the client.
Next to visibility, another reason could be to be able to specify a certain Constructor you want all implementations to implement, or define a certain property. But in general, I agree with Alexander that a 100% abstract class isn't a good idea. I would prefer an interface in most cases unless there's a very good reason not to use an interface.
I personally think the difference as conceptual more than technical. For instance it would be bad idea to have an interface called "Human" and implement them on Male and Female. It would make more sense to make the Human as class.
You can implement multiple interfaces and you should see interfaces as add-ons.
I'm not quite sure how to answer this conceptually anymore, but in practice I use interfaces for the following reasons:
To indicate different classes have a shared interface: that you can manipulate them / use them in the same way
You can implement multiple interfaces, but only extend one class
Reasons for using abstract classes:
To share functionality between similar objects. For example Porshe911 could extend Car, overwrite a few methods and keep the rest.
To write frameworks that people can adapt. For example by leaving a few crucial methods unimplemented and writing the rest of the class to be internally consistent provided you implement those few methods. An example would be a menu class with a single abstract method getMenuItems()
Your example of the 100% abstract class seems senseless to me. As far as I can see that would just make it an interface, with the added restriction that you can have only one.
100% Abstract class isn't good idea. For common structure of child classes uses Interface. For similiar classes with same some methods and not same others more better to use Abstract Class.