Good post. Myself, I use 3 simple rules when designing object-oriented code:
1) Any object, no matter what, implements an interface or more (all public methods are defined in implemented interfaces)
2) Objects are immutable -- no setters. There are also no "get" prefixes, simply because I believe they change your mindset, they make you look at the object as if it were a data structure.
3) There are no "model objects" in my code. I consider the interfaces to be the model. I believe the concept of "model" turns us into puppeteers (see here: amihaiemil.com/2018/04/17/dolls-an...)
Regarding your example, I have only one complaint: the abstraction is not high enough. Meaning the Rectangle takes "height" and "width" directly.
There should also be an option to make an InputStream, or a File, or whatever source of data act as a Rectangle: the idea is to avoid turning A into B; instead, there should be a new implementation of interface B, based on A.
If we just have the "height" + "width" abstraction, then it means there has to be some static methods somewhere, with the job of parsing some data and turning it into a Rectangle.
Thanks for your comment. I agree with you matra to design object-oriented code. Regarding the second part of your comment, I think that your approach could be correct, but there is no obvious use case listed in the post that refers to such approach :)
Anyway, for me, method factories are ok, as Joshua Bloch says in "Effective Java". Also in Scala, using the apply method, chose this way of creating objects. If you want to deal only with interfaces, the factory method is the only right way, I guess.
Good post. Myself, I use 3 simple rules when designing object-oriented code:
1) Any object, no matter what, implements an interface or more (all public methods are defined in implemented interfaces)
2) Objects are immutable -- no setters. There are also no "get" prefixes, simply because I believe they change your mindset, they make you look at the object as if it were a data structure.
3) There are no "model objects" in my code. I consider the interfaces to be the model. I believe the concept of "model" turns us into puppeteers (see here: amihaiemil.com/2018/04/17/dolls-an...)
Regarding your example, I have only one complaint: the abstraction is not high enough. Meaning the Rectangle takes "height" and "width" directly.
There should also be an option to make an InputStream, or a File, or whatever source of data act as a Rectangle: the idea is to avoid turning A into B; instead, there should be a new implementation of interface B, based on A.
If we just have the "height" + "width" abstraction, then it means there has to be some static methods somewhere, with the job of parsing some data and turning it into a Rectangle.
Thanks for your comment. I agree with you matra to design object-oriented code. Regarding the second part of your comment, I think that your approach could be correct, but there is no obvious use case listed in the post that refers to such approach :)
Anyway, for me, method factories are ok, as Joshua Bloch says in "Effective Java". Also in Scala, using the
applymethod, chose this way of creating objects. If you want to deal only with interfaces, the factory method is the only right way, I guess.The second part of my comment is explained here:amihaiemil.com/2017/10/16/javaee8-... (more directly) or here: amihaiemil.com/2017/09/01/data-sho... (more indirectly). Basically my whole blog is around those 3 points (so far), each post from a different perspective.
Yes, ok. IMHO, no approach is correct a priori. Anyway, nice work.