Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Software Engineering · Question Set
Design Principles: Coupling & Cohesion interview questions for placements and exams.
Questions
11
Included in this set
Subject
Software Engineering
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for Software Engineering.
Modules with low cohesion (doing many unrelated things) and high coupling (many dependencies) are hard to maintain, understand and reuse. Good design tends toward high cohesion and low coupling.
For complete preparation, combine this set with full subject-wise practice for Software Engineering. You can also explore other subjects and sets from the links below.
When designing a software system you first identify logical modules based on functional grouping so that each module is cohesive: it has one clear responsibility and its internal elements work together. Then you design module interfaces so that dependencies between modules are minimal, achieving low coupling. /n/n This matters for long-term maintenance because changes, bug-fixes and extensions are easier to apply when modules are well defined: a change in one module rarely forces changes in many others. It also improves reusability, testability and team coordination. Applying these principles shows you understand maintainable software architecture.
In such a scenario you might find a module that handles UI tasks, database access and business logic all in one (low cohesion) and depends on many other modules (high coupling). /n/n To refactor you would: 1) extract the business logic into a separate service or module; 2) move database access into a repository class/module; 3) isolate UI code into its own module; 4) introduce interfaces or abstractions to reduce direct dependency between modules; 5) ensure each new module has a single clear responsibility and minimal dependencies. /n/n As a result you achieve higher cohesion in each module and lower coupling between modules. This reduces complexity, improves testability, and makes future enhancements safer. Demonstrating such experience or reasoning in an interview shows you grasp practical design quality.
Cohesion refers to how well the responsibilities inside a module belong together. High-cohesion modules perform a single, well-defined task and are easier to understand, maintain and reuse.
Coupling describes how tightly connected modules are: high coupling means changes in one module force changes in others, which hurts maintainability.
High cohesion means a module has narrow, well-focused responsibilities. This results in simpler, more maintainable code and easier unit testing.
Low coupling implies modules depend little on others, so you can modify one without triggering cascade changes. This supports maintainability and agility.
Functional cohesion means all elements in a module contribute to a single well-defined task. It is the strongest and most desirable form of cohesion.
Content coupling occurs when one module uses the internal details of another module (for example accessing its internal data). This is highly undesirable because it creates very strong dependencies.
Good modularisation means each module has a clear purpose (high cohesion) and interacts minimally with others (low coupling). This improves maintainability, testability and scalability.
To measure coupling and cohesion you might use metrics such as number of module dependencies, fan-in/fan-out values (how many modules call this module and how many this module calls), coupling-between-objects (CBO), Lack of Cohesion in Methods (LCOM) for classes, and others. /n/n For example if a class has many unrelated methods and fields, a high LCOM value signals low cohesion. If a module has many outward calls and high fan-out, it signals high coupling. /n/n These metrics inform refactoring: modules with poor design metrics are candidates for decomposition, abstraction, interface introduction or removal of unnecessary dependencies. Discussing metrics in an interview shows you understand both theory and practice of design quality.