TL;DR

API should be concerned with and hide details of the main function of a component. Getters may be useful, when state management is not the main function.

This has nothing to do with OOP

Component design goal is to split the problem into subproblems in a way that complexity of each component is manageable while complexity of their interactions is minimal. This has nothing to do with OOP.

Components hide their implementation details by definition. This has nothing to do with OOP.

Components are usually focused on exactly one complex subproblem. This has nothing to do with OOP.

State is a hard problem to manage. Usually state management is isolated to better manage its complexity. This has nothing to do with OOP.

OOP isolates state within components. FP isolates state outside of components (for example with IO monad).

OOP components hide state to avoid exposing its complexity. They expose the state if in doing so, the overall complexity decreases. This may happen when the subproblem complexity does not come from state management.

Getters are exposing state. Therefore their presence indicate that either Component design is not suitable for the problem at hand (leaks implementation detail) or design is focused on a problem that is harder to solve than state management.

In other words, question "are getters bad" is a special case of component design question - is state of this component the hardest problem it is trying to solve? If the component is not concerned with state management, it can expose whatever private fields it wants under the assumption that this would help other components to get the answer to the actual hard subproblem this one solves (obviously, details of the solution should never be exposed, just the result).

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP.

Examples

String.length is a leak of abstraction (for multiple reasons including multi byte encodings) because mutable strings should not expose their state allowing indexed access. For immutable strings with fixed-length encodings this is not a leak, because they can afford indexed access and expose it as API (like arrays).

Array.length is not a leak, because it is not changing and indexed access is main purpose of Arrays.

HashMap.size is not a leak because Collections are explicitly designed stateful and the main problem being solved is storage, state management is left to clients.

Account.balance is a leak in context of bank transaction and is not a leak in context of Internet Bank UI.

Dog.legCount is a leak in context of house pet management and is not a leak in context of pet clothing shop or veterinary clinic.

DTO.property is not a leak, because value delivery is the main purpose of DTO.

This has nothing to do with OOP

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP. Getters are just a minor part of API design. They are not special, apply other heuristics.

TL;DR

API should be concerned with and hide details of the main function of a component. Getters may be useful, when state management is not the main function.

This has nothing to do with OOP

Component design goal is to split the problem into subproblems in a way that complexity of each component is manageable while complexity of their interactions is minimal. This has nothing to do with OOP.

Components hide their implementation details by definition. This has nothing to do with OOP.

Components are usually focused on exactly one complex subproblem. This has nothing to do with OOP.

State is a hard problem to manage. Usually state management is isolated to better manage its complexity. This has nothing to do with OOP.

OOP isolates state within components. FP isolates state outside of components (for example with IO monad).

OOP components hide state to avoid exposing its complexity. They expose the state if in doing so, the overall complexity decreases. This may happen when the subproblem complexity does not come from state management.

Getters are exposing state. Therefore their presence indicate that either Component design is not suitable for the problem at hand (leaks implementation detail) or design is focused on a problem that is harder to solve than state management.

In other words, question "are getters bad" is a special case of component design question - is state of this component the hardest problem it is trying to solve? If the component is not concerned with state management, it can expose whatever private fields it wants under the assumption that this would help other components to get the answer to the actual hard subproblem this one solves (obviously, details of the solution should never be exposed, just the result).

The heuristic "getters are bad" comes up due to the hard problem of state management and an attempt to isolate state management by default. The heuristic is only apllicable for components managing state. Not every component has to manage state and some components manage one part of state but expose another.

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP.

Examples

String.length is a leak of abstraction (for multiple reasons including multi byte encodings) because mutable strings should not expose their state allowing indexed access. For immutable strings with fixed-length encodings this is not a leak, because they can afford indexed access and expose it as API (like arrays).

Array.length is not a leak, because it is not changing and indexed access is main purpose of Arrays.

HashMap.size is not a leak because Collections are explicitly designed stateful and the main problem being solved is storage, state management is left to clients.

Account.balance is a leak in context of bank transaction and is not a leak in context of Internet Bank UI.

Dog.legCount is a leak in context of house pet management and is not a leak in context of pet clothing shop or veterinary clinic.

DTO.property is not a leak, because value delivery is the main purpose of DTO.

This has nothing to do with OOP

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP. Getters are just a minor part of API design. They are not special, apply other heuristics.

TL;DR

API should be concerned with and hide details of main function of a component. Getters may be useful, when state management is not the main function.

This has nothing to do with OOP

Component design goal is to split the problem into subproblems in a way that complexity of each component is manageable while complexity of their interactions is minimal. This has nothing to do with OOP.

Components hide their implementation details by definition. This has nothing to do with OOP.

Components are usually focused on exactly one complex subproblem. This has nothing to do with OOP.

State is a hard problem to manage. Usually state management is isolated to better manage its complexity. This has nothing to do with OOP.

OOP isolates state within components. FP isolates state outside of components (for example with IO monad).

OOP components hide state to avoid exposing its complexity. They expose the state if in doing so, the overall complexity decreases. This may happen when the subproblem complexity does not come from state management.

Getters are exposing state. Therefore their presence indicate that either Component design is not suitable for the problem at hand (leaks implementation detail) or design is focused on a problem that is harder to solve than state management.

In other words, question "are getters bad" is a special case of component design question - is state of this component the hardest problem it is trying to solve? If the component is not concerned with state management, it can expose whatever private fields it wants under assumption that this would simplify intercomponent interaction for other components to get the answer to the actual hard subproblem this one solves (obviously, details of the solution should never be exposed, just the result).

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP.

Examples

String.length is a leak of abstraction (for multiple reasons including multi byte encodings) because mutable strings should not expose their state allowing indexed access. For immutable strings with fixed-length encodings this is not a leak.

Array.length is not a leak, because it is not changing and indexed access is main purpose of Arrays.

HashMap.size is not a leak because Collections are explicitly designed stateful and the main problem being solved is storage, state management is left to clients.

Account.balance is a leak in context of bank transaction and is not a leak in context of Internet Bank UI.

Dog.legCount is a leak in context of house pet management and is not a leak in context of pet clothing shop or veterinary clinic.

This has nothing to do with OOP

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP. Getters are just a minor part of API design. They are not special, apply other heuristics.

TL;DR

API should be concerned with and hide details of the main function of a component. Getters may be useful, when state management is not the main function.

This has nothing to do with OOP

Component design goal is to split the problem into subproblems in a way that complexity of each component is manageable while complexity of their interactions is minimal. This has nothing to do with OOP.

Components hide their implementation details by definition. This has nothing to do with OOP.

Components are usually focused on exactly one complex subproblem. This has nothing to do with OOP.

State is a hard problem to manage. Usually state management is isolated to better manage its complexity. This has nothing to do with OOP.

OOP isolates state within components. FP isolates state outside of components (for example with IO monad).

OOP components hide state to avoid exposing its complexity. They expose the state if in doing so, the overall complexity decreases. This may happen when the subproblem complexity does not come from state management.

Getters are exposing state. Therefore their presence indicate that either Component design is not suitable for the problem at hand (leaks implementation detail) or design is focused on a problem that is harder to solve than state management.

In other words, question "are getters bad" is a special case of component design question - is state of this component the hardest problem it is trying to solve? If the component is not concerned with state management, it can expose whatever private fields it wants under the assumption that this would help other components to get the answer to the actual hard subproblem this one solves (obviously, details of the solution should never be exposed, just the result).

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP.

Examples

String.length is a leak of abstraction (for multiple reasons including multi byte encodings) because mutable strings should not expose their state allowing indexed access. For immutable strings with fixed-length encodings this is not a leak, because they can afford indexed access and expose it as API (like arrays).

Array.length is not a leak, because it is not changing and indexed access is main purpose of Arrays.

HashMap.size is not a leak because Collections are explicitly designed stateful and the main problem being solved is storage, state management is left to clients.

Account.balance is a leak in context of bank transaction and is not a leak in context of Internet Bank UI.

Dog.legCount is a leak in context of house pet management and is not a leak in context of pet clothing shop or veterinary clinic.

DTO.property is not a leak, because value delivery is the main purpose of DTO.

This has nothing to do with OOP

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP. Getters are just a minor part of API design. They are not special, apply other heuristics.

TL;DR

API should expose details that help with main function of a component. Getters may be useful, when state management is not the main function.

This has nothing to do with OOP

Component design goal is to split the problem into subproblems in a way that complexity of each component is manageable while complexity of their interactions is minimal. This has nothing to do with OOP.

Components hide their implementation details by definition. This has nothing to do with OOP.

Components are usually focused on exactly one complex subproblem. This has nothing to do with OOP.

State is a hard problem to manage. Usually state management is isolated to better manage its complexity. This has nothing to do with OOP.

OOP isolates state within components. FP isolates state outside of components (for example with IO monad).

OOP components hide state to avoid exposing its complexity. They expose the state if in doing so, the overall complexity decreases. This may happen when the subproblem complexity does not come from state management.

Getters are exposing state. Therefore their presence indicate that either Component design is not suitable for the problem at hand (leaks implementation detail) or design is focused on a problem that is harder to solve than state management.

In other words, question "are getters bad" is a special case of component design question - is state of this component the hardest problem it is trying to solve? If the component is not concerned with state management, it can expose whatever private fields it wants under assumption that this would simplify intercomponent interaction for other components to get the answer to the actual hard subproblem this one solves (obviously, details of the solution should never be exposed, just the result).

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP.

Examples

String.length is a leak of abstraction (for multiple reasons including multi byte encodings) because mutable strings should not expose their state allowing indexed access. For immutable strings with fixed-length encodings this is not a leak.

Array.length is not a leak, because it is not changing and indexed access is main purpose of Arrays.

HashMap.size is not a leak because Collections are explicitly designed stateful and the main problem being solved is storage, state management is left to clients.

Account.balance is a leak in context of bank transaction and is not a leak in context of Internet Bank UI.

Dog.legCount is a leak in context of house pet management and is not a leak in context of pet clothing shop or veterinary clinic.

This has nothing to do with OOP

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP. Getters are just a minor part of API design.

TL;DR

API should be concerned with and hide details of main function of a component. Getters may be useful, when state management is not the main function.

This has nothing to do with OOP

Component design goal is to split the problem into subproblems in a way that complexity of each component is manageable while complexity of their interactions is minimal. This has nothing to do with OOP.

Components hide their implementation details by definition. This has nothing to do with OOP.

Components are usually focused on exactly one complex subproblem. This has nothing to do with OOP.

State is a hard problem to manage. Usually state management is isolated to better manage its complexity. This has nothing to do with OOP.

OOP isolates state within components. FP isolates state outside of components (for example with IO monad).

OOP components hide state to avoid exposing its complexity. They expose the state if in doing so, the overall complexity decreases. This may happen when the subproblem complexity does not come from state management.

Getters are exposing state. Therefore their presence indicate that either Component design is not suitable for the problem at hand (leaks implementation detail) or design is focused on a problem that is harder to solve than state management.

In other words, question "are getters bad" is a special case of component design question - is state of this component the hardest problem it is trying to solve? If the component is not concerned with state management, it can expose whatever private fields it wants under assumption that this would simplify intercomponent interaction for other components to get the answer to the actual hard subproblem this one solves (obviously, details of the solution should never be exposed, just the result).

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP.

Examples

String.length is a leak of abstraction (for multiple reasons including multi byte encodings) because mutable strings should not expose their state allowing indexed access. For immutable strings with fixed-length encodings this is not a leak.

Array.length is not a leak, because it is not changing and indexed access is main purpose of Arrays.

HashMap.size is not a leak because Collections are explicitly designed stateful and the main problem being solved is storage, state management is left to clients.

Account.balance is a leak in context of bank transaction and is not a leak in context of Internet Bank UI.

Dog.legCount is a leak in context of house pet management and is not a leak in context of pet clothing shop or veterinary clinic.

This has nothing to do with OOP

Split your components to minimize API surface, isolate current, actual hardest problems as implementation detail. This has nothing to do with OOP. Getters are just a minor part of API design. They are not special, apply other heuristics.