When we talk about Java Beans. Thing comes to the mind is an object having only getters and setters to access and change its instance variables. A POJO. Ever thought why do we use this or are they really useful in your project? Maybe we are using them because its a standard but not a need. Maybe we do need them. Let me dive into its depth.
If my service layer has to transfer some data between data layer and other layers. I would go for a DTO which is a class with private instance variables and respective setter and getters which will change them when needed. Some time I as a question to my self that if I am providing getter and giving the object to the caller and setter which will change the instance variable, then why do I keep it private. Don't you think I should make that object with all public fields without any setters or getters. This will also reduce the lines of code and easy to acess the instance variables.
If this is the case, then why am I providing getXXX() and setXXX (). Is it just that its a standard and I have to follow?
Take another instance where I am developing something which is/might be used by another person. When I say to other engineers that I will implement a data layer and will give back to you an Object you need. Like Person, BusinessObject, etc. Now if you are that person, how will you access the data inside my Objects returned by data layer. If you are using eclipse, then I bet after getting object person you will type "person.get". You will continue to search for the getter you are interested in. and will continue. If you don't find any suggestions by eclipse after "person.get" you will be confused and then check the API for that Person object or might inspect the Person class.
When Java beans was introduced in 90's many java open sources projects addapted it and provides better APIs where in with help of the setter and getter, things became so easy and smooth. If you use frameworks like Hibernate, Struts, etc. You will be writing many Java beans/POJO classes.
Conclusion:
What do I conclude after all confusing stuff. Even though I write java beans a lot I would prefer to use an Object with simple public fields. IF AND ONLY IF that object is used internal to the project. I.e. it is not an open source of any kind. No matter how many persons work on that project its pretty clear to access the public fields. Yes, Eclipse or other IDE will generate pairs of gettters and setters for me. But...!
In other case when I am writing an open source or some kind of API or a framework; strictly I would go as per specifications. The co developers or the techies would be happy to use it instead of public fields.
Its up to you to decide what to go for, depending on your needs or what your frame work demands.
I still have an open question for you to answer. Why do we make variables private when we provide methods to view or change them?
For similar reasons we started using public fields in java beans, without getters and setters. The only down side of this is that a subclass cannot replace functionality in get and set methods. But since the java bean is expected to be a simple struct-like data transfer object and not contain any code, this is not a concern.
ReplyDeleteI think this is part of maturity of the java developer community. In early days things were over object oriented with a heavy price of big increase in code bases and code complexity. Today there is a lot of focus on removing and unnecessary code (like getters and setters), and reducing the complexity of code. AOP is a good example of that, as well as the change from struts 1 to struts 2.
For a java bean which is intended to be just a structure of data, data transfer object, I also think getters and setters are obsolete. Moreover, in those simple objects the ability to subclass a method and add code, makes the simple data object a functional object, which introduces unnecessary complexity to the code. Using public fields, removes that risk, the data transfer object will always stay just that, and never will have any real code.
Elli
Thanks for your thoughts Elli.
ReplyDelete