What is a good use case of Java Beans?

Question

I just saw the Java Beans specification. I felt that using only getters, setters and empty constructor will make code more hectic plus developer needs to manage track to set all the required instances properly.

Could somebody point me a good use case for using such design? I am unable to get a feel of it. There is one use I can think of - "When you need to create an Instance of a class such that its data members will be decided later in the code."

EDIT: Guys I am not initiating a discussion. Don't want to discuss advantages/disadvantages. I am not looking for current libraries like spring etc which makes it mandatory to use Beans. I am looking for an example to understand engineering benefits Java beans would bring. "Just one example where Java Beans design would help"

Answer 1

A number of libraries and specifications (e.g. JPA, JavaEL) use the Java Beans spec and rely on exactly that behavior.

Using getters and setters has the advantage of letting you add code inside those methods, e.g. to create "virtual" properties which are calculated at runtime rather than stored in a field.

Additionally using getters and setters allows other frameworks to wrap those methods and provide additional functionality like change logging etc. In many cases this is done by internally creating a subclass and overriding the getters and setters. The user would not notice that since that "weaving" or "proxying" is often done at runtime. Hibernate for example uses this to provide lazy loading functionality when you call a getter to access a related collection or entity.

Update:

As per request an example for "virtual" properties:

Assume you have a Person bean which has the fields firstName and lastName. You could add a read-only virtual property name by providing the following getter:

public String getName() {
  return getFirstName() + " " + getLastName();
}

Update 2:

Another note on why getters and setters are necessary: this basically comes from how Java works. Languages that directly support properties, like C#, would allow you to write code like person.firstName = "Joe"; and still use a setter if there is one or throw an error if the property is read-only. So if you'd add a setter for firstName those languages would internally translate firstName = "Joe" to setFirstName("Joe") without the developer having to change anything - quite an elegant solution. :)

Since Java doesn't support that, we have to always provide accessor methods (setters/getters) even if they don't do anything special - just in case they might need to be changed in the future.

Answer 2

Beyond the actual advantages and disadvantages of JavaBeans spec, I think it's important to remember that it is a specification introduced in 1996 to enable the visual editing of Java code.

I don't know if this approach to programming succeeded and has been adopted (I have never used it, personally). What I know is that the specification continued to live and to be applied very widely (IMHO sometimes also in contexts in which was not the most suitable).

I think the most useful place in which JavaBeans can be used is a framework. A good example is Spring. A JavaBean class is very suitable whenever class instantiation is not responsible of the programmer, but is delegated to the application container (for example via reflection).

Answer 3

getters & setters ensures the basic object oriented concept - Encapsulation

Imagine you wrote the code for a class and another dozen programmers from your company all wrote programs that used your class. So , anyone can change your instance variable & it may harm your code .

So you should

Keep instance variables protected (with an access modifier, often private).

Make public accessor methods, and force calling code to use those methods rather than directly accessing the instance variable.

Their code brought out errors in your code.

look the following example

public class MyClass{
public int size;
public int weight;
...
}
public class OthersClass {
public static void main (String [] args) {
MyClass myClass= new MyClass();
myClass.size = -5; // Legal but bad logic
}
}

Answer 4

Many people will tell you that Java Beans are so much better than using plain Java objects that act as "data transfer objects".

But other people, for example this guy here in his well known book https://cleansourcecode.files.wordpress.com/2013/10/clean-code.pdf suggests that most often, "beans" and getters and setters do have not much additional value (the whole chapter 6 is devoted to this question).

So you should decide for yourself (and probably with your team mates) if your problem is better solved with "Java Beans" or "plain data transfer objects".

Sure, "beans" force you to use setters, which allow you to later add validation. On the other hand: such a change modifies the semantics of your methods; and it might be plain wrong that all of a sudden a setter does validation and starts throwing exceptions. Because, if you change the contract of your methods; you might not want to do that implicitly under the covers.

Answer 5

An empty constructor is needed to create a new instance via reflection by your persistence framework. If you don't provide any additional constructors with arguments for the class, you don't need to provide an empty constructor because you get one per default.

In my experience it is to prevent the situation where someone adds a constructor with parameters, and thus effectively removes the default constructor. By implementing the default constructor explicitly that is more unlikely to happen.

Also, i guess you are imagining a class with lots of attibutes that will be hard to fill only with getters and setters, but also note this points:

• Getters will automatize the view part.
• Setters will allow you to add validation or error control if necessary.

Answer 6

JavaBeans, as you've described above, can be employed as DAO (Data Access Objects) for retrieving and saving data to a (SQL primarily) Database. They are useful where all you really care about is the data