Return to Answer

This tenancy of OO to focus on methods instead data is why getters enter the picture because OO places more value on methods for their flexibility. For example String.getBytes must violate encapsulation right? It's exposing the String's implementation detail right? Well not exactly. I could implement a String with a char array and dynamically transform that to a byte array when getBytes method to provide the String is various encodings (ie UTF-8, UTF-16, etc) is called. If you didn't have a method that returned you the byte array and you needed it. Then you'd have to get the underlying char array in the string in order to write that method outside of the String object. That would most definitely violate encapsulation.

And that's the thing about this that is tricky. If your requirements demand you have knowledge about character encodings of a String the best way to handle that is to delegate that conversion to the owner of that data to perform the operation for you. That's how OO and encapsulation helps you. By calling that getBytes method you are codifying that as a requirement in your program. OO and encapsulation doesn't let you transcend the requirements.

This tenancy of OO to focus on methods instead data is why getters enter the picture because OO places more value on methods for their flexibility. For example String.getBytes must violate encapsulation right? It's exposing the String's implementation detail right? Well not exactly. I could implement a String with a char array and dynamically transform that to a byte array when getBytes method to provide the String is various encodings (ie UTF-8, UTF-16, etc) when it's called. If you didn't have a method that returned you the byte array and you needed it. Then you'd have to get the underlying char array in the string in order to write that method outside of the String object. That would most definitely violate encapsulation.

And that's the thing about this that is tricky. If your requirements demand you have knowledge about character encodings of a String the best way to handle that is to delegate that conversion to the owner of that data to perform the operation for you. That's how OO and encapsulation helps you. By calling that getBytes method you are codifying that as a requirement in your program. OO and encapsulation doesn't let you transcend the requirements.

In fact I will even go another step and say that if you have getters/setters on your object you are practicing encapsulation. And YES even if you return the internal guts of your implementation through a getter! Controversial stance I know, but hear me out. Because you've used a method in order to reveal potential internal workings of a class to the client you haven't prevented yourself into changing those internals later. That's the core test of encapsulation. If you allowed direct access to the instance variables you'd have violated encapsulation and thereby locked yourself into not being able to refactor it. But if you use a getter you can always change the object's internal representation and simply change your getter method without affecting clients. And that is the point of encapsulation. Now you are locked into providing that method (until all clients are changed), but you are still insulating your ability to change from clients.

I think the principle that all getters somehow violate oop principles at some fundamental level is wrong. If I have a string class and I want to know how long the string is by calling getLength does that mean it's not pure OOP? No! Of course it doesn't; that's preposterous. A string of characters has a length. It's inherent to the properties of the string. Just like people have names, ages, birthdays, and preferences of color. Exposing those properties doesn't violate the principles of encapsulation in oop.

Sharing information inherent to the model or problem domain doesn't violate OOP. What good is an array, list, or collection if you can't get the contents of it? And this gets at the limitations of what encapsulation, as a principle, are trying to solve. Encapsulation is there to prevent implementation coupling. It's not trying to prevent coupling of data. If I call getLength on a string then I can't work with string that doesn't have a length. Therefore I'm coupled or depends upon that data or detail.

Coupling happens. It has to happen in order to build software. But all OOP is meant to handle is implementation coupling not other forms of coupling like data or interface. It's a much lower bar OOP is trying to solve or really provide mechanisms to let you solve it. Something critics are quick to confuse encapsulation in all it's forms as somehow reasons to discredit OO for not solving all forms when it never intended to.

And this is where the concept of interfaces comes in. Because OO programs couple themselves to interfaces used, that meaning the methods that are called. But if another object implements the same interface then you could substitute one for the other and the code would work all the same. So most OO languages provide some mechanism to declare these interfaces to formally declare these integration points. And most haven't evolved to focus on interfaces based around methods rather than properties because they provide far more flexibility than data properties do.

This tenancy of OO to focus on methods instead data is why getters enter the picture because OO places more value on methods for their flexibility. For example String.getBytes must violate encapsulation right? It's exposing the String's implementation detail right? Well not exactly. I could implement a String with a char array and dynamically transform that to a byte array when getBytes method to provide the String is various encodings (ie UTF-8, UTF-16, etc) is called. If you didn't have a method that returned you the byte array and you needed it. Then you'd have to get the underlying char array in the string in order to write that method outside of the String object. That would most definitely violate encapsulation.

And that's the thing about this that is tricky. If your requirements demand you have knowledge about character encodings of a String the best way to handle that is to delegate that conversion to the owner of that data to perform the operation for you. That's how OO and encapsulation helps you. By calling that getBytes method you are codifying that as a requirement in your program. OO and encapsulation doesn't let you transcend the requirements.

That's why OO focuses on methods as its preferred way of coupling. They offer a flexible place to insert logic to provide and integration point on which to base your dependencies.

I think the principle that all getters somehow violate oop principles at some fundamental level is wrong. If I have a string class and I want to know how long the string is by calling getLength does that mean it's not pure OOP? No! Of course it doesn't; that's preposterous. A string of characters has a length. It's inherent to the properties of the string. Just like people have names, ages, birthdays, and preferences of color. Exposing those properties doesn't violate the principles of encapsulation in oop.

Sharing information inherent to the model or problem domain doesn't violate OOP. What good is an array, list, or collection if you can't get the contents of it? And this gets at the limitations of what encapsulation, as a principle, are trying to solve. Encapsulation is there to prevent implementation coupling. It's not trying to prevent coupling of data. If I call getLength on a string then I can't work with string that doesn't have a length. Therefore I'm coupled or depends upon that data or detail.

Coupling happens. It has to happen in order to build software. But all OOP is meant to handle is implementation coupling not other forms of coupling like data or interface. It's a much lower bar OOP is trying to solve or really provide mechanisms to let you solve it. Something critics are quick to confuse encapsulation in all it's forms as somehow reasons to discredit OO for not solving all forms when it never intended to.

And this is where the concept of interfaces comes in. Because OO programs couple themselves to interfaces used, that meaning the methods that are called. But if another object implements the same interface then you could substitute one for the other and the code would work all the same. So most OO languages provide some mechanism to declare these interfaces to formally declare these integration points. And most have evolved to focus on interfaces based around methods rather than properties because they provide far more flexibility than data properties do.

This tenancy of OO to focus on methods instead data is why getters enter the picture because OO places more value on methods for their flexibility. For example String.getBytes must violate encapsulation right? It's exposing the String's implementation detail right? Well not exactly. I could implement a String with a char array and dynamically transform that to a byte array when getBytes method to provide the String is various encodings (ie UTF-8, UTF-16, etc) is called. If you didn't have a method that returned you the byte array and you needed it. Then you'd have to get the underlying char array in the string in order to write that method outside of the String object. That would most definitely violate encapsulation.

And that's the thing about this that is tricky. If your requirements demand you have knowledge about character encodings of a String the best way to handle that is to delegate that conversion to the owner of that data to perform the operation for you. That's how OO and encapsulation helps you. By calling that getBytes method you are codifying that as a requirement in your program. OO and encapsulation doesn't let you transcend the requirements.

That's why OO focuses on methods as its preferred way of coupling. They offer a flexible place to insert logic to provide and integration point on which to base your dependencies.

I think the principle that all getters somehow violate oop principles at some fundamental level is wrong. If I have a string class and I want to know how long the string is by calling getLength does that mean it's not pure OOP? No! Of course it doesn't; that's preposterous. A string of characters has a length. It's inherent to the properties of the string. Just like people have names, ages, birthdays, and preferences of color. Exposing those properties doesn't violate the principles of encapsulation in oop.

Sharing information inherent to the model or problem domain doesn't violate OOP. What good is an array, list, or collection if you can't get the contents of it? And this gets at the limitations of what encapsulation, as a principle, are trying to solve. Encapsulation is there to prevent implementation coupling. It's not trying to prevent coupling of data. If I call getLength on a string then I can't work with string that doesn't have a length. Therefore I'm coupled or depends upon that data or detail.

Coupling happens. It has to happen in order to build software. But all OOP is meant to handle is implementation coupling not other forms of coupling like data or interface. It's a much lower bar OOP is trying to solve or really provide mechanisms to let you solve it. Something critics are quick to confuse encapsulation in all it's forms as somehow reasons to discredit OO for not solving all forms when it never intended to.

And this is where the concept of interfaces comes in. Because OO programs couple themselves to interfaces used, that meaning the methods that are called. But if another object implements the same interface then you could substitute one for the other and the code would work all the same. So most OO languages provide some mechanism to declare these interfaces to formally declare these integration points. And most haven't evolved to focus on interfaces based around methods rather than properties because they provide far more flexibility than data properties do.

This tenancy of OO to focus on methods instead data is why getters enter the picture because OO places more value on methods for their flexibility. For example String.getBytes must violate encapsulation right? It's exposing the String's implementation detail right? Well not exactly. I could implement a String with a char array and dynamically transform that to a byte array when getBytes method is called. If you didn't have a method that returned you the byte array and you needed it. Then you'd have to get the underlying char array in the string in order to write that method outside of the String object. That would most definitely violate encapsulation.

That's why OO focuses on methods as it's preferred way of coupling. They offer a flexible place to insert logic to provide and integration point on which to base your dependencies.

I think the principle that all getters somehow violate oop principles at some fundamental level is wrong. If I have a string class and I want to know how long the string is by calling getLength does that mean it's not pure OOP? No! Of course it doesn't; that's preposterous. A string of characters has a length. It's inherent to the properties of the string. Just like people have names, ages, birthdays, and preferences of color. Exposing those properties doesn't violate the principles of encapsulation in oop.

Sharing information inherent to the model or problem domain doesn't violate OOP. What good is an array, list, or collection if you can't get the contents of it? And this gets at the limitations of what encapsulation, as a principle, are trying to solve. Encapsulation is there to prevent implementation coupling. It's not trying to prevent coupling of data. If I call getLength on a string then I can't work with string that doesn't have a length. Therefore I'm coupled or depends upon that data or detail.

Coupling happens. It has to happen in order to build software. But all OOP is meant to handle is implementation coupling not other forms of coupling like data or interface. It's a much lower bar OOP is trying to solve or really provide mechanisms to let you solve it. Something critics are quick to confuse encapsulation in all it's forms as somehow reasons to discredit OO for not solving all forms when it never intended to.

And this is where the concept of interfaces comes in. Because OO programs couple themselves to interfaces used, that meaning the methods that are called. But if another object implements the same interface then you could substitute one for the other and the code would work all the same. So most OO languages provide some mechanism to declare these interfaces to formally declare these integration points. And most haven't evolved to focus on interfaces based around methods rather than properties because they provide far more flexibility than data properties do.

This tenancy of OO to focus on methods instead data is why getters enter the picture because OO places more value on methods for their flexibility. For example String.getBytes must violate encapsulation right? It's exposing the String's implementation detail right? Well not exactly. I could implement a String with a char array and dynamically transform that to a byte array when getBytes method to provide the String is various encodings (ie UTF-8, UTF-16, etc) is called. If you didn't have a method that returned you the byte array and you needed it. Then you'd have to get the underlying char array in the string in order to write that method outside of the String object. That would most definitely violate encapsulation.

And that's the thing about this that is tricky. If your requirements demand you have knowledge about character encodings of a String the best way to handle that is to delegate that conversion to the owner of that data to perform the operation for you. That's how OO and encapsulation helps you. By calling that getBytes method you are codifying that as a requirement in your program. OO and encapsulation doesn't let you transcend the requirements.

That's why OO focuses on methods as its preferred way of coupling. They offer a flexible place to insert logic to provide and integration point on which to base your dependencies.