问物体健美操的规则9在现实生活中真的可行吗？

EN

我最近读到了关于对象健美操的文章，我被规则9困住了。

我对代码的典型方法(我是C# .NET开发人员)是将数据建模为仅用于表示数据模式的波科类。这不可避免地意味着一组使用getter和setter公开的属性。这些类实现的方法很少，或者更多的是否定的。它们是哑对象，通常存在于我的解决方案体系结构中的一个较低的级别。它们有一个独特的责任:对结构化数据(例如数据库表行)建模。

在需要逻辑功能的地方，我将在业务(或服务)层中引入这些专用服务类。这些类还通过处理特定的业务需求来遵守单一责任原则。例如，我可能有一个Customer类，以及一个负责读取和写入持久数据存储的CustomerRepository类。这个CustomerRepository将实现一个IRepository契约，以确保我可以将它作为一个依赖项注入，并在测试中模拟它。

使用此模式，不可避免地，我的Customer必须通过getter和setter公开其属性("直接朝你的脸上吐出自己的内脏"!)以便存储库可以将其映射到数据库表或其他任何地方。

所以我的问题是，为什么一个对象健美操爱好者会认为这是如此错误？在我所看到的所有示例中，作者将属性保持为私有，并将逻辑函数直接引入到类中，在我看来，这些函数打破了单个责任，并可能导致大量的、笨重的、不可测试的类。

那么，规则9在现实生活中真的可行吗？在我发现的为数不多的详细解释之一中，作者似乎反对自己，定义了一个Account类，将Balance设置为私有，然后引入了像Withdraw这样的方法，不仅封装了属性，还封装了与该属性一起工作的任何逻辑。好吧，但是如果业务需求需要程序员将帐户余额写到UI中呢？在这种情况下，如何遵守规则第9条？