Getters and setters vs property accessors?

The instructor of my Android development class is manually and purposefully using setters and getters when the Kotlin language and Android Studio is strongly pushing for this property accessor way of handling private data fields. He says that it goes against the philosophy of hiding the data and keeping data fields private.

I’m all for property accessors, but I’m struggling to come up with a response for what he says. Modern programming languages like Kotlin and Swift have been strongly encouraging the use of property accessors.

@yowhatthefuck I think that in rapidly advancing fields like programming, teachers run a big risk of being stuck since they do not encounter enough real life challenges.

Its all up to the individual teacher own drive to keep up.

There should be some rotation out in the field for them, like internship, so they keep up.

Some are better than others of cause.

I apply C# logic to this

- always use properties
- use shorthand if you don't have custom logic for accessing or mutating
- use getters and setter explicitly when you do

If your model is just a sack of data sure, go ahead. Use getters/setters or just stop dancing around and make them public. If your models are are immutable (events, exceptions etc.), use named constructors w/ getters.

But in case the model is more than a DTO, add actual behavior and remove the getters. You can query data via read- and view models.

Just read it up to be sure...

https://kotlinlang.org/docs/...

I think there's a whole lot of confusion going on...

Most languages started property accessors to shorten code.

A property accessor is usually focused on wrapping a setter or getter to a variable by it's name. That's true for most languages.

So. Property accessor is in it's most basic form just a shortened version of an setter and getter.

Take a breath and let that sink in.

Now the more interesting part starts:

Visibility / Scope - aka
private, public and (only in some languages) protected / friendly

Here languages start to be different.

And the confusing part (which many people pointed out) starts.

Fact is: most property either define modifiers like public / private / protected or special keywords like var / val to define behaviour.

A good design makes use of behaviour by utilizing it to either hide it - mostly to allow reusage / abstraction / composition / polymorphic / ... - or to not hide it all.

The last part is where some coders get too high strung on theoretical books / people / internet telling them what to do.

At first an class with public fields might seem terryfying.

But if a class consists only of public fields, has no additional behaviour and no further inheritance / composition and so on....

Then it's just that. An isolated data container for data.

There's no OOP here and hence do not apply OOP. It's data - nothing more, nothing less.

That's what most people call an DTO - data transfer object.

public Bla {
public int age;
public string name;
}

It's as simple as that.

There are good arguments against accessors. Generally a developer expects model[property] to return the raw property on model. By adding custom logic in an accessor you defy that expectation.

(Especially In languages where property accessors weren't considered from the get-go [Javascript, PHP]) they can make code harder to debug, extend or overwrite and look like "magic".

Php doesn't have per-property accessors, but a single "magic" _get and _set method per class. The PHP framework Laravel heavily uses these and sometimes in ways that make code harder to read, i.e. by causing side effects/ state changes

@webketje
That sounds objectively awful and magic string riddled. Which is itself a code smell.

I tend to like accessors, especially for derivative properties when I'm forced to do OOP. No need for a backing field if the data is inferred. You also can't do lazy instantiation without an accessor of some kind.

There's also a difference between a contextual model, a viewmodel, a record and an entity.

@IntrusionCM in C# 9 that coming up you would use a record, which is an immutable value object for that.

I only wish it had not taken so long for them to get to this :/

So much code that could have been made easier.

And its supposed to help the compiler do aggressive optimization.

@Voxera
It took 3 years of us protesting the implementation to get them to follow F#'s records implementation.

Mads and gang don't have the respect for external ideas that Anders had.