I do not quite understand what a POJO object is so convenient for and how to understand that it is a POJO.

By definition, this is an object that does not expand anything, does not implement anything and does not have a constructor, all private variables + getters and setters ... Just such a simple object.

So, if I understand correctly, that if we allow a constructor to be thrown from this class, is it already POJO?

public final class CardFriend { private String friendName; private String friendPhoneNumber; private Bitmap friendPhotoBitmap; private String friendEmail; private String Uid; private int chanel; public CardFriend(String friendName, String friendPhoneNumber, Bitmap photoBitmap, String friendEmail, int chanel) { this.friendPhotoBitmap = photoBitmap; this.Uid = "test"; if (friendName == null){ this.friendName = States.NO_NAME; }else { this.friendName = friendName; } if (friendPhoneNumber == null){ this.friendPhoneNumber = States.WITHOUT_PHONE_NUMBER; }else { this.friendPhoneNumber = friendPhoneNumber; } if (friendEmail == null) { this.friendEmail = States.WITHOUT_EMAIL; } else { this.friendEmail = friendEmail; } this.chanel = chanel; } public String getFriendName() { return friendName; } public String getFriendPhoneNumber() { return friendPhoneNumber; } public Bitmap getFriendPhotoBitmap() { return friendPhotoBitmap; } public String getFriendEmail() { return friendEmail; } public int getChanel() { return chanel; } public String getUid() { return Uid; } } 

And I have not found, is it possible to use logical methods in such classes? Suppose some kind of calculation method.

Well, if anyone cites examples where such objects are best used (since it is not a dubious advantage to throw out the constructor and install the setters), then it will be completely clear))

  • In general, more generally, a POJO is an instance of a class that is not inherited from other classes - Simple Java Object - pavlofff
  • POJO - as a rule, object-model, serves for convenient grouping of different-type data (other objects of different types, as in your code - fields with a name, telephone, image, etc.), in order to present them as a single structure (data unit containing different types of data ), also the methods of recording / extracting this data. May contain logic with calculations, if required in the model. POJO may have a constructor, whence the limitation on its absence? Moreover, the default constructor is created implicitly, even if it is not specified in the code. - pavlofff pm
  • one
    Moreover, I don’t think that POJO needs to look for some special application, it’s just a characteristic of the object, such as a notebook in a ruler. - pavlofff
  • one
    @AlekseyTimoshchenko, there is a link to Wikipedia in the comments below, which explicitly says: ** is not bound by any restrictions , except language. And then it’s truly stated above that this term does not have an unambiguous and generally accepted definition, it is more often used just to say something, that this is not some Enterprise Javabean or Widget GUI, but a simple object that we created here purely for our needs, such as we are comfortable, are not foreseeable for anything and are not required to report. - m. vokhm
  • one
    To begin with, there is no official definition of a POJO. Therefore, everyone interprets the concept of "simple object" by virtue of its understanding of simplicity. Someone thinks that the constructor with arguments is no longer a simple object, I do not think so. In general, at the present time, the definition of a POJO object has been assigned a value that it is a data unit consisting of heterogeneous objects (as in your example). Such a unit can contain both constructors with arguments and public fields (although this is not recommended) and business logic and even inheritance . - pavlofff

1 answer 1

In a report by Martin Fowler, Rebecca Parsons and Josh McKenzie from 2000, when this term was first used, POJO is just a Java class without “bells and whistles”, not tied to a specific framework. In the context of that report, POJOs are simple objects that are not the entity bean from J2EE. There was no clear definition then, therefore the views on what it is may differ slightly.

As a rule, such classes do not inherit from other classes (you can probably make an exception for POJO classes from the same package), do not implement interfaces (sometimes an exception is made for marker interfaces from the standard library), do not use annotations in definitions and do not depend on third-party libraries. Those. POJO can have methods with business logic, and arbitrary-type constructors.

If you make an exception for Serializable, then JavaBeans can be assigned to POJO. If you allow annotations that do not change the semantics of the class (i.e., without which the object's purpose and logic of its operation do not change), then the JPO and DTO objects serialized in XML or JSON, the rules for which are specified in the annotations, can be assigned to the POJO.

An example of when it is convenient to use a POJO is an ordinary domain model in DDD, which you save to the database or transfer via the REST service to the client. You can cram a bunch of annotations into it, or you can put all the mapping rules on the database or DOM into separate components (configurations of the ORM and the serializer), reducing the connectivity of your architecture.