A team of programmers is reviewing a proposed API for a new utility class. After some discussion, they realize that they can reduce the number of methods in the API without losing any functionality. If they implement the new design, which two OO principles will they be promoting?
1. Looser Coupling
2. Higher Cohesion
3. Stronger Encapsulation
这肯定是在描述一件好事，所以把坏的选项都去掉了，这3个好的选项中，应该不是encapsulation。请问1和2应该是哪个呢?为什么？答案是1.
谢谢。
1. Looser Coupling
2. Higher Cohesion
3. Stronger Encapsulation
这肯定是在描述一件好事，所以把坏的选项都去掉了，这3个好的选项中，应该不是encapsulation。请问1和2应该是哪个呢?为什么？答案是1.
谢谢。
答案是1和2，这是设计的目标。
which two OO principles will they be promoting?
支持2L的回答
这个问题如果没有一定的设计经验（不管是正式的还是非正式的）是不那么容易理解的，因为只有经历过这些才会遇到这个领域特有的问题。如果追溯这些问题的根源，最终会找到两个：Coupling(耦合)和Cohesion(内聚)。
首先应该明白什么是耦合和内聚:
1. 耦合通常是指对象之间联系的紧密程度。比如一个view对象引用一个graphics对象，那么view和graphics之间就会产生耦合，如果view知道graphics内部的细节越多，那么耦合就越强。这只是耦合的一种，称为内容耦合。另外，时间耦合也比较重要，例如：只有对象a的foo个方法调用过后，b的bar方法才能调用，这就是时间耦合，应该尽量避免。
2. 内聚是对对象(或方法)的职责(功能)数量的度量，对象(或方法)的职责越少，内聚就越高，对象(或方法)的职责越多，内聚就越低。例如一个view对象却有着大量与视图不相关的代码，那么这个view对象就不是高内聚的，如果要使它高内聚的，那么就将写视图操作不相关的代码从中剥离出来，让它只专注于一件事情--处理视图操作。再则应该清楚它们对系统有什么样的影响：
1. 如果耦合过高会直接导致代码难以修改和重用。过高的耦合就意味着系统中对象之间的依赖非常紧密，可能任何一个小的改动都会导致整个系统重新编译，这在大型项目上是非常可怕的。过高的耦合通常还意味着对象之间复杂的依赖关系(有时间上的，也有内容上的)，系统规模越大，关系就越复杂，这会导致系统难以理解和修改，任何一个看起来很简单(正常的逻辑本来就很简单)的修补，却会导致系统其它多个地方失效。
2. 如果内聚过低会增加系统中不必要的耦合，而且会导致大量的重复。例如：一个类A做了两件事情a和b，另一个类B要求类A为其做a事情，却从不要求A为其做b事情，那么对b做出的任何改动都会影响B，B在为它不需要的服务b买单。