I have a question regarding the implementation of Factory Method in Java and Python.
Suppose I want to model 2 kind of animals - dogs and cats, and expose a factory method for their creation.
As I understood, the best practice implementation on Java will be:
abstract class Animal{
public abstract void sound();
}
public class Dog extends Animal{
public void sound(){
System.out.println("Woof");
}
}
public class Cat extends Animal{
public void sound(){
System.out.println("Maw");
}
}
class AnimalFactory {
//use getShape method to get object of type shape
public Animal getAnimal(String animalType){
if(shapeType == null){
return null;
}
if(animalType.equalsIgnoreCase("Dog")){
return new Dog();
} else if(animalType.equalsIgnoreCase("Cat")){
return new Cat();
}
return null;
}
}
However, on Python it will be something like that (source):
class Animal(ABC):
#abstractmethod
def sound():
pass
class Dog(Animal):
def sound():
print('Woof')
class Cat(Animal):
def sound():
print('Maw')
class AnimalFactory():
#staticmethod
def getAnimal(typ):
targetclass = typ.capitalize()
return globals()[targetclass]()
For my question:
It seems that because I use globals() on Python, I can actually use the AnimalFactory in Python, to create any arbitrary class that within the symbol table on run-time, that accepts zero arguments, in contrast to the Java implementation that checks explicitly the class name.
Is this a bad practice or just a "pythonic way"?
Thanks.
Edit:
I want to clarify why I am not feeling comfortable with the python code:
Suppose I want to write another Factory class for other group of classes, it will have exactly the same implementation as the Animal, and theoretically, I could even use the exact Factory class.
I know I may make some people angry by the following statement, but I feel that the 'duck typing' behaviour, and the lack of formal explicit contract in the code, is the root of the illustrated problem and the Python illnesses in big development projects.
If this is just 'for your own use' then I likely would not be too concerned. However, if it's an interface that 'other people' will use, then in my opinion, something calling itself AnimalFactory has no business returning something that's not an Animal. So, I think a check should be made.
I'd suppose a simple way to do it would be to ensure the result from the globals()[targetclass]() call is an instance of Animal.
Well, it is not seems a bad practice to me. However, I would first check if such targetClass exists, So I won't get an error.
Plus, I'm sure there are many ways to make the java factory method more efficient.
e.g. I could create from advance a list of all classes that extends Animal, then when i get animalType variable, I could find a class from the list that is corresponding to that type.
There are many ways and libraries that help to get such a list. One popular option is Reflections, which you can use it like that:
Reflections reflections = new Reflections("my.project");
Set<Class<? extends Animal>> classes = reflections.getSubTypesOf(Animal.class);
Then just go over the set and chose the wanted class.
Edit:
As for your edit, well, I wouldn't call it illness. Python capabilities are great, but sometimes there are features of "You can, but it doesn't mean you should" kind, I guess these are one of them. You can define for each factory a collection of "legal classes" you can create in that particular factory - such a practice can lower down a bit your concerns :)
Related
I have been studying abstract methods lately and I can't understand why do we need them?
I mean, after all, we are just overriding them. Do you know its just a declaration? Why do we need them?
Also, I tried understanding this from the internet and everywhere there's an explanation like imagine there's an abstract class human then there're its subclasses disabled and not disabled then the abstract function in human class walking() will contain different body or code. Now what I am saying is why don't we just create a function in the disabled and not disabled subclasses instead of overriding. Thus again back to the question in the first paragraph. Please explain it.
One of the most obvious uses of abstract methods is letting the abstract class call them from an implementation of other methods.
Here is an example:
class AbstractToy {
protected abstract String getName();
protected abstract String getSize();
public String getDescription() {
return "This is a really "+getSize()+" "+getName();
}
}
class ToyBear extends AbstractToy {
protected override String getName() { return "bear"; }
protected override String getSize() { return "big"; }
}
class ToyPenguin extends AbstractToy {
protected override String getName() { return "penguin"; }
protected override String getSize() { return "tiny"; }
}
Note how AbstractToy's implementation of getDescription is able to call getName and getSize, even though the definitions are in the subclasses. This is an instance of a well-known design pattern called Template Method.
The abstract method definition in a base type is a contract that guarantees that every concrete implementation of that type will have an implementation of that method.
Without it, the compiler wouldn't allow you to call that method on a reference of the base-type, because it couldn't guarantee that such a method will always be there.
So if you have
MyBaseClass x = getAnInstance();
x.doTheThing();
and MyBaseClass doesn't have a doTheThing method, then the compiler will tell you that it can't let you do that. By adding an abstract doTheThing method you guarantee that every concrete implementation that getAnInstance() can return has an implementation, which is good enough for the compiler, so it'll let you call that method.
Basically a more fundamental truth, that needs to be groked first is this:
You will have instances where the type of the variable is more general than the type of the value it holds. In simple cases you can just make the variable be the specific type:
MyDerivedClassA a = new MyDerivcedClassA();
In that case you could obviously call any method of MyDerivedClassA and wouldn't need any abstract methods in the base class.
But sometimes you want to do a thing with any MyBaseClass instance and you don't know what specific type it is:
public void doTheThingsForAll(Collection<? extends MyBaseClass> baseClassReferences) {
for (MyBaseClass myBaseReference : baseClassReferences) {
myBaseReference.doTheThing();
}
}
If your MyBaseClass didn't have the doTheThing abstract method, then the compiler wouldn't let you do that.
To continue with your example, at some point you might have a List of humans, and you don't really care whether they are disabled or not, all you care about is that you want to call the walking() method on them. In order to do that, the Human class needs to define a walking() method. However, you might not know how to implement that without knowing whether the human is or isn't disabled. So you leave the implementation to the inheriting classes.
There are some examples of how you'd use this in the other answers, so let me give some explanation of why you might do this.
First, one common rule of Object Oriented Design is that you should, in general, try to program to interfaces rather than specific implementations. This tends to improve the program's flexibility and maintainability if you need to change some behavior later. For example, in one program I wrote, we were writing data to CSV files. We later decided to switch to writing to Excel files instead. Programming to interfaces (rather than a specific implementation) made it a lot easier for us to make this change because we could just "drop in" a new class to write to Excel files in place of the class to write to CSV files.
You probably haven't studied this yet, but this is actually important for certain design patterns. A few notable examples of where this is potentially helpful are the Factory Pattern, the Strategy Pattern, and the State Pattern.
For context, a Design Pattern is a standard way of describing and documenting a solution to a known problem. If, for example, someone says "you should use the strategy pattern to solve this problem," this makes the general idea of how you should approach the problem clear.
Because sometimes we need a method that should behave differently in its instances.
For example, imagine a class Animal which contains a method Shout.
We are going to have different instances of this Animal class but we need to implement the method differently in some cases like below:
class Animal:
/**
different properties and methods
which are shared between all animals here
*/
...
method shout():
pass
class Dog extends Animal:
method shout():
makeDogVoice()
class Cat extends Animal:
method shout():
makeCatVoice()
dog = new Animal
cat = new Animal
dog.shout()
cat.shout()
So dog shouts like dogs, and cat shouts like cats! Without implementing the shared behaviors twice
There is a different behavior of shouting in these instances. So we need abstract classes.
Suppose you don't know about implementation and still want to declare a method then we can do that with the help of abstract modifier and making it an abstract method. For abstract method only declaration is available but not the implementation. Hence they should end with ;
Example:
public abstract void m1(); // this is correct
public abstract void m1(){ ... } // this is wrong
Advantage: By declaring abstract method in parent class we can provide guideline to child classes such that which methods are compulsory to implement.
Example:
abstract class Vehicle{
abstract int getNoOfWheels();
}
Class Bus extends Car{
public int getNoOfWheels(){
return 4;
}
}
If you want the short answer, think of this:
You have an abstract class Car.
You implement 2 classes that extend it, Ferrari and Mercedes.
Now:
What if you did one of the following, for the method drive(), common to all cars:
1) changed the visibility of the method,
2) changed the name of the method from driving to Driving,
3) changed the return type, from a boolean to an int
Think about it. It might not seem to make any difference right, because they are different implementations?
Wrong!
If I am iterating through an array of cars, I would have to call a different method for each type of car, thereby making this implementation of abstract useless.
Abstract classes are there to group classes with a common template, that share common properties. One way this helps would be the looping over the array:
Abstract methods ensure that all cars declare the same method,
and therefore, any object of a subclass of Car will have the method drive(), as defined in the abstract class, making the for loop mentioned easy to implement.
Hope this helps.
I know exactly what are the differences between Interfaces and Abstract classes, but why are Interfaces helpful? look at this :
Now imagine abstractions Point and Circle. How would you achieve that a MovablePoint is both Movable and Point? Only interfaces can give you that, and that's what they are here for.
see HERE
An abstract class is good if you think you will plan on using inheritance since it provides a common base class implementation to
derived classes.
An abstract class is also good if you want to be able to declare non-public members. In an interface, all methods must be public.
If you think you will need to add methods in the future, then an abstract class is a better choice. Because if you add new method
headings to an interface, then all of the classes that already
implement that interface will have to be changed to implement the new
methods. That can be quite a hassle.
Interfaces are a good choice when you think that the API will not change for a while.
Interfaces are also good when you want to have something similar to multiple inheritance, since you can implement multiple interfaces.
SO in your scenario only with interfaces you can specify if a MovablePoint is both Movable and Point.
Yes--in this instance you could have, but try looking at the bigger picture, too. I asked the same question when I first learning OOP and interfaces confused me for a long time.
What if you wanted to add the 'movable' methods to an object that wasn't a subclass of Point, let's say 'MovableJPEG' or some such thing. The end result of the move actions would be the same, but you'd have to rewrite the interface for both classes and different methods to handle moving these features around in classes that interacted with Movable objects.
With an interface you pass a any number of Types related only by having a similar interface to the same method because their implementation details are guaranteed to be the same.
Both interfaces and abstract classes allow a programmer to write modular classes.
The advantage of an interface over an abstract class is that it does not carry any predefined methods or properties with it. An abstract class may have things that you do not want implemented inside of your class.
A second advantage is that a java class can only extend one class, but a large number of interfaces.
Interfaces provide more freedom, where an abstract class can influence the internal design of a class. One advantage of an abstract class is code sharing, which is more difficult with interfaces.
you do not have multiple inheritance in java. so multiple classes cant be inherited in same class but multiple interfaces can be implemented
helps in keeping things organized. Like all the things related to DOG is under one interface, all CATs under CAT and so on.
Runtime polymorphisim : with interface u can have superclass reference variable referring different different sub classes. This helps in keeping code clean, improves scalability ( makes possible all those bridge/proxy/factory etc design patterns which otherwise might not have been there).
Imagine someone using your library wants to introduce something other usable, such as a MovableTirangle. If they let this implement Movable, it can be perfectly used with your library.
For example, the library provides a
void move(Movable m, int horiz, int vert) {
int i;
if (horiz >= 0) {
for (i=0; i < horiz; i++) {
m.moveRight();
}
} else {
for (i=0; i > horiz; i--) {
m.moveLeft();
}
}
if (vert >= 0) {
for (i=0; i < vert; i++) {
m.moveUp();
}
} else {
for (i=0; i > vert; i--) {
m.moveDown();
}
}
}
which can be used with all current and future kinds of Movables.
Until now, this is valid for base classes as well, so that doesn't really count.
But, as Java doesn't support multiple inheritance, a class cannot inherit from more than one base class. But it can implement more than one interface, if this should be needed.
Besides, if you had a functional interface (which you haven't, because you have more than one non-default function in it), you could additionally make use of the new lambda feature of Java. That's another thing which doesn't work with abstract classes.
Let you are trying to give as set of similar property to some unrelated classes. Then you may use interface. For example -
<Bounceable>
/ \
Ball Tire
Here Ball and Tire (of a car) are totally unrelated. But both of them are Bounceable. If you want two unrelated class to have the same property then you can use interface.
There is another important use of interface - giving the flavor of multiple inheritance but with more efficiently than multiple inheritance (where there is a common Deadly Diamond of Death problem.). For example you are expecting a Ball should be both Bouncable and Serializeable. Here Bouncable and Serializeable are totally unrelated of each other. Then you can use interface here. Abstract class need to be extended/inherited and in java multiple inheritance is not possible. So we can provide completely unrelated property to a class by using interface.
Conceptual Difference:
I will not list all the differences between using interfaces or abstract classes or when to use each of them, I think you will find a lot of resources in the web and SO talking only about that, as an example: How should I have explained the difference between an Interface and an Abstract class?
To answer you, Yes, you can use only abstract class in your example and you don't have to use an interface
But, there is a Conceptual Difference, Interfaces are not created to expose public behavior, it's a contract for what a class can do.
While abstract classes are parent of a hierarchy to produce children having core structure and providing default behavior.
Analogy with your example:
Conceptually, Movable must be an Interface because it defines what a class that implements Movable can do (can move up, move down, move...) and not how to do it (Circle dosn't move like Rectangle). While your MovableCircle could be an abstract class because we can define methods like : calculateArea(), getRadius(), calculateCircumference(), ... Which is a default behavior for classes that will inherit from it like MovableWheel.
.
IMO while it's correct when people explain interface as a contract i.e. an obligation to implement method signature, i find that they often forget to mention the use of interface as type for the whole group of objects that implement that same interface, and i believe that to be important piece of the puzzle, understanding the usefulness of interface.
Here is a code example (C#) with Cat and Dog classes that uses both interface and absctract class, which hopefully should higlight differences between them.
Assumption 1: both animals say sounds, but these are different sounds (different methods needed)
Assumption 2: both animals can eat, if they are not full (here one method is needed for both animals)
static void Main(string[] args)
{
IanimalBehavior pluto = new Dog();
IanimalBehavior simba = new Cat();
Program.makeAnimals_say_and_eat(pluto);
Program.makeAnimals_say_and_eat(simba);
Program.makeAnimals_say_and_eat(pluto);
Program.makeAnimals_say_and_eat(simba);
Console.ReadLine();
}
static void makeAnimals_say_and_eat(IanimalBehavior animalObject)
{
Console.WriteLine(animalObject.makeSound());
Console.WriteLine(animalObject.eat());
}
interface IanimalBehavior {
string makeSound();
string eat();
}
class Dog : Animal, IanimalBehavior {
public string makeSound() {
return this.GetType().Name + " says: wuf";
}
}
class Cat : Animal, IanimalBehavior {
public string makeSound()
{
return this.GetType().Name + " says: miauw";
}
}
abstract class Animal {
bool _isFull = false;
public string eat()
{
if (_isFull == false)
{
_isFull = true;
return this.GetType().Name + " is now eating";
}
else
{
return this.GetType().Name + " is now too full to eat!";
}
}
}
Notice that animals are declared as interface types:
IanimalBehavior pluto = new Dog();
This will ensure that the method makeAnimals_say_and_eat() can take a parameter type that targets both types of objects (Cat & Dog), so only one method is needed for all animals which is what we want.
static void makeAnimals_say_and_eat(IanimalBehavior animalObject)
{
Console.WriteLine(animalObject.makeSound());
Console.WriteLine(animalObject.eat());
}
The method calls .makeSound() and .eat() from any object that is passed as parameter. Compiler is happy because it knows that any IanimalBehavior type must include both methods because it says so in the contract:
interface IanimalBehavior {
string makeSound();
string eat();
}
on .makeSound() the return value depends on the class type while .eat() is the same for both classes because eat() is declared in absctract class Animal that all animals inherit from.
the ouput of these instructions:
Program.makeAnimals_say_and_eat(pluto);
Program.makeAnimals_say_and_eat(simba);
Program.makeAnimals_say_and_eat(pluto);
Program.makeAnimals_say_and_eat(simba);
are:
Dog says: wuf
Dog is now eating
Cat says: miauw
Cat is now eating
Dog says: wuf
Dog is now too full to eat!
Cat says: miauw
Cat is now too full to eat!
Interface types also gives you the option of storing different objects of similar nature (same interface implemetation) in a single array which you then can iterate.
IanimalBehavior[] animal_list = { new Dog(), new Cat()};
foreach (IanimalBehavior animal in animal_list)
{
Console.WriteLine(animal.eat());
Console.WriteLine(animal.makeSound());
}
I am reading a Java book and stuck again this time thinking about what this whole paragraph actually means:
Interfaces are designed to support dynamic method resolution at run time. Normally, in order for a method to be called from one class to another, both classes need to be present at compile time so the Java compiler can check to ensure that the method signatures are compatible. This requirement by itself makes for a static and nonextensible classing environment. Inevitably in a system like this, functionality gets pushed up higher and higher in the class hierarchy so that the mechanisms will be available to more and more subclasses. Interfaces are designed to avoid this problem. They disconnect the definition of a method or set of methods from the inheritance hierarchy. Since interfaces are in a different hierarchy from classes, it is possible for classes that are unrelated in terms of the class hierarchy to implement the same interface. This is where the real power of interfaces is realized.
First question: what does the author mean by saying from one class to another? Does he mean that those classes are related in terms of the hierarchy? I mean, assigning subclass object reference to its superclass type variable and then calling a method?
Second question: what does the author again mean by saying This requirement by itself makes for a static and nonextensible classing environment? I don't understand the makes for meaning (english is not my main language) and why the environment is called static and nonextensible.
Third question: what does he mean by saying functionality gets pushed up higher and higher? Why does it get pushed up higher and higher? What functionality? Also, mechanisms will be available to more and more subclasses. What mechanisms? Methods?
Fourth question: Interfaces are designed to avoid this problem. What problem???
I know the answers must be obvious but I don't know them. Maybe mainly because I don't undestand some magic english phrases. Please help me to understand what is this whole paragraph telling.
Between any two classes. If your code contains a call to String.substring() for example, the String class and its substring() method must be available at compile time.
As said, "makes for" means the same as "creates". The environment is non-extensible because everything you may want to use must be available at compile time. (This isn't 100% true though. Abstract classes and methods provide extension points even when no interfaces are present, but they aren't very flexible as we're going to see.)
Imagine that you have two classes: Foo and Bar. Both classes extend the class Thingy. But then you want to add a new functionality, let's say you want to display both in HTML on a web page. So you add a method to both that does that.
The basic problem
abstract class Thingy { ... }
class Foo extends Thingy {
...
public String toHTMLString() {
...
}
}
class Bar extends Thingy {
...
public String toHTMLString() {
...
}
}
This is great but how do you call this method?
public String createWebPage( Thingy th ) {
...
if (th instanceof Foo)
return ((Foo)th).toHTMLString();
if (th instanceof Bar)
return ((Bar)th).toHTMLString();
...
}
Clearly this way isn't flexible at all. So what can you do? Well, you can push toHTMLString() up into their common ancestor, Thingy. (And this is what the book is talking about.)
A naive attempt to resolve it
abstract class Thingy {
...
public abstract String toHTMLString();
}
class Foo extends Thingy {
...
public String toHTMLString() {
...
}
}
class Bar extends Thingy {
...
public String toHTMLString() {
...
}
}
And then you can call it like this:
public String createWebPage( Thingy th ) {
...
return th.toHTMLString();
}
Success! Except now you've forced every class extending Thingy to implement a toHTMLString() method, even if it doesn't make sense for some of them. Even worse, what if the two objects do not extend anything explicitly, they're completely unrelated? You'd have to push the method up all the way into their common ancestor, which is java.lang.Object. And you can't do that.
Solution with interfaces
So what can we do with interfaces?
abstract class Thingy { ... }
interface HTMLPrintable {
public String toHTMLString();
}
class Foo extends Thingy implements HTMLPrintable {
...
public String toHTMLString() {
...
}
}
class Bar extends Thingy implements HTMLPrintable {
...
public String toHTMLString() {
...
}
}
//We've added another class that isn't related to all of the above but is still HTMLPrintable,
//with interfaces we can do this.
class NotEvenAThingy implements HTMLPrintable {
public String toHTMLString() {
...
}
}
And the calling code will be simply
public String createWebPage( HTMLPrintable th ) {
...
return th.toHTMLString(); // "implements HTMLPrintable" guarantees that this method exists
}
What are interfaces then?
There are many metaphors used to understand interfaces, the most popular is probably the idea of a contract. What it says to the caller is this: "If you need X done, we'll get it done. Don't worry about how, that's not your problem." (Although the word "contract" is often used in a more general sense, so be careful.)
Or in another way: if you want to buy a newspaper, you don't care if it's sold in a supermarket, a newsagents or a small stall in the street, you just want to buy a newspaper. So NewspaperVendor in this case is an interface with one method: sellNewsPaper(). And if someone later decides to sell newspaper online or door-to-door, all they need to do is implement the interface and people will buy from them.
But my favourite example is the little sticker in shop windows that says "we accept X,Y and Z credit cards". That's the purest real-world example of an interface. The shops could sell anything (they may not even be shops, some might be restaurants), the card readers they use are different too. But you don't care about all of that, you look at the sign and you know you can pay with your card there.
The Key to paragraph is "classes need to be present at compile time" in line 2. Classes are more concrete. While interfaces are abstract.
As classes are concrete so Designer and programmer needs to know all about class structure and how the methods are implemented. Where as interfaces are more abstract. (They contain abstract methods only). So programmer needs to know only what methods an interface has to have and signature of those methods. He does not need to know detail how these are implemented.
Thus using interfaces is easier and better while making subclasses. You only need to know method signatures of interface.
Using concrete class we have to implement functionality of a method high in class hierarchy while using interface avoids this problem. (There is a related concept of polymorphism that you would probably learn later)
I was thinking about programming to interfaces and not to concrete classes, but I had a doubt: should any interface method be able to hold references to concrete classes?
Suppose the following scenarios:
1)
public interface AbsType1 {
public boolean method1(int a); // it's ok, only primitive types here
}
2)
public interface AbsType2 {
public boolean method2(MyClass a); // I think I have some coupling here
}
Should I choose a different design here in order to avoid the latter? e.g.
public interface MyInterface {} // yes, this is empty
public classe MyClass implements MyInterface {
// basically identical to the previous "MyClass"
}
public interface AbsType2 {
public boolean method2(MyInterface a); // this is better (as long as the
// interface is really stable)
}
But there's still something that doesn't convince me... I feel uncomfortable with declaring an empty interface, though I saw someone else doing so.
Maybe and Abstract Class would work better here?
I am a little bit confused.
EDIT:
Ok, I'll try to be more specific by making an example. Let's say I'm desining a ShopCart and I want of course to add items to the cart:
public interface ShopCart {
public void addArticle(Article a);
}
Now, if Article were a concrete class, what if its implementation changes over time? This is why I could think of making it an Interface, but then again, it's probably not suitable at least at a semantic level because interfaces should specify behaviours and an Article has none (or almost none... I guess it's a sort of entity class).
So, probably I'm ending up right now to the conclusion that making Article an abstract class in this case would be the best thing... what do you think about it?
I would use interfaces because composition is much better than inheritance. "Should any interface method be able to hold references to concrete classes ?", why it shouldn't? Some classes within package are coupled, it's a fact and common use technique. When you marked this relation in interface then you see on which classes is dependent your implementation. Dependency or composition relations are not inheritance so a i would avoid abstract class.
In my opinion Interfaces are fine for all types where the implementation may vary. But if you define a module which introduces a new type, that isn't intended to have alternative implementations then there is no need to define it as an Interface in the first place. Often this would be over-design in my opinion. It depends on the problem domain and often on the way how support testing or AOP-weaving.
For example consider a 2D problem domain where you need to model a Location as a type. If it is clear that a Location is always represented by a x and y coordinate, you may provide it as a Class. But if you do not know which properties a Location could have (GPS data, x, y, z coordinates, etc.) but you rely on some behavior like distance(), you should model it as an Interface instead.
If there are no public methods which AbsType would access in MyClass then the empty interface is probably not a good way to go.
There is no interface declaration (contract) for static methods, which otherwise might make sense here.
So, if AbsType is not going to use any methods from MyClass/MyInterface, then I assume it's basically only storing the class object for some other purpose. In this case, consider using generics to make clear how you want AbsType to be used without coupling closely to the client's code, like
public class AbsType3<C extends Class<?>> {
public boolean method3(T classType) {...}
}
Then you can restrict the types of classes to allow if needed by exchanging the <C extends Class<?>> type parameter for something else which may also be an interface, like
<C extends Class<Collection<?>>>.
Empty interfaces are somewhat like boolean flags for classes: Either a class implements the interface (true) or it doesn't (false). If at all, these marker interfaces should be used to convey an significant statement about how a class is meant to be (or not to be) used, see Serializable for example.
I know this is a basic question, but I can't find other StackOverflow posts or any good API docs on this.
Say I have an abstract class like Appliance and then I have some classes like Toaster and Blender that extend Appliance. Now suppose that I want to create an ArrayList that will contain mixed elements, all of which are ultimately members of Appliance but could also be Toaster or Blender as well. The Blender class has a method called turnBlenderOff() and the Toaster class has a method called turnToasterOff(), and I will want to iterate over my ArrayList and call these methods, depending on which subclass the element actually belongs to.
Currently I make a class called PowerPoint and try:
// Constructor given an ArrayList of appliances.
public PowerPoint(ArrayList<Appliance> initial_list_of_appliances){
int listSize = initial_list_of_appliances.size();
for(int ii = 0; ii < listSize; ii++){
this.applianceList.add(initial_list_of_appliances.get(ii));
}
}
/////
// Method to switch everything in the list OFF simultaneously.
/////
public void switchOff(){
int N = this.applianceList.size();
String cur_name;
for(int ii = 0; ii < N; ii++){
cur_name = this.applianceList.get(ii).getClassName();
if(cur_name.equals("Blender")){
this.turnBlenderOff(this.applianceList.get(ii));
}
else if(cur_name.equals("Toaster")){
this.turnToasterOff(this.applianceList.get(ii));
}
else if(cur_name.equals("Oven")){
this.turnOvenOff(this.applianceList.get(ii));
}
}
}
Most of my code compiles fine, but I keep getting this error message:
PowerPoint.java:83: turnBlenderOff(appliances.ApplianceWrapper.Blender) in PowerPoint cannot be applied to (appliances.ApplianceWrapper.Appliance)
this.turnBlenderOff(this.applianceList.get(ii));
I see that this method, implemented to work only on Blender objects is trying to be executed on an Appliance object that happens to be a Blender but that the compiler doesn't realize this.
I tried to replace the <Appliance> type with <? extends Appliance> in the ArrayList specifications, but that gave additional errors and would not longer compile.
What is the proper way to make a list based on the abstract type, but then call methods of the subclassed type by using something like getClassName() to retrieve the subclass type?
Added
Since a lot of folks immediately pointed out the obvious: use inheritance better, I need to explain. For this project, we have to assume that all of the subclasses of Appliance were created by third-party people and put into some package that we cannot change. This was done in a bad, crufty way in which all different subclasses have different on/off methods and this can't be changed. So the option of designing a smooth Appliance abstract class is not open to me. For example, Toaster has the method startToasting(), while Oven has the method heatUp(), each of which serves as the 'on' method for the two different classes.
I think the exercise is meant to teach us: how would you retro-fit someone else's bad design job so as to minimize future damage.
If you want to use an abstract class and all subclasses actually have the same functions, why don't you use a function in the abstract base class called "turnDeviceOff" and override it in the subclasses accordingly. That's the OO approach.
The ArrayList is ok.
but you could do this:
public abstract class Appliance{
//declare an abstract method
abstract void switchOff();
}
then
public class Toaster extends Appliance{
//implement the abstract method
void switchOff(){
//do toaster switchOff
}
}
for other subclasses, do the same.
finally,
for(Appliance element: yourList){
element.switchOff();
}
Use instanceof or getClass, not rolling your own getClassName, and then do an explicit cast to the type you just identified.
That said, prefer #guitarflow's answer, though that approach might not work if there is state that you can't just pass to the switchOff method.
There are two ways you can do this. The first (and less-recommended) way is by using the instanceof keyword and casting your Appliance instance into a Blender instance:
for(Appliance a : list){
if(a instanceof Blender) this.turnBlenderOff((Blender)a);
...
}
This is bad because instanceof is slow and doesn't allow you to take advantage of Java's most powerful counterpart to polymorphism, late binding. The better way would be to have the Appliance class have an abstract public method called turnOff(). Then you could do something like:
for(Appliance a : list){
a.turnOff();
...
}
The proper way to solve is by adding a turnOff() method in Appliance class, and have the various subclasses override them appropriately. If you do that, then the big "if" code goes away.
You're rather defeating the point of inheritance: Appliance should define a turnOff() method, which its children should implement appropriately for their needs. That way you can just work with a list of Appliances and not have to worry about what's what.
Otherwise, what's the point of them extending Appliance in the first place?
If you do need to figure out the type of something, use instanceof, testing class names as strings is a terribly brittle way of doing it.
Edit
Random style tip: it's almost never necessary to use index access on Lists anymore:
public PowerPoint(List<Appliance> initialList){
for(Appliance app : initialList)
applianceList.add(app);
}
Of course there's also:
applianceList.addAll(initialList);
Edit 2
A more direct translation:
public void switchOff(){
for(Appliance app : applianceList)
switchOff(app);
}
private void switchOff(Appliance app){
if(app instanceof Blender)
turnBlenderOff(app);
else if(app instanceof Toaster)
turnToasterOff(app);
else if(app instanceof Oven)
turnOvenOff(app);
else
throw new RuntimeException("unknown appliance: " + app);
}
You could also add a wrapper around the different appliance classes that normalizes the API, but it may not be worth it (depending on how involved it is).