Why Java Beans demand accessors?_问答_开发者_运维开发者技术经验分享

please, dont try to kill me with all the "only accessors are right" talk... I came in peace :)

I just kindly want to ask, what is the main reason, that Java Beans MUST use accessors even in situations only simple attribute access is required. I know accessors are good thing, in certain situations. But, as my favourite article says, "dont use acce开发者_运维知识库ssors, unless you are 100% certain you need more than simple atribute access, they are waste of CPU and programmer time".

Again, please, dont attack me for not using accessors all the time. I only ask, what is the reason it HAS to be used in order to use and create proper Java Bean. Why people at Oracle said lets do it this way... Thanks.

Java beans are a convention. Frameworks that work with Java beans rely on the details of that convention to reliably manipulate objects.

There's actually a good explanation on wikipedia: http://en.wikipedia.org/wiki/JavaBean

The main reason of using accessors it to have a full control over its modifications within a single place.

For example let say that you have a collection which is returned by reference from a class in that case it is very hard to track when something is added to a collection or not. A good practice is to return always a copy of the collection within a getter method
Another utilization is to have for instance only read-only properties and I am not talking about final variables but read only for the outside world and strictly controlled by the inner world (it is very usefull when operation on entities which are mapped to DB views)
for unit testing it can be utilized in mocking (checking setter invokation couter)
you may always create proxy object which allows us to provide some extra logic like some validation or data corrections
when creating JPA entities I prefer field injection for JPA provider initialization and property initialization for client logic - but this is my subjective opinion
while you are debugging it is sometimes very helpful to put breakpoint on setter to see what magically changes the value of some property
when class internal structure changes on the inside the contract (accessor methods) remain the same
initializing some properties in a lazy way

I could find many more reasons ... :)

IMHO using accessors and mutators gives as a way to make our code more extensible and much more flexible

In fact, a Java bean is a bean if it follows the conventions:

The class must have a public default constructor with no-argument.
The class properties must be accessible using get, set, is. The accessors, if you prefer.
The class should be serializable.

source

So it's just a matter of conventions...

While this is a requirement for original Java Beans, as per convention, it is worth noting that many libraries that support "beans" do also consider public fields as valid accessors; and usually also allow use of annotations to specify non-public methods and fields as well. This includes libraries like JAXB (for XML-to-POJO data binding) and Jackson (JSON-to-POJO).

So in some ways original Java bean 'specification' (convention as documented in JDK javadocs) is not all that relevant any more.

I assume original authors of convention just felt that direct field access was not a good practice. Personally I think there are cases where simple immutable struct-like classes are fine, and it's pretty silly to have to write monkey code for getters (or setters for mutable ones); but there is fine line between "Java structs" (just data, no logic or at most very little) and "real" objects (state and behavior).

By using accessors you can apply logic when you get/set a value. It isolates the bean from the rest of the application.

If you need to alter the internal storage of the bean, you can do that, and still keep the same getters/settes.

For example: If you have a class for storing an ip address, you might wan't to store it as an Long value instead of a String (for effiecency). You can do this by only make changes to one class.

Also take a look at GRASP, especially Information Expert

If you need to hide the details of the property, then you will need accessors. i.e for example there is a computed value (say balanceDue) which is computed from two other actual properties (say credit and debit), then you can have code in your accessors that do the computing. Otherwise, you will need to do teh computation within every client that invokes the individual fields. This is one example where accessors make sense from a logical point of view. Basically, encapsulation.