setter和getter方法是否打破了封装？
有人告诉我们应该避免使用限制器和吸气剂。 关于它有各种各样的想法，但根据我使用这些突破封装。 为什么？ 因为它告诉世界一个物体的内部。 例如：
class Point { private int x; private int y; void setx(int x) {...} int getx() {...} ... } 该对象应该只暴露为客户端提供清晰抽象的行为。
class Point { private int x; private int y; int coordinate(int x) {...} // 0, 1, 2, 3 ... }
那么，这些存取器和setter方法是否打破了封装？
从这里 ：
拥有getter和setter本身并不打破封装。 破解封装是为每个数据成员（每个字段，在java术语中）设置一个getter和setter。 这是让所有数据成员公开的一步之遥。
封装的重点不在于您不应该知道或者从对象外部更改对象的状态，而是您应该有一个合理的策略来执行它。
考虑一个Person类的例子。 假设一个人有姓名，社会安全号码和年龄。 假设我们不允许人们更改姓名或社会安全号码。 但是，该人的年龄应每年增加1。 在这种情况下，您将提供一个构造函数，将名称和SSN初始化为给定值，并将年龄初始化为0.您还将提供方法incrementAge（），这将使年龄增加1。也会为这三个人提供吸气剂。 在这种情况下不需要制定者。
在此设计中，您允许从类外部检查对象的状态，并允许从类外部更改对象的状态。 但是，您不允许任意更改状态。 有一个策略，它有效地说明名称和SSN根本不能改变，并且年龄可以一次增加1年。
现在让我们说一个人也有薪水。 人们可以随意改变工作，这意味着他们的薪水也会发生变化。 为了模拟这种情况，除了提供setSalary（）方法之外别无他法！ 在这种情况下，允许随意改变工资是一个完全合理的政策。
顺便说一句，在你的例子中，我会给类冰箱putCheese（）和takeCheese（）方法，而不是get_cheese（）和set_cheese（）。 然后你仍然会有封装。
你也可以参考： 为什么getter和setter方法是邪恶的
虽然getter和setter实际上是为了实现Encapsulation本身，但它在很大程度上取决于情况本身。
- 糟糕的OO设计：公共领域。
- 糟糕的OO设计：当使用getter和setter时，即使是
不需要 - 伟大的OO设计：仅在他们真正需要的地方使用 – 并且用于暴露类的行为而不是用于操纵数据的工具。