-4

I have a problem during a project of mine using Java, as usual my java classes have the structure:

import ...;
import ...;
...
private Type0 myVariable0;
private Type1 myVariable1;
...
...
private Type99 myVariable99;

MyConstructor()
...
MyGetter0();
...
MyGetter99();
MySetters(MyType0 MyVariable0)
...
MySetters(MyType99 MyVariable99)

My PHD supervisor complaints all the time that my class structure is not readable due to lots of variables declared, and lots of getters and setters. I am using Java for my project and I don't know C++, but I studied his implementation of my project in C++, and he does not use lots of global variables for the whole class, instead he has lots of local variables into functions.

Is it possible to encapsulate private variables into Java methods only, avoiding to use class member variables? I believe that is not possible. I have tried to restructure my above code but I cannot manage.

Is it the solutions to split the code into multiple classes only, or is there another generic way that I miss to restructure the whole POJO structure putting variables into class methods?

Thanks in advance.

  • If it's a POJO you're after: geeksforgeeks.org/pojo-vs-java-beans – Robert Harvey Dec 29 '19 at 16:44
  • Beyond that, it's hard to advise you because we don't know what "ugly" means in this context. – Robert Harvey Dec 29 '19 at 16:45
  • Ugly is the POJO structure I have indicated in code. My question is can we have a POJO functionality with another structure (i.e. private variables into methods?) – Novemberland Dec 29 '19 at 16:47
  • @RobertHarvey That is a distressingly limited view of what a POJO is. – candied_orange Dec 29 '19 at 16:48
  • @Novemberland what is ugly about that structure? Please edit your question before it's closed – candied_orange Dec 29 '19 at 16:49
3

I think it's important to understand proper OOP from a traditional sense, and what is necessary for data binding, etc. Java introduced the JavaBean (POJO with only getters and setters) to bind to the user interface. Most people are not building user interfaces in Java these days, but they still have their place. First, let's distinguish between OOP and traditional procedural programming:

Object Oriented Programming:

  • Emphasizes data hiding (i.e. internal data is not accessible directly)
  • Only exposes methods to manipulate the object
  • SOLID principles

As an example, lets say we have a PlayerCharacter class for a game:

public class PlayerCharacter {
    private int defense;
    private int hitPoints;

    public PlayerCharacter() {
        defense = 5;
        hitPoints = 15;
    }

    public PlayerState receiveHit(int attackStrength) {
        int hitStrength = Math.Max(attackStrength - defense, 0);
        hitPoints = Math.Max(hitPoints - hitStrength, 0);

        return hitPoints > 0 ? PlayerState.Alive : PlayerState.Dead;
    }
}

You'll notice that there is no way for any other class to know what the hitPoints or defense values are. The class is fully contained, making it opaque. The method receives all the external information it needs as parameters. This allows you to replace the very simplistic algorithm I have for calculating damage done with something more complex. This class represents OOP from the traditional interpretation.

Data Objects and Services (AKA Procedural with Objects)

The JavaBean approach is very much like a C struct. You have all your object state available outside of the class, allowing other objects to modify it's state directly. It is entirely possible to write running applications that use this approach. In fact, it's actually quite common these days.

In writing code for the server, it is very common for developers to use Object-Relational Mapping (ORM) tools like hibernate. They bind database rows to POJOs, hiding the code to synchronize changes to the database. Again, the JavaBean approach is used for binding, but this time to the back end.

Services are then written to manipulate the data objects (i.e. the name spaces for functions).

This approach is not traditional OOP, but it works very well for a certain class of applications.

Your PHD Supervisor

Your professor is trying to teach you proper OOP. It's a valuable skill to have, and knowing the trade-offs will only help you build better systems in the future. There is a lot of strength in the traditional OOP approach, since it does lend itself better to reuse.

It's better to have more, but smaller self-contained objects with your professor. It also makes your code easier to spot errors in.

When you get in the real world, you'll have to make decisions based on how your team designed the code to work.

| improve this answer | |
  • Well, I'm glad someone brought their magic 8 ball this morning. – Robert Harvey Dec 29 '19 at 16:53
  • Except of splitting variables into different classes is there another way? (I am using a framework and I use the classes that I should use, it is hard to split them to different classes) – Novemberland Dec 29 '19 at 17:15
  • @Novemberland: You have to identify what your PhD Supervisor means by "ugly" first. "Ugly" all by itself is not actionable; I've seen a whole lot of ugly code in my time that still does its job. – Robert Harvey Dec 29 '19 at 19:17
  • @RobertHarvey I've edited ugly to not readable... – Novemberland Dec 29 '19 at 19:20
  • @Novemberland: I think you still need to ask your PhD Supervisor to be more specific. Is the problem too many variables? Something else? – Robert Harvey Dec 29 '19 at 19:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.