0

I am trying to build a constructor for a class that represents an Object. Thing is I am not sure which way would be better, using getters/setters in my constructors/methods or just use the "=" operator (keep in mind this is exactly what my setter does). 

public class Object{
int x;
public Object()
{
       x = 1;
}

public Int objectsInt(Object other)
{
        if(other!=null)
        {
           this.x = other.x;
           return other.x;
        }
        else
        {
           return 0;
        }
}
}

// or 

public class Object{
int x;
public Object()
{
       Object obj = new Object();
       obj.setObjInt(1);
}

public int objectsInt(Object other)
{
        if(other!=null)
        {
           Object obj = new Object();
           obj.setObjInt(other.getObjInt)
           return obj.getObjInt;
        }
        else
        {
           return 0;
        }
}

public int getObjInt()
{
        return x;
}

public void setObjInt(int x)
{
        this.x = x  ;
}
}

or maybe there is a different way I didn't think of. p.s. this is just a demonstration not my real code, the Object class is a lot more complex so I made it simple as possible for you to understand my intention.

WhiteLister
  • 15
  • 5
  • 2
    Well for starts, your second code sample is going to get some infinite recursion going because your constructor calls itself in the first line. – mypetlion Dec 02 '19 at 21:43
  • Have you tried testing both pieces of code? The second one will result in an error due to the call stack overflowing, since your constructor calls itself unconditionally. – kaya3 Dec 02 '19 at 21:43
  • As far as I know this is entirely opinion/convention based. *Personally*, I find that `this.x = x` **feels** like it is more lightweight, since it doesn't spool up an entire method. Whether or not this actually makes a difference in Java, I don't know. Just my preference. – matthew-e-brown Dec 02 '19 at 21:45
  • Neither is "better" or "worse" than the other, but which you would use would depend on the context in which you want to use them and the problem you are trying to solve. "Copy" normally would return a new instance of the object, with the same properties copied over to it. Setting a property (by using another instance reference) this way seems wrong to me (IMHO) and I'd simply use `set/getX` instead, but that's me. If you want to create a different object, which is based on some (or all) of the properties of the first, I might consider using a factory pattern instead – MadProgrammer Dec 02 '19 at 21:47
  • In you second example you are creating a second new instance of an Object in the constructor. You should not do this. Instead just call the instance method directly with setObjInt(1); – bhspencer Dec 02 '19 at 21:49
  • 1
    @matthew-e-brown Java "tends" to prefer setters/getters (accessors) as it maintains encapsulation, but, for every rule ;) – MadProgrammer Dec 02 '19 at 21:49
  • Does this answer your question? [Advantage of set and get methods vs public variable](https://stackoverflow.com/questions/11071407/advantage-of-set-and-get-methods-vs-public-variable) – MyStackRunnethOver Dec 02 '19 at 21:50
  • More than preference for setters and getters I recommend you put you effort on understanding how how constructors and instance methods work. You are creating extra instances in a couple of places here that mean your code wont work. – bhspencer Dec 02 '19 at 21:50
  • Thank you all for the quick response. – WhiteLister Dec 02 '19 at 22:01
  • I personally use the first code segment (it is an assignment in java class.) and my friend uses the other segment, but it seems to me it is not needed in our case and the first segment will run faster. @MyStackRunnethOver thank you but I already know the benefits of getters/setters - i was curious if it makes a huge impact on the code above or not. – WhiteLister Dec 02 '19 at 22:08
  • Getters/setters actually break encapsulation, as it exposes an underlying property of the object - can read more about it [here](https://softwareengineering.stackexchange.com/a/358612/139941). The purpose of OOP is to interact with objects via their behaviors. An object should be designed with a responsibility in mind, and it should expose behaviors that allow handling of that responsibility, while keeping it's properties hidden. Although a getter does allow easy access to properties for things such as printing, it creates tight coupling (content coupling), harming maintainability. – Dioxin Dec 03 '19 at 14:01
  • Focus on how the property will be used - *why* does `x` exist? What logic is it going to be used for? Printing? Arithmetic? Comparison? All 3? If so, your object should expose methods allowing such, rather than exposing the property itself. That way, clients (and future debuggers) know exactly where and why the property is being used. Your example doesn't express any responsibility, so it's hard to suggest what behavioral methods it would expose opposed to getter/setters. – Dioxin Dec 03 '19 at 14:06

0 Answers0