Win a copy of Securing DevOps this week in the Security forum!

Alexandru Dragoi

Ranch Hand
+ Follow
since May 09, 2008
Bucharest, Romania
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
4
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alexandru Dragoi

Just a mention regarding a rule for reduce() function for a stream:

The identity must be defined such that for all elements in the stream u, combiner.apply(identity, u) is equal to u.


The elements u are not from the stream and have the type of the reduction result.

Paul Anilprem wrote:OP's claim about the code in your book is correct. It will not work for extreme cases.



If you just set up some invariants for that object state everything would be fine. As you said, negative ids do not make sense.
In OCP Oracle Certified Professional Java SE 8 Programmer II, on chapter 3, page 144 we have an implementation of compareTo method:

This implementation may give the wrong answer when there is overflow (comparing a large negative value to a large positive value).
I did provided a global access to my instance, although it does not respect the encapsulation principle (also another subject of the exam).
In the OCP Oracle Certified Professional Java SE 8 Programmer II, chapter 2 test answer to this question:

What are some of the properties of using the singleton pattern? (Choose all that apply.)


This answer is marked as being true:

F. Requires a public static method to retrieve the instance of the singleton.



You do not need a public static method to retrieve the instance.
This is also a valid singleton:

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.
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.


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:


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.

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?
In the exam book we have a bad example of how to write code:


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...
Thanks for this book! I have looked over the book contents and it seems small and concise.