Bad example to write code in OCP Oracle Certified Professional Java SE 8 Programmer II

[Alexandru Dragoi]

In the exam book we have a bad example of how to write code:

public void feedAnimal(Animal animal) {
   if(animal instanceof Cow) {
      ((Cow)animal).addHay();
   } else if(animal instanceof Bird) {
      ((Bird)animal).addSeed();
   } else if(animal instanceof Lion) {
       ((Lion)animal).addMeat();
   } else {
      throw new RuntimeException("Unsupported animal");
   } 
}

But it does not explain for what situation is bad.

Indeed, if we plan to extend with more types, the above code is a poor design decision.
However, if we will only have three types, and we plan to extend with a lot of behaviors like:feedAnimal, then the above code is a perfect design decision! Maybe is the best decision that we can have...

[Liutauras Vilda]

Alexandru Dragoi wrote:In the exam book we have a bad example of how to write code:

Which book?

[Alexandru Dragoi]

Liutauras Vilda wrote:

Alexandru Dragoi wrote:In the exam book we have a bad example of how to write code:

Which book?

The book is OCP Oracle Certified Professional Java SE 8 Programmer II.
Can someone please help me to delete my previous post?

[Liutauras Vilda]

Alexandru Dragoi wrote:However, if we will only have three types, and we plan to extend with a lot of behaviors like:feedAnimal, then the above code is a perfect design decision!

Don't know. If you don't have control over those concrete animal classes, then it could be a candidate for an Adapter pattern. Other than that, all those three methods do the same, adding food in some sense. Maybe have a Feeding interface and have a method addFood() implemented or similar, so you could avoid runtime check and casting.

Book is right, it isn't a good way to do things.

[Alexandru Dragoi]

I think it is related to the procedural style (code in the original post) vs object orientated style design because it also gives an alternative, better way to write code:

abstract class Animal {
   public abstract void feed(); }
}
class Cow extends Animal {
   public void feed() { addHay(); }
   private void addHay() { }
}
class Bird extends Animal {
   public void feed() { addSeed(); }
   private void addSeed() { }
}
class Lion extends Animal {
   public void feed() { addMeat(); }
   private void addMeat() { }
}

So it just compares the two designs and it says that the second is a winner.

However it dos not have the context: we do not know if we plan to extend by adding more types or by adding more behavior to the existing types.

[Jeanne Boyarsky]

Alexandru Dragoi wrote: Maybe is the best decision that we can have...

It's got an if statement and casts. Having a feed() method defined in each class would be far better design.

[Alexandru Dragoi]

If statements and casts are bad indeed.

However, sometimes you would want to add new types and other times you would want to add new behaviors.

There are times where the existing types are sufficient and we are required to add new behaviors.
I imagine a type hierarchy with one interface and 5 subclasses. The business does not require new types (the 5 existing ones are sufficient).
On the other hand, you receive requests to continuously add new behaviors to the existing types.
Adding one behavior would mean to change the code in 6 places.

With the code in the original post, we just add a new method to the AnimalBehaviour class and that's it! We do not change anything in the type hierarchy.
It will look bad with all of those casts and if statements, but what better options do we have: adding all the behaviors in the type hierarchy does not seem to me a better solution.

On the other side, if the behaviors are fixed and we want to add new types we can take advantage of object orientation and polymorphism by applying the second design.

I just want to say that there is not a good solution for all the cases.

[Henry Wong]

Alexandru Dragoi wrote:
I just want to say that there is not a good solution for all the cases.

Well, this would be true for everything right?

All features of a computer language, all frameworks, all best practices, heck, all computer languages are designed to solve the majority of problems that it may encounter. It is always possible to encounter something that doesn't work well -- although, I would argue that if you are purposely looking for it, it is likely contrived.

Anyway, this is also true for books.  In fact, I would argue that it is much more likely for books, as it is designed to teach. And to teach, you have to simplify, and even target simple examples, etc.

Henry

[Alexandru Dragoi]

Anyway, this is also true for books.  In fact, I would argue that it is much more likely for books, as it is designed to teach. And to teach, you have to simplify, and even target simple examples, etc.

If I am referring to the example in the book, it seems more likely to add new types, so the second design is better indeed.
The examples are simple and it explains very well the concepts.

I was just trying to generalize the concepts in my post.

[John Simon]

Well, IMHO, just because you don't foresee a potential need to add new animals at the time you originally write the code doesn't meant that you should go with a less than ideal design.  If you have an inkling that something is not quite right about what you're doing then you should refactor rather than leaving it for someone else to deal with in the future

Regards,

John