1

This is more general question to any OOP, please before answer consider readability and efficiency. Here is example in Javascript:

function fnc () {

   this.var = "abc";

   this.setVar = function (val) {
      this.var = val;
   }

   this.getVar = function () {
      return this.var;
   }

}

Now, i can set value of var via method:

fnc.setvar("abc");

or 

fnc.var = "abc";

I can also get it directly:

console.log(fnc.var)

or via get method:

console.log(fnc.getVar())

Here comes the question:

If the result is the same which option is better? what are the pros and cons for direct or method way?

Kalreg
  • 982
  • 1
  • 13
  • 27

2 Answers2

1

This highly depends on the features and patterns used in a given language.

Behaviour driven languages

In Java or C++ classes are defined by their behaviour, read "methods". The interfaces and the whole inheritance are based on methods. Fields are 2nd class citizens. Therefore you use methods to get and set attributes. This is the only way of overriding the access and ensuring the integration is correct after you change something later on. Having all fields hidden behind methods also enables you finer grained control (for example getter without a corresponding setter, or a setter that does a calculation instead of simply setting an attribute), but you need a lot of boilerplate, so you write lots of code that does not really add to your business logic and makes the code harder to read from within the class. What makes the code harder to read, however, makes it easier to understand from the client-side through interfaces, as they fully define a class. This concept of methods over attributes usually comes along with visibility settings for methods and attributes. This way you define what is meant for outside world and what is meant for this class or package only. Attributes are almost always private (read "for this class only").

Property driven languages

In languages like JavaScript or Python classes/objects are defined by their fields, read "attributes". Even methods are nothing more than attributes and so both methods and attributes can be overriden (or hidden), switched at runtime etc. Given that you gain nothing but false security using getters and setters, and given that every function call less means better performance and shorter stacktrace, using fields directly is the preferred usage in scripting languages. Regarding readability: the code itself is much easier to read and to understand, but interfaces as known from behaviour based languages don't exist here except in form of documentation (if the code author writes one). Visibility of methods and attributes is usually always public, but some languages offer special annotations or naming schemas to show which methods or fields are meant to be private. There is no strong or no enforcement at all though.

BTW-JFYI: Python has a special solution for the extendability of fields: properties. This is a special thing which enables you using getter and setter with proper logic inside the class but present the field as plain attribute to the outside world. See Python @property versus getters and setters for further reading.

Community
  • 1
  • 1
Hubert Grzeskowiak
  • 15,137
  • 5
  • 57
  • 74
  • Never heard the terms "behaviour driven" vs. "property driven" languages. Could you post a reference? – Frank Puffer Mar 27 '16 at 20:16
  • Sorry, but I have none. The text above is based solely on my experience. There are probably better terms for the two paradigms described above. – Hubert Grzeskowiak Mar 27 '16 at 20:34
  • JS has the same property approach as Python, no? That aside, I didn't read much in your descriptions of two paradigms that strongly differentiates between the two, and some that apply equally across both. – Dave Newton Mar 27 '16 at 20:49
  • @DaveNewton the whole text is all about the differences. Which part applies to both paradigms? – Hubert Grzeskowiak Mar 27 '16 at 21:22
  • @HubertGrzeskowiak Much of it, AFAICT. I read it more as differences between static/dynamic typing, runtime dynamism, and language implementation details. Other than "Java exposes properties through getters and Python [and JS] doesn't have to" and "accessors make code harder to read [in Java-the-language]" what have you actually said? Unrelated, but C doesn't have classes. – Dave Newton Mar 27 '16 at 22:36
  • @HubertGrzeskowiak A comment isn't enough space; [here's a gist that enumerates some of my observations](https://gist.github.com/davelnewton/c12a9ec48f8c8e165d51). – Dave Newton Mar 27 '16 at 22:57
  • @DaveNewton some good points you have there. I suggest you write your own answer to this question. – Hubert Grzeskowiak Mar 28 '16 at 01:47
1

Don't consider the immediate result only. Most software is going to be modified at some point. Considering that, you are more flexible when using getter and setter methods as opposed to direct attribute access.

However the best option - if applicable - is to not use setters at all but create immutable objects.

Frank Puffer
  • 8,135
  • 2
  • 20
  • 45