内聚和耦合之间的区别是什么?

耦合和内聚如何导致软件设计的好坏?

举些什么例子来概括这两者之间的区别,以及它们对整体代码质量的影响?


当前回答

提高内聚性和降低耦合确实会带来好的软件设计。

内聚对功能进行了划分,使其简洁并与相关数据最接近,而解耦则确保功能实现与系统的其余部分隔离。

解耦允许您在不影响软件其他部分的情况下更改实现。

内聚性确保实现更特定于功能,同时更容易维护。

减小耦合、提高内聚的最有效方法是采用界面设计。

也就是说,主要的功能对象只能通过它们实现的接口相互“认识”。接口的实现自然会引入内聚性。

虽然在某些场景中不太现实,但这应该是一个设计目标。

例子(非常粗略):

public interface IStackoverFlowQuestion
      void SetAnswered(IUserProfile user);
      void VoteUp(IUserProfile user);
      void VoteDown(IUserProfile user);
}

public class NormalQuestion implements IStackoverflowQuestion {
      protected Integer vote_ = new Integer(0);
      protected IUserProfile user_ = null;
      protected IUserProfile answered_ = null;

      public void VoteUp(IUserProfile user) {
           vote_++;
           // code to ... add to user profile
      }

      public void VoteDown(IUserProfile user) {
          decrement and update profile
      }

      public SetAnswered(IUserProfile answer) {
           answered_ = answer
           // update u
      }
}

public class CommunityWikiQuestion implements IStackoverflowQuestion {
     public void VoteUp(IUserProfile user) { // do not update profile }
     public void VoteDown(IUserProfile user) { // do not update profile }
     public void SetAnswered(IUserProfile user) { // do not update profile }
}

在你的代码库的其他地方,你可以有一个模块来处理问题,不管它们是什么:

public class OtherModuleProcessor {
    public void Process(List<IStackoverflowQuestion> questions) {
       ... process each question.
    }
}

其他回答

简单地说,内聚意味着一个类应该代表一个单一的概念。

如果类的所有特性都与类所代表的概念相关,那么类的公共接口就是内聚的。 例如,与其拥有CashRegister类,不如拥有CashRegister和Coin功能,将其整合为2个类- CashRegister和Coin类。

在耦合中,一个类依赖于另一个类,因为它使用类的对象。

高耦合的问题在于它会产生副作用。一个类中的一个更改可能导致另一个类中出现意外错误,并可能破坏整个代码。

通常,高内聚和低耦合被认为是高质量的OOP。

cohesion refers all about how a single class is designed. Cohesion is the Object Oriented principle most closely associated with making sure that a class is designed with a single, well-focused purpose. The more focused a class is, the cohesiveness of that class is more. The advantages of high cohesion is that such classes are much easier to maintain (and less frequently changed) than classes with low cohesion. Another benefit of high cohesion is that classes with a well-focused purpose tend to be more reusable than other classes.

在上图中,我们可以看到,在低内聚情况下,只有一个类负责执行大量不相同的作业,这降低了可重用性和维护的机会。但是在高内聚的情况下,所有的作业都有一个单独的类来执行特定的作业,这样可以获得更好的可用性和可维护性。

凝聚力:Co的意思是在一起,hesion的意思是粘在一起。粘结:不同物质的微粒粘在一起的系统

举个现实的例子: img礼貌

整体大于部分之和-亚里士多德。

Cohesion is an ordinal type of measurement and is usually described as “high cohesion” or “low cohesion”. Modules with high cohesion tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand. wiki Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability. wiki

内聚性表明了软件元素的职责是如何相互关联和集中的。

耦合指的是软件元素与其他元素的连接强度。

软件元素可以是类、包、组件、子系统或系统。在设计系统时,建议使用具有高内聚性和支持低耦合的软件元素。

低内聚导致整体类难以维护、理解,降低了可重用性。类似地,高耦合导致类紧密耦合,更改往往不是非局部的,难以更改并减少重用。

我们可以假设一个场景,在这个场景中,我们正在设计一个典型的可监视ConnectionPool,并满足以下需求。注意,对于像ConnectionPool这样的简单类来说,它可能看起来太过了,但基本目的只是用一些简单的示例演示低耦合和高内聚,我认为应该会有所帮助。

支持连接 释放连接 获取有关连接与使用计数的统计数据 获取有关连接和时间的统计数据 将连接检索和发布信息存储到数据库中,以便以后报告。

对于低内聚,我们可以通过将所有功能/职责强制填充到单个类中来设计ConnectionPool类,如下所示。我们可以看到,这个类负责连接管理、与数据库交互以及维护连接统计信息。

有了高内聚性,我们可以在类之间分配这些职责,并使其更可维护和可重用。

To demonstrate Low coupling we will continue with the high cohesion ConnectionPool diagram above. If we look at the above diagram although it supports high cohesion, the ConnectionPool is tightly coupled with ConnectionStatistics class and PersistentStore it interacts with them directly. Instead to reduce the coupling we could introduce a ConnectionListener interface and let these two classes implement the interface and let them register with ConnectionPool class. And the ConnectionPool will iterate through these listeners and notify them of connection get and release events and allows less coupling.

Note/Word or Caution: For this simple scenario it may look like an overkill but if we imagine a real-time scenario where our application needs to interact with multiple third party services to complete a transaction: Directly coupling our code with the third party services would mean that any changes in the third party service could result in changes to our code at multiple places, instead we could have Facade that interacts with these multiple services internally and any changes to the services become local to the Facade and enforce low coupling with the third party services.

理论的区别

凝聚力

内聚性是模块相对功能强度的表征。 内聚模块执行单一任务,几乎不需要与其他模块交互 程序其他部分的组件。 具有高内聚和低耦合的模块称为功能独立模块 其他模块。

衔接的分类

1.巧合2。逻辑3。时间4。程序5。沟通6。连续7。功能

耦合

耦合表示模块之间的相对依赖关系。 两个模块之间的耦合程度取决于它们的接口复杂性。