Wondering if m_ naming convention conforms to Javabean property style?
well, m_ comes from Microsoft standards, which is based on Hungarian Notation. So that naming pattern isn't recommended by Sun/Oracle.
That's not to say you can't use them in JavaBeans as, javabeans are all about the method signatures, not about the field names, so you can call fields whatever you like.
Well,You can name your Java bean member, using any naming convention. The name is not part of the contract that makes a class, Java Bean.
Your class needs a public contructor,all its properties should be accessible via get and set and the class needs to be serializable.
But then again, I would not suggest using the m_ naming convention. Java Beans convention are used by lots by Java tooling support and more importantly by frameworks like JSF and Web Services (for UI binding and xml marshaling respectively). So apart from confusing some Java developers, who needs to maintain your code, there is also a possibility that some tooling support might not work.
Related
I am working on a Java library which wraps an existing general purpose API in a more specialized, servlet aware API. The wrapper API consists of exact same classes as the unerlying API, but some method signatures are re-written in terms of servlet objects, like HttpServletRequest. The original developer followed the naming convention of prepending the word Servlet to the existing class name, e.g. Connection in the existing API becomes ServletConnection and Session becomes ServletSession. Is this naming a good idea, or should the classes have the same names? My question may seem a matter of taste, but I am hoping for answers based on reason. The Scala collections API, for instance, reuses class names between mutable and immutable collections.
if I have the following private member:
private int xIndex;
How should I name my getter/setter:
getXindex()
setXindex(int value)
or
getxIndex()
setxIndex(int value)
EDIT: or
getXIndex()
setXIndex(int value);
?
The correct answer is
getxIndex()
setxIndex(int value)
if you want them to be used as properties according to section 8.8: Capitalization of inferred names of the JavaBeans API specification (e.g. access them via ${object.xIndex} in a JSP.
In accordance with JavaBeans API specification from 1997
it should be as Thomas Einwaller describes:
// According to JavaBeans API specification
public int getxIndex() { return xIndex; }
public void setxIndex(int xIndex) { this.xIndex = xIndex; }
This is unfortunate, getx and setx are not words. In the rare case when this would form a word or acronym it would be disinformative, eg the method setiMessage most
likely has nothing to do with SETI.
Using the only valid measurement of code quality (WTFs per minute),
I assess that this is bad code.
If we modify this to follow the convention for
naming a method it would be:
// According to Java naming convention
public int getXIndex() { return xIndex; }
public void setXIndex(int xIndex) { this.xIndex = xIndex; }
Why does the JavaBeans specification violate the convention? It all comes down to this sentence of the JavaBeans specification:
However to support the occasional use of all upper-case names, we check if the first two characters of the name are
both upper case and if so leave it alone.
Exactly what kind of use of all upper-case names this refers to is unclear to me. Field names should, according to
convention, be camel cased. It seems
to me that we generate unconventional method names in order to support unconventional field names as decided by a
20+ year old document.
It should also be noted that even though it seems to be an overwhelming support for the JavaBeans specification in tools,
it is not exclusively used. Eg. Kotlin will not recognize xIndex as a property in the above example. Reversely, the
Kotlin property var xIndex = 0 will result in the Java methods getXIndex and setXIndex. This seems to be a bug
according to the JetBrains support, but I fail to see how they can fix that without making a breaking change.
Some tools that does support the JavaBeans specification has not always done so, eg Jackson
and Swagger Code Generator have been patched to conform to it.
Even though IntelliJ generate accessors according to the JavaBeans specification, the example
in the documentation differs from it. Probably because people don't know about the standard and naturally prefers the
normal method naming convention.
So when should we follow the JavaBeans specification? When property names should be inferred by accessors by tools that
rely on this standard, then we might want to use it. For instance, Jackson will rely
on the property xIndex being accessed through getxIndex and setxIndex methods unless we use annotations.
When should we avoid this standard? Per my recommendation: When the code should be read and understood by humans.
Because to not use proper camel casing when naming methods is disinformative.
If I would have it my way, we would use normal naming conventions, ie getXIndex and setXIndex. But, given the state
of things, the best solution I see is suggested by #vaxquis:
Name your field "indexX" or whatever else, your problem is solved... don't overcomplicate things - even if setxIndex
is the correct way for Beans, having method named setxIndex increases the WTF factor of the code without giving you
anything in return.
Any comments regarding the JavaBeans specification should, according the specification itself, be sent to
java-beans#java.sun.com.
Should be:
getXIndex()
setXIndex(final int xIndex)
Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.
You should use Introspector.decapitalize from package java.beans and you have no problem beacause it is compliant with java rules.
Eclipse ide automatically generates setters and getters as:
getxIndex()
setxIndex(int value)
Which is according to the java beans API specification.
I think getXindex() is the best way. The getter should start with 'get', followed by the member name, with its first letter capitalized. Also the latest conventions I heard of, say that we should avoid multiple capital letters one after another. For example getHTMLtooltip is wrong. it should be getHtmlTooltip instead. Also you should try to make all your members final and there should not be a need of setters, since the class will be immutable ;)
I have seen some projects (jsoup for example) are using this new getter/setter naming convention:
String name()
void name(String value)
instead of old getter/setter convetion:
String getName()
void setName(String value)
What are positive and negative aspects of each naming convention? When and why you think one should be preferred over the other?
The first example doesn't adhere to the JavaBeans specification [Warning PDF]. There are certain frameworks like Spring, that assume this naming convention, especially when you do something in EL like ${object.name}, which gets translated to object.getName(). This will fail if you don't follow the naming conventions (although there are ways to get around it).
Without getting into a discussion about when/if to use getters/setters, in general it's better to stick with the naming convention because there are fewer surprises that way, especially when you're integrating with third-party libraries or frameworks that expect things to be named according to convention.
Nothing except readability and API style.
Some APIs accept this style and some don't, like Spring injections and JSF can't recognize this syntax (they explicitly require get/set for properties).
I like to simply use name() when the object that I'm dealing with is immutable, i.e. I would never change the value of the name field. When I'm dealing with a mutable object, I would use the second convention you mentioned, simply because I think it is superior in terms of readability.
I always prefer using verbs for methods name, so this is valid also for getters and setters.
I use nouns only for variables.
Follow classic JavaBean standard make me feel more comfortable. :)
I prefer to use the shorter style if the library is low level and I want to make it clear this component is not a JavaBean.
If in doubt, I would use the JavaBean style.
As far as I know, JavaBeans are the simple getter and setters methods of whatever fields are there in your Java class, on the other hand POJO seems similar (fields and its getter/setter) whats the difference then?
As that's not enough, here comes the beans floating around in all your JSPs and Struts config files, does (according to my knowledge) same stuff...
I am confuse by naming, whats the difference, what are the magic words?
Why do they call it bean, what should I say, if any one ask me describe bean in context of Java EE / JSP / Struts.
A POJO is a plain java object that doesn't adhere to any framework standard. Often Java Beans are considered POJOs as well, since the Java Beans Standard (or what is used of it) is kind of weak.
Java Beans are Java classes that adhere to certain naming conventions (mainly the getter setter thing) and are used in many contexts. JSPs is one of them. There is actually more to Java Bean then most people use. You can learn about it in this tutorial: http://docs.oracle.com/javase/tutorial/javabeans/index.html
Why is it called bean? I can only guess: Java -> Coffee -> Bean on one hand and on the other hand a bean is something simple, self contained which is kind of appropriate for a 'component'
A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods. An Enterprise JavaBean is not a single class but an entire component model (again, EJB 3 reduces the complexity of Enterprise JavaBeans).
So main difference that could be seen is POJOs can be more encapsulated - have argument constructors and throw away some setters that should be used only once per object. JavaBean as you mentioned enforces some strick standard which isn't the best solution to every need.
Are the notions mentionned in the question title synonymous to a certain degree? Where do the main differences lie (context, structure, ...) and can one be considered a subset of another? Here's some brief definitions taken from Wikipedia.
POJO (Plain Old Java Object)
Wikipedia
In computing software, POJO is an
acronym for Plain Old Java Object. The
name is used to emphasize that a given
object is an ordinary Java Object, not
a special object, and in particular
not an Enterprise JavaBean. The term
was coined by Martin Fowler, Rebecca
Parsons and Josh MacKenzie in
September 2000:
"We wondered why people were so against using regular objects in their
systems and concluded that it was
because simple objects lacked a fancy
name. So we gave them one, and it's
caught on very nicely."
Java Bean Wikipedia
JavaBeans are reusable software
components for Java that can be
manipulated visually in a builder
tool. Practically, they are classes
written in the Java programming
language conforming to a particular
convention. They are used to
encapsulate many objects into a single
object (the bean), so that they can be
passed around as a single bean object
instead of as multiple individual
objects. A JavaBean is a Java Object
that is serializable, has a nullary
constructor, and allows access to
properties using getter and setter
methods.
Value Object Wikipedia
Data transfer object (DTO), formerly
known as value objects or VO, is a
design pattern used to transfer data
between software application
subsystems. DTOs are often used in
conjunction with data access objects
to retrieve data from a database.
Business Object Wikipedia
A business object is a type of an
intelligible entity being an actor
inside the business layer in a
n-layered object-oriented computer
program.
Related:
Difference between DTO, VO, POJO, JavaBeans?
What is the difference between a JavaBean and a POJO?
DDD: what's the use of the difference between entities and value objects?
Not all of these classifications are related. Here's my understanding:
POJO is what its name suggests - a plain old Java object. There's nothing special about it. And this is exactly what we want to convey when we say that an object is a POJO. Today most applications are using some kinds of underlying frameworks, and with the frameworks come requirements on the objects that will integrate with the framework - the object must implement an interface or extend a class. When we say an object is a POJO, we mean to say it is just an ordinary object and has no dependencies on any framework.
A JavaBean is a java class that follows certain conventions as described in your question. Such objects are often mandated by certain frameworks which use reflection to find out the properties (accessible through getters/setters) of the object and manipulate them e.g. beans exposed to JSPs, Spring beans etc. The good thing about JavaBeans is that they are still POJOs. Although they follow certain conventions, the conventions are not defined by any particular framework but are rather defined by Sun Javabean standard and the classes are still plain Java classes with no ties to any third party framework's classes or interfaces.
Business Objects refer to objects that represent your business domain entities. These usually reside in your business layer - the layer where all the business logic is. These objects usually map to persistence store entities e.g. tables. These objects could be POJOs, JavaBeans, EJBs etc.
Value objects are a type of design pattern. In some small web applications, you have the option of using your business objects in the web layer as well. However, in larger applications or J2EE applications, you define value objects to move information from the business layer to the web layer. That's why they are also called Data Transfer Objects (DTOs). These objects usually have only the attributes that are needed in the web layer and leave the attributes of business objects that were meant for business layer consumption behind. They may also have "computed" attributes that are generated in the business layer. Using this patterns helps decouple the business and web layers.
Here's my take:
Business objects is a generic term
for the abstract idea that
represents your problem. You can
implement them in any language. In
Java, you have additional choices to
make, because they can be POJOs or
EJBs, mutable or immutable.
Value objects or DTOs are used to ferry data between layers. They're usually immutable. They can be implemented as POJOs or Java Beans. Think of them as another subset of POJOs.
A Java Bean conforms to the original Sun specification. They were intended to provide an interface that would allow them to be plugged into a VB-style IDE with ease. Think of these as a subset of POJO.
People sometimes get confused about the difference between Java Beans and Enterprise Java Beans. Java Beans are part of the original Java 1.0 spec, intended to be like VB components (remember "Bean Box"?). Enterprise Java Beans were a spec that followed that described how special Java objects would implement specific interfaces to interoperate with a Java EE app server. The app server was a transaction monitor for a distributed component architecture that would handle threading, persistence, pooling, object lifecycle, messaging, naming, etc. EJBs are a very special subset of Java objects that work only within the context of a Java EE app server.
A POJO can be implemented to conform to the Java Bean standard, but it's not a requirement. Any Java object qualifies as a POJO. It was originally meant to distinguish them from EJB version 2.0, which required several interfaces in order to interoperate with the Java EE app server properly.
The questions is whether it's a mistake to use some of these as synonyms (like I've heard some people do) and if a given classification can be considered as a subset or another.
It is a mistake to use these terms as synonyms. They clearly have distinct meanings. The quoted definitions (and those provided in other answers) make this clear.
However, if it is often valid to use many (or even all) of these terms to describe the same object or objects. It is all a matter of perspective; i.e. what aspect of the object(s) you are trying to emphasize.
Synthesis (from answers given):
POJO: An ordinary object with no dependencies towards any framework. It can be adapted to conform to the Java Bean standard without being a requirement as such.
JavaBean: Object conforming to the Sun JavaBean or Java 1.0 specification (refer to "Bean box"). They were originally intended to provide an interface so they could be plugged into a VB-style IDE with little difficulty. Can be considered as a subset of POJOs and remain independant of frameworks. It can employ certain mecanisms such as reflection to access properties.
Enterprise Java Bean: These shouldn't be confused with Java Beans. With the simplifications brought about with version 3.0, EJBs can be considered as equivalent to a POJO. EJB in itself is a specification describing special Java Objects that can interoperate with a Java EE server. The server as such acted as a transaction monitor in the context of a distributed component architecture handling things such as threading, persistence, pooling, object lifecycle, messaging and naming. As such an EJB can be viewed as a very special subset that used in the contect of a Java EE application server.
Business object: Theoretical concept or abstract idea that helps to represent a given problem. It represents business domain entities and resides in the business layer of an application. They can be mapped to entities in the context of persistance. The object can be a POJO/JavaBean/EJB and be either mutable or immutable.
Value object/Data Transfer Object: Employs a design pattern which helps to decouple the business and web layers. This is to suit the context of large applications where objects can transit between layers (the business and web layer for example). They're usually immutable in nature and can either be formated as POJOs or Java Beans. One specificity is that they can contain computed attributes that are generated in the business layer.
P.S: Marked as community wiki so feel free to edit.