7 Replies Latest reply: Feb 14, 2014 1:37 AM by gimbal2 RSS

Lombok alternatives for clear code without getters/setters/toString/constructors

user5970066 Newbie
Currently Being Moderated

Hi

Do you know any Lombok alternatives ?

Using Lombok we can forget about messing class with getters and setters and toString, I want use it in my project however I wonder if there are any better alternatives?

  • 1. Re: Lombok alternatives for clear code without getters/setters/toString/constructors
    TPD-Opitz-Consulting-com Expert
    Currently Being Moderated

    The best thing I can suggest is forgetting about getters and setters. These are violations of the main principle of object oriented programming: information hiding. Unless your class is a pure data container without any logic it should not have any getter or setter.

     

    A framework like Lombok will make it easier to violate OOP rules without explicitly documenting it in the code.

     

    Instead of lerning how to use Limbok I't suggest you leant how to use JUnit and Mockito to create your program testdriven...

     

    bye

    TPD

  • 2. Re: Lombok alternatives for clear code without getters/setters/toString/constructors
    rp0428 Guru
    Currently Being Moderated
    These are violations of the main principle of object oriented programming: information hiding.

    Care to explain that?

     

    Getters/Setters are used to implement 'information hiding'. Access to the instance variables is ONLY available via getter/setter methods rather than directly.

  • 3. Re: Lombok alternatives for clear code without getters/setters/toString/constructors
    TPD-Opitz-Consulting-com Expert
    Currently Being Moderated

    rp0428 wrote:

     

    These are violations of the main principle of object oriented programming: information hiding.

    Care to explain that?

     

    Getters/Setters are used to implement 'information hiding'. Access to the instance variables is ONLY available via getter/setter methods rather than directly.

    Getters/setetrs uncover the inner structure of an object. That is quite the opposite of "information hiding".

    The meaning of "information hiding" is not (only) nobody can read data stored in the object.

    In the first place it means that no other part of the program needs to know how an object organizes it's inner structure.

     

    The only acceptable exception to this are DTOs which only carry information and do not have any logic.

     

    This does not mean that I would avoid a method setName() in a class Person. Changing a persons name is a valid business case. But I would not accept a method setAge()...

     

    bye

    TPD

  • 4. Re: Lombok alternatives for clear code without getters/setters/toString/constructors
    rp0428 Guru
    Currently Being Moderated

    Well then I disagree almost entirely with what you say.

    Getters/setetrs uncover the inner structure of an object. That is quite the opposite of "information hiding".

    IMHO that is EXACTLY a feature of "information hiding". This wiki quote says it pretty succinctly:

    http://en.wikipedia.org/wiki/Information_hiding

    A common use of information hiding is to hide the physical storage layout for data so that if it is changed, the change is restricted to a small subset of the total program. For example, if a three-dimensional point (x,y,z) is represented in a program with three floating point scalar variables and later, the representation is changed to a single array variable of size three, a module designed with information hiding in mind would protect the remainder of the program from such a change.

    A classic example is an instance variable that stores 'temperature'. There may be multiple 'getters/setters' to allow different temperature scales to be used: centigrade, kelvin, etc. A user can call a 'getter' to get a temperature value in centigrade without having ANY knowledge as to the actual physical format, or even location, of the data.

     

    That information is 'hidden'.

    The only acceptable exception to this are DTOs which only carry information and do not have any logic.

    I disagree if 'DTO' is the acronym for 'Data Transport Object. DTOs (as well as DAOs) are a CLASSIC use of getters and setters and for the same reason: information hiding. You don't want to expose the actual physical structure of the DTO/DAO to the user/developer. Exposing that structure inhibits reuse of the class if the internal structure needs to be modified for some reason.

     

    That reason just might be the 'temperature' example I gave above. I might modify the DTO/DAO to store temperature differently.and the getters/setters hide that.

     

    DTOs/DAOs definitely contain 'logic' - it just isn't 'business logic'. They contain any logic needed for the getters/setters.

     

    Again a wiki quote says it rather nicely:

    http://en.wikipedia.org/wiki/Data_transfer_object

    The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.[1]

    Those 'accessors' and 'mutators' are the getters and setters.

    This does not mean that I would avoid a method setName() in a class Person. Changing a persons name is a valid business case. But I would not accept a method setAge()...

    Again - that would be a CLASSIC use case for REQUIRING a setter method. You don't want someone being able to set just any value at all for an age; they could make you 900 years old!

     

    An attribute such as 'age' might not be appropriate for an employee data record since age, when used as a real-time value, is 'dynamic'. But if you are reporting information and perhaps using DTOs/DAOs to store that information an 'age' attribute is often an attribute of a report. The value of 'age' needs to be computed/validated by 'some' process to eliminate 'dirty data'.

     

    Use of a setter is one way to ENSURE that the validation is done. Factory methods are another way.

     

    Getters and Setters also help implement the two other main features of object-oriented programming: polymorphism and inheritance. Interfaces are typically defined to include getters/setters to ensure that information hiding will really be implemented in defining classes.

  • 5. Re: Lombok alternatives for clear code without getters/setters/toString/constructors
    TPD-Opitz-Consulting-com Expert
    Currently Being Moderated

    Not sure if you misinterpret my posts by intention or not...

     

    My point was NOT to access properties directly instead of using setters/getters.

    My point is that object properties should not be accessable at all from the outside by any chance and if I provide access (via getter of cause) I need to have a good reason to do so.

     

    The Framework the TO mentioned provides access to any property with little effort. This is what I don't want in my programs.

     

    bye

    TPD

  • 6. Re: Lombok alternatives for clear code without getters/setters/toString/constructors
    rp0428 Guru
    Currently Being Moderated

    Understood - thanks for clarifying.

     

    I didn't doubt that you understand when and how to use getters/setters but since the forum is for everyone I usually try to clarify issues like that for people that don't have your expertise or experience.

  • 7. Re: Lombok alternatives for clear code without getters/setters/toString/constructors
    gimbal2 Guru
    Currently Being Moderated

    I must say I had to read the first reply a few times before my hairs stopped standing up straight But I get the intention. Indeed, don't expose innards if the "outside world" has no business toying with them; not with getters, not without them.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points