It's all about encapsulation

If you want to violate pretty much every piece of advice about data encapsulation in the OOP book then just expose the internal state of your object to all and sundry. Simply make the field public and off you go. Before long all those references you're handing out will get modified by some distant call of a call of a call and your object is none the wiser - until it comes to perform some operation that results in epic failure.

Epic fail? I don't want that...

If you want to make sure that only your object is changing it's own internal state then getters/setters are the way to go. The getter/setter guards the internal state making sure that external classes have no other way to get at it. (OK, I hear your subclassing, reflection yada yada ...)

Got an example to clinch it?

Consider exposing arrays. If you do it directly through a getter, such as this (in Java)

public byte[] getRedBackgroundPDF() { return this.redPDF; } 

you get an epic fail because the byte[] is passed by reference and so external classes can modify the internals of your class, bypassing the purpose of the getter. The PDF can be modified in some manner (say to make it have a blue background) and your class has no idea.

To overcome this, you need to clone so that the external classes effectively get a read-only version of the byte[].

public byte[] getRedBackgroundPDF() { return Arrays.copyOf(this.redPDF,this.redPDF.length) ; } 

External code may change this to be blue, but every time anyone else visits the getRedBackgroundPDF() method they'll always start off with a red background.

It seems unnecessary and ugly, but it protects your internal state.

No code is trivial

If, at runtime, the CPU executes it, then it is non-trivial because it is having an effect.

It's all about encapsulation

If you want to violate pretty much every piece of advice about data encapsulation in the OOP book then just expose the internal state of your object to all and sundry. Simply make the field public and off you go. Before long all those references you're handing out will get modified by some distant call of a call of a call and your object is none the wiser - until it comes to perform some operation that results in epic failure.

Epic fail? I don't want that...

If you want to make sure that only your object is changing it's own internal state then getters/setters are the way to go. The getter/setter guards the internal state making sure that external classes have no other way to get at it. (OK, I hear your subclassing, reflection yada yada ...)

Got an example to clinch it?

Consider exposing arrays. If you do it directly through a getter, such as this (in Java)

public byte[] getRedBackgroundPDF() { return this.redPDF; } 

you get an epic fail because the byte[] is passed by reference and so external classes can modify the internals of your class, bypassing the purpose of the getter. The PDF can be modified in some manner (say to make it have a blue background) and your class has no idea.

To overcome this, you need to clone so that the external classes effectively get a read-only version of the byte[].

public byte[] getRedBackgroundPDF() { return Arrays.copyOf(this.redPDF,this.redPDF.length) ; } 

External code may change this to be blue, but every time anyone else visits the getRedBackgroundPDF() method they'll always start off with a red background.

It seems unnecessary and ugly, but it protects your internal state.

It's all about encapsulation

If you want to violate pretty much every piece of advice about data encapsulation in the OOP book then just expose the internal state of your object to all and sundry. Simply make the field public and off you go. Before long all those references you're handing out will get modified by some distant call of a call of a call and your object is none the wiser - until it comes to perform some operation that results in epic failure.

Epic fail? I don't want that...

If you want to make sure that only your object is changing it's own internal state then getters/setters are the way to go. The getter/setter guards the internal state making sure that external classes have no other way to get at it. (OK, I hear your subclassing, reflection yada yada ...)

Got an example to clinch it?

Consider exposing arrays. If you do it directly through a getter, such as this (in Java)

public byte[] getPDF() { return this.pdf; } 

you get an epic fail because the byte[] is passed by reference and so external classes can modify the internals of your class, bypassing the purpose of the getter.

To overcome this, you need to clone so that the external classes effectively get a read-only version of the byte[].

public byte[] getPDF() { return Arrays.copyOf(this.pdf,this.pdf.length) ; } 

It seems unnecessary and ugly, but it protects your internal state.

It's all about encapsulation

If you want to violate pretty much every piece of advice about data encapsulation in the OOP book then just expose the internal state of your object to all and sundry. Simply make the field public and off you go. Before long all those references you're handing out will get modified by some distant call of a call of a call and your object is none the wiser - until it comes to perform some operation that results in epic failure.

Epic fail? I don't want that...

If you want to make sure that only your object is changing it's own internal state then getters/setters are the way to go. The getter/setter guards the internal state making sure that external classes have no other way to get at it. (OK, I hear your subclassing, reflection yada yada ...)

Got an example to clinch it?

Consider exposing arrays. If you do it directly through a getter, such as this (in Java)

public byte[] getRedBackgroundPDF() { return this.redPDF; } 

you get an epic fail because the byte[] is passed by reference and so external classes can modify the internals of your class, bypassing the purpose of the getter. The PDF can be modified in some manner (say to make it have a blue background) and your class has no idea.

To overcome this, you need to clone so that the external classes effectively get a read-only version of the byte[].

public byte[] getRedBackgroundPDF() { return Arrays.copyOf(this.redPDF,this.redPDF.length) ; } 

External code may change this to be blue, but every time anyone else visits the getRedBackgroundPDF() method they'll always start off with a red background.

It seems unnecessary and ugly, but it protects your internal state.