How can I use a POJO Class and a Classic Class and what is the difference?

Question

Hello everyone. I have a school project to do in Java. I use the POJO class, DAO and the classic Class. I don't really understand how I can use the classics classes (wich contained attributes and methods) with POJO. I know the definition of a POJO but is it useful to have the same attributes in my POJO class than my classic class?

Answer 1

Yes, I'm sorry. I call "classic class" as a normal class with some attributes and some methods wich can modify the values of theses attributes. The POJO just contained attributes and getters + setters but not algorithmic methods which modify the value of the POJO's attributes. So, in my normal class, should I just put my methods + one attributes that referred to my POJO class as I could use my methods to modify the attributes via getters and setters of my POJO?

Answer 2

Well, if I understand what you are saying, I should use POJO for subtil information as for example , the ID from a table of my table. My class wich contain some functionnalities is able to contain attributes. Or, I can just put methods in my class and use POJO's getters and setters to modify the informations. Is it a good manner to work in a project?

Answer 3

So what do so think of as classic? Pojo means "plain old Java object". You can literally not get more classic than that.

The opposite of Pojo is "class implementing stuff from my fancy framework". For whatever framework that may be.

Answer 4

As I understand it you use some DAOs to send/retrieve Pojos to/from the db.

Actually, there is no proper definition of Pojo. It's not a scientific term or anything. Pojo is a nickname for model or domain objects as they are otherwise called: The things your program is about. If your program is about books you probably have a class Book. And the Book should have all the functionality it needs to be a book.

The reason you factor out the db access is that it's not an inherent part of Book or whatever. (Although other schools of thought will disagree about that.) So there are only two kinds of things here: The model classes your program is about and utility classes providing db functionality.

The only reason not to put the business logic in the model classes, is changing the logic while keeping the model.