2

Consider the following JavaScript code:

class MyClass {
   #myPrivateField;
   constructor() {
      #myPrivateField = new AnotherClass();
      this.theGetter.method1(); // or: this.#myPrivateField.method1(); 
      this.theGetter.method2(); // or: this.#myPrivateField.method2();
   }
   get theGetter() {
      return this.#myPrivateField;
   }
}

Obviously, invoking the "getter" method of theGetter causes some negligible overhead, or probably gets inlined. Inside of the class, the getter could've perfectly been alternated with a "direct access" notation (i.e, through this.#myPrivateField.method1(), for example).

Regardless of the performance penalty, in a software engineering perspective, why should or shouldn't I stick to one notation over the other inside the context of the class and what is the best practice in this regard?

  • 1
    @Kain0_0 Thanks for the response; It's more than a "stylistic" question: take for granted that the advocates of the "getter" usage may rationally argue that not only changing the "foundations" (i.e. the very private fields) would be trivial, but also it utilizes the the expressive public interface that improves readability; in this sense, what would the critics may validly argue? – goodUser Mar 23 at 7:47
  • 1
    I think the question you are asking is actually just Why use getters and setters/accessors?. Anyways, I'm not sure if those principles apply well in JavaScript context. – akuzminykh Mar 23 at 7:57
  • 1
    @akuzminykh Thanks for the response; The concepts do apply as JavaScript is an object oriented language and the same features are provided. Also, my question is more specific than: "whether or not to use the accessors (getters and setters) in general", but rather: "whether or not to utilize the getter notation inside the context of the class, and why?" – goodUser Mar 23 at 8:18
  • 1
    @VLAZ While the "private fields" are not yet in the "formal standard", but the support is getting widespread; Nevertheless, it's more of a Software Engineering question than a JavaScript-specific one! – goodUser Mar 23 at 8:28
  • 1
    @candied_orange The symbol of # indicates a private field in JavaScript. – goodUser Mar 23 at 11:00
3

Besides the general principles of Why use getters and setters/accessors? I try to answer that with an example, and focus on the usage class-internally as this is your question.


One thing for clarification: In Java there are two classes to represent a point in time regarding Coordinated Universal Time (UTC) where both have a method to get their value, which is in milliseconds, i.e. Date#getTime and Instant#toEpochMilli.


Imagine a class in two versions using Java:

class Data {
    private Date date;

    public Date getDate() {
        return date;
    }

    public long getMillis() {
        return date.getTime();
    }
}
class Data {
    private Date date;

    public Date getDate() {
        return date;
    }

    public long getMillis() {
        return getDate().getTime();
    }
}

Note that the first version uses the field directly while the second version uses the getter.

Now imagine I want to change the type of date to Instant thus I have to change the versions as follows. I will do minimal effort in changing. The first thing to change is obviously the field itself.

    private Instant date;

The second thing to change is the getter. But how? Do we change it to return the new type or do we a conversion?

    public Instant getDate() {
        return date;
    }
    public Date getDate() {
        return Date.fromInstant(date);
    }

Depending on how we changed the getter the method that uses the getter changes as follows.

    public long getMillis() {
        return getDate().toEpochMilli();
    }
    public long getMillis() {
        return getDate().getTime();
    }

As you can see, when we change the getter to convert from the previous type to the new type, we don't have to change the using method at all.

The version of the method that accesses the field directly has to be changed as follows.

    public long getMillis() {
        return date.toEpochMilli();
    }

Now I hope this clarifies the benefit of using the getter inside the class itself. You will have less effort to put in when refactoring the code. But is it worth it?

Maybe you don't want to use the previous type anymore at all. Maybe the trouble to refactor the class is minimal. Maybe the factor readability comes into place. How will the class potentially change, may there be a functionality in the getter in the future? Are there conventions in my company?

All those questions' answers depend on the specific use case thus there is no generalized answer.

Anyways, I suggest to use the fields directly as (from my experience) the refactoring doesn't hurt and brings more benefits most of the time. You will have cleaner code and no strange mixtures of concepts. If you are not sure, just do the most simple and readable solution.


The answer disregards the case where the getter/setter does more than just getting/setting the field. In that case you obviously always want to use the getter/setter.

| improve this answer | |
  • 1
    +1: I do appropriate the efforts to convey your idea, thank you. I'm looking for a more engineering analytics and comparisons. However the "getter" approach does really seem to fit more appropriately in this regard as it's capable of returning dynamically computed value and perfectly reflects the status of an internal variable in a readonly manner; Additionally, in my specific case in JavaScript, unlike Java, the getter methods are invoked merely by their name, without the invocation-parenthesis: (), as though they're "properties", which adds to elegance and readability even further. – goodUser Mar 23 at 11:38
1

Check the semantics first. Someone might subclass your class and (mis-)override the getter to not to return the instance variable. In this sense, utilizing the getter instead of the instance variable is wrong, even in the base class itself.

On the other hand, you might not allow subclassing.

| improve this answer | |
  • Interesting points, thanks for the response. – goodUser Mar 25 at 12:30

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.