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...
Alex Dragoi, SCJP 1.4, OCPJP 6
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?
Alex Dragoi, SCJP 1.4, OCPJP 6
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.
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.
Alex Dragoi, SCJP 1.4, OCPJP 6
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.
[OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
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.
Alex Dragoi, SCJP 1.4, OCPJP 6
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
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.
Alex Dragoi, SCJP 1.4, OCPJP 6
-
2
-
-
-
-

Regards,
John
