Cohesion and Coupling Essentials Quiz Quiz

Explore key principles of cohesion and coupling with scenario-based questions designed to reinforce essential software engineering concepts. Enhance your understanding of how module design decisions impact maintainability, flexibility, and reliability.

1. Understanding Cohesion Types

   In the context of software design, which type of cohesion is considered the most desirable when designing a module that processes a single well-defined task?

   1. Functional cohesion
   2. Procedural cohesion
   3. Coincidental cohesion
   4. Temporal cohesion

   Explanation: Functional cohesion is the most desirable because it means all parts of the module work together to perform a single, specific function, which maximizes clarity and maintainability. Procedural cohesion is less preferable since it only groups functions by the order of execution, not by shared purpose. Coincidental cohesion, where unrelated operations coexist, is unfavorable and can confuse maintenance. Temporal cohesion groups elements by timing only, which does not ensure logical relatedness.

2. Identifying Tight Coupling

   Which scenario best illustrates tight coupling between two components in software architecture?

   1. Component A and Component B each follow the same naming convention
   2. Component A sends data to Component B via a message queue
   3. Component A calls a public method from Component B's interface
   4. Component A directly modifies the internal variables of Component B

   Explanation: Tight coupling occurs when one component relies on the internal details of another, such as directly accessing and changing its variables, making maintenance and testing harder. Merely calling public methods through an interface allows for better abstraction and looser coupling. Sharing naming conventions does not establish operational dependency. Using a message queue facilitates loose coupling by separating components through asynchronous communication.

3. Effects of Low Cohesion

   What is a likely consequence when a module in a program exhibits low cohesion, such as handling database access, UI display, and logging in one place?

   1. The module becomes harder to maintain and test
   2. The module automatically reduces dependencies
   3. The module always follows the single responsibility principle
   4. The module will execute faster due to combined logic

   Explanation: Low cohesion results in modules combining unrelated functionality, which complicates understanding, maintenance, and testing efforts. Combining logic rarely improves performance and is likely to introduce inefficiencies instead. Such a module violates the single responsibility principle. Additionally, grouping unrelated tasks does not reduce dependencies but may inadvertently increase them.

4. Evaluating Coupling Types

   Which type of coupling is considered the weakest and thus most desirable when designing modules that exchange data?

   1. Control coupling
   2. Common coupling
   3. Data coupling
   4. Content coupling

   Explanation: Data coupling is the weakest form, involving only the exchange of simple data through parameters, promoting modular and maintainable design. Content coupling is the strongest and least desirable, as it exposes module internals. Control coupling occurs when one module controls another’s logic, which should be avoided for flexibility. Common coupling, using shared global data, increases inter-module dependencies and risks side effects.

5. Improving Cohesion in Refactoring

   During a code review, you notice a class that validates user input, handles network requests, and writes to a log file. What should you do to improve its cohesion?

   1. Add more comments to clarify the logic
   2. Combine even more related tasks into the class
   3. Separate each responsibility into distinct classes
   4. Rename the class to better reflect all its tasks

   Explanation: Separating each responsibility into its own class increases functional cohesion, making code more modular and easier to maintain. Renaming the class only improves clarity but does not address the core problem. Adding comments may help understanding, but does not solve the issue of multiple responsibilities. Combining more tasks further reduces cohesion and makes the codebase more complex and fragile.