2 grammar stuff (subject verb agreement, correct use of it's and its)
source | link

Quick answer : Using getter and setter methods in the way you describe will most likely be fine. And removing them will not solve any concrete problem.

Longer answer

RembemberRemember that encapsulation is about information hiding. Formally, what you want is a data structure - your private fields - that is only ever accessed and modified via a fixed set of routineroutines - your methods. That improveimproves maintenance, because if you want to change the inner data-structure, you only have to go through your finite set of routineroutines to make the update, rather than the whole program. ItsIt's easy to see the advantage :) .

The problem in get/set come when you expose implementation information. LetsLet's take the example of exposing a database connection. Suddenly, you declared to the world that your object talktalks to a database. Client code will use that connection to do other stuff. 2 years later, you remove the database, itsit's not needed anymore. But the client code expectexpects a connection to the old database! You can't change your object the way you want, and you have to carry around useless junk... you have exposed details you shouldn't!

In otheranother case, though, you don't have something to hide : A Customer is an ID, a name and a phone number. Don't hide that, it's the very thing client code needneeds! Multiple partparts of the application require this to do their job : your UI will display a formatted version to the user, your database will save and read the value, a JSON library will serialize the information to send an order to a 3rd party. This is business information. It need to be accessible to be useful. In that case, a getter - and maybe a setter - is perfectly valid.

In your case : If the getter in your business logic hidehides your model, it's perfectly fine. Use them. A getter-less design may not be better.

As a finishing note : people are often against getter because of something called "tell don't ask". This is a whole different issue than encapsulation. ItsIt's a design philosophy, and the benefitbenefits are less clear than with information hiding. The laterlatter was already knowknown in the 70s, while the former is a more recent invention. "Tell don't ask" is wonderfullwonderful for some applicationapplications - event driven oneones in particular. Alas, it work poorly with CRUD applicationapplications, where the whole point is to ask about information. Assuming you're outside the specific set of problemproblems "tell don't ask" solvesolves, use getters without any guilt. Just remember to hide your implementation.

Quick answer : Using getter and setter in the way you describe will most likely be fine. And removing them will not solve any concrete problem.

Longer answer

Rembember that encapsulation is about information hiding. Formally, what you want is a data structure - your private fields - that is only ever accessed and modified via a fixed set of routine - your methods. That improve maintenance, because if you want to change the inner data-structure, you only have to go through your finite set of routine to make the update, rather than the whole program. Its easy to see the advantage :) .

The problem in get/set come when you expose implementation information. Lets take the example of exposing a database connection. Suddenly, you declared to the world that your object talk to a database. Client code will use that connection to do other stuff. 2 years later, you remove the database, its not needed anymore. But the client code expect a connection to the old database! You can't change your object the way you want, and you have to carry around useless junk... you have exposed details you shouldn't!

In other case, though, you don't have something to hide : A Customer is an ID, a name and a phone number. Don't hide that, it's the very thing client code need! Multiple part of the application require this to do their job : your UI will display a formatted version to the user, your database will save and read the value, a JSON library will serialize the information to send an order to a 3rd party. This is business information. It need to be accessible to be useful. In that case, a getter - and maybe a setter - is perfectly valid.

In your case : If the getter in your business logic hide your model, it's perfectly fine. Use them. A getter-less design may not be better.

As a finishing note : people are often against getter because of something called "tell don't ask". This is a whole different issue than encapsulation. Its a design philosophy, and the benefit are less clear than with information hiding. The later was already know in the 70s, while the former is a more recent invention. "Tell don't ask" is wonderfull for some application - event driven one in particular. Alas, it work poorly with CRUD application, where the whole point is to ask about information. Assuming you're outside the specific set of problem "tell don't ask" solve, use getters without any guilt. Just remember to hide your implementation.

Quick answer : Using getter and setter methods in the way you describe will most likely be fine. And removing them will not solve any concrete problem.

Longer answer

Remember that encapsulation is about information hiding. Formally, what you want is a data structure - your private fields - that is only ever accessed and modified via a fixed set of routines - your methods. That improves maintenance, because if you want to change the inner data-structure, you only have to go through your finite set of routines to make the update, rather than the whole program. It's easy to see the advantage :) .

The problem in get/set come when you expose implementation information. Let's take the example of exposing a database connection. Suddenly, you declared to the world that your object talks to a database. Client code will use that connection to do other stuff. 2 years later, you remove the database, it's not needed anymore. But the client code expects a connection to the old database! You can't change your object the way you want, and you have to carry around useless junk... you have exposed details you shouldn't!

In another case, though, you don't have something to hide : A Customer is an ID, a name and a phone number. Don't hide that, it's the very thing client code needs! Multiple parts of the application require this to do their job : your UI will display a formatted version to the user, your database will save and read the value, a JSON library will serialize the information to send an order to a 3rd party. This is business information. It need to be accessible to be useful. In that case, a getter - and maybe a setter - is perfectly valid.

In your case : If the getter in your business logic hides your model, it's perfectly fine. Use them. A getter-less design may not be better.

As a finishing note : people are often against getter because of something called "tell don't ask". This is a whole different issue than encapsulation. It's a design philosophy, and the benefits are less clear than with information hiding. The latter was already known in the 70s, while the former is a more recent invention. "Tell don't ask" is wonderful for some applications - event driven ones in particular. Alas, it work poorly with CRUD applications, where the whole point is to ask about information. Assuming you're outside the specific set of problems "tell don't ask" solves, use getters without any guilt. Just remember to hide your implementation.

1
source | link

Quick answer : Using getter and setter in the way you describe will most likely be fine. And removing them will not solve any concrete problem.

Longer answer

Rembember that encapsulation is about information hiding. Formally, what you want is a data structure - your private fields - that is only ever accessed and modified via a fixed set of routine - your methods. That improve maintenance, because if you want to change the inner data-structure, you only have to go through your finite set of routine to make the update, rather than the whole program. Its easy to see the advantage :) .

The problem in get/set come when you expose implementation information. Lets take the example of exposing a database connection. Suddenly, you declared to the world that your object talk to a database. Client code will use that connection to do other stuff. 2 years later, you remove the database, its not needed anymore. But the client code expect a connection to the old database! You can't change your object the way you want, and you have to carry around useless junk... you have exposed details you shouldn't!

In other case, though, you don't have something to hide : A Customer is an ID, a name and a phone number. Don't hide that, it's the very thing client code need! Multiple part of the application require this to do their job : your UI will display a formatted version to the user, your database will save and read the value, a JSON library will serialize the information to send an order to a 3rd party. This is business information. It need to be accessible to be useful. In that case, a getter - and maybe a setter - is perfectly valid.

In your case : If the getter in your business logic hide your model, it's perfectly fine. Use them. A getter-less design may not be better.

As a finishing note : people are often against getter because of something called "tell don't ask". This is a whole different issue than encapsulation. Its a design philosophy, and the benefit are less clear than with information hiding. The later was already know in the 70s, while the former is a more recent invention. "Tell don't ask" is wonderfull for some application - event driven one in particular. Alas, it work poorly with CRUD application, where the whole point is to ask about information. Assuming you're outside the specific set of problem "tell don't ask" solve, use getters without any guilt. Just remember to hide your implementation.