Introduction to Semantic Accessors

We all know how amazing is the code we write. How cool it is and how well is done.
But... It is?
The best way to know if your code is easy to understand AND use is give it someone with less experience.

I realise that the huge amount of time we don't code for others, we code for ourselves.
We write code, to make things easier to us, not to others.
Because we think if we understand it the others should.
But that is not the truth.

At some point in the future we will have to be that person that have to use our own code and believe me, you will forget how that was done.

Abstraction

The first step is abstract the parts of you code that you don't want others see or mess around. Think of it as if you where creating tools and you leave available the parts you want the people use.
So using public and private will be helpful.
I know that frameworks as Angular, the variables and properties are public by default, but I strongly recommend mark them as public if that is your intention.
Because you won't believe how fast code can turn unmaintainable after a few people jump in to fix some last-minute-to-production bugs.

Set public and private have an INTENTION, and someone that see that all the properties are public and/or private will think twice before leave a new property undefined.

My advice is to try to use as much as private properties as you can. Some plugins on VSCode will tell you if a property is not being use if they are private, otherwise if they are public there is no way to know if other part of the app is using them unless you specifically track them down.

Getters and Setters

Back in the old times getters and setters where part of every object you created. This practice has been in decrease in certain areas like front-end because you will have to duplicated and add extra variables for something that it will be easier if we simply set them as public. So I prefer only use setters and getters when the semantic helps.

Let's get SEMANTICS

I realise that testing tools are super semantic when they come to use expressions as close as we talk. So I thought, maybe we can do the same thing on regular code.
I wanted to use the help of autocomplete tool from the IDEs, so that way we won't have to remember of enter into some code to check what is available.

So the idea is wrap the properties we want to have available in a public object named GET.

I liked so much this idea that I create another object for the flags. Wrapped in an IS object.

The last think I have to do is create a last one for the main control of my service, so I did that.

The Grand Finale

You maybe think all these are extra steps, that duplicates code, but believe me when I say that all this is worth it. Of course we have to be careful not to add extra layer to the logic that makes everything repeated but you will see the advantages when you use these classes or services from outside.

With some help form the IDEs we won't have to remember what can be used and what is available for us:

Thanks to these techniques my whole team has increase their efficiency because they don't waste time trying to identify or remember the name of the methods or variables they need.

I hope you find this useful as well.