It violates responsibility principles. If ImportantClass needs the other two instances in order to work properly, then it is ImportantClass's responsibility to make sure that they are in a known good state before anything else should happen.
That code violates several principles described in the excellent book Effective Java by Joshua Bloch, which I highly recommend. For example, on public instance fields:
If an instance field is non-final, or is a final reference to a mutable object, then by making the field public, you give up the ability to limit the values that can be stored in the field. This means you also give up the ability to enforce invariants involving the field. Also, you give up the ability to take any action when the field is modified, so classes with public mutable fields are not thread-safe. Even if a field is final and refers to an immutable object, by making the field public you give up the flexibility to switch to a new internal data representation in which the field does not exist.
Furthermore, you are not achieving encapsulation with these fields public.
The book has a lot to say about how to do object initialization safely and correctly, as well. Suffice it to say, the code you posted is highly problematic.
You can mention to him that this coding approach violates one of the three fundamental concepts of object oriented development which of course is encapsulation.
The fact that the state of his object can be modified directly by its users which makes debugging really hard as opposed to a private method that will be the single way to access internal data...
More than this, his clients are tightly coupled with his class so in the case that he wants to make some internal changes his clients need to be recompiled despite that fact that the changed occurred do not affect their use....
The truth though, is that during the latest years the application of data encapsulation in OO systems has been relaxed in comparison with the past.
Technologies like SPRING or LINQ for example, directly violate the privacy of implementation details trying to archive IOC or 'functional like' behavior.
A direct result of this tendency is the recent adoption from C# of automatic properties that are used to simplify direct exposure of private data as set/get properties...
API 应该易于使用且不易误用。简单的事情应该很容易做；可以做复杂的事情；并且不可能或至少很难做错事。
不要让 API 包含实现细节。它们使用户感到困惑并抑制了发展的灵活性。实现细节并不总是很明显：要警惕过度规范。
It violates the Principle of Least Astonishment because as a consumer of the class I would require working knowledge of the class to make it work without exceptions (or run it until I get no exceptions which would be a huge pain in the a$$).
APIs should be easy to use and hard to misuse. It should be easy to do simple things; possible to do complex things; and impossible, or at least difficult, to do wrong things.
Keep APIs free of implementations details. They confuse users and inhibit the flexibility to evolve. It isn't always obvious what's an implementation detail: Be wary of overspecification.
发布评论
评论（5）
它违反了责任原则。如果
ImportantClass需要其他两个实例才能正常工作，那么ImportantClass有责任在发生其他情况之前确保它们处于已知的良好状态。It violates responsibility principles. If
ImportantClassneeds the other two instances in order to work properly, then it isImportantClass's responsibility to make sure that they are in a known good state before anything else should happen.该代码违反了 Joshua Bloch 所著的《Effective Java》优秀著作中描述的几条原则，我强烈推荐这本书。例如，在公共实例字段上：
此外，您没有实现对这些公共字段的封装。
这本书也有很多关于如何安全、正确地进行对象初始化的内容。可以说，您发布的代码存在很大问题。
That code violates several principles described in the excellent book Effective Java by Joshua Bloch, which I highly recommend. For example, on public instance fields:
Furthermore, you are not achieving encapsulation with these fields public.
The book has a lot to say about how to do object initialization safely and correctly, as well. Suffice it to say, the code you posted is highly problematic.
我会向您的同事推荐一篇有关SOLID 原则的文章。
I would point your coworker to an article regarding SOLID principles.
你可以向他提到，这种编码方法违反了面向对象开发的三个基本概念之一，当然就是封装。
事实上，他的对象的状态可以由用户直接修改，这使得调试非常困难，而不是私有方法，私有方法将是访问内部数据的唯一方法......
更重要的是，他的客户与他的客户紧密耦合因此，如果他想要进行一些内部更改，则需要重新编译他的客户端，尽管发生的更改不会影响它们的使用......
但事实是，在最近几年中数据封装的应用与过去相比，OO系统中的内容已经宽松了。
例如，SPRING 或 LINQ 等技术直接侵犯了试图存档 IOC 或“类似功能”行为的实现细节的隐私。
这种趋势的直接结果是 C# 最近采用了自动属性，这些属性用于简化私有数据作为设置/获取属性的直接公开...
You can mention to him that this coding approach violates one of the three fundamental concepts of object oriented development which of course is encapsulation.
The fact that the state of his object can be modified directly by its users which makes debugging really hard as opposed to a private method that will be the single way to access internal data...
More than this, his clients are tightly coupled with his class so in the case that he wants to make some internal changes his clients need to be recompiled despite that fact that the changed occurred do not affect their use....
The truth though, is that during the latest years the application of data encapsulation in OO systems has been relaxed in comparison with the past.
Technologies like SPRING or LINQ for example, directly violate the privacy of implementation details trying to archive IOC or 'functional like' behavior.
A direct result of this tendency is the recent adoption from C# of automatic properties that are used to simplify direct exposure of private data as set/get properties...
它违反了最小惊讶原则，因为作为该课程的消费者，我需要以下方面的工作知识类以使其无异常地工作（或者运行它直到我没有异常，这将是 a$$ 的巨大痛苦）。
一些引述自 http://portal.acm.org/itation.cfm?id=1176622 ：
It violates the Principle of Least Astonishment because as a consumer of the class I would require working knowledge of the class to make it work without exceptions (or run it until I get no exceptions which would be a huge pain in the a$$).
Some quotes from http://portal.acm.org/citation.cfm?id=1176622: