Cohesion and Coupling Interview Questions

Cohesion is how focused a module is. High cohesion is good — a class does one job. Coupling is how much one module knows about another. Low coupling is good. A God class that talks to the database, sends email, and renders HTML is low cohesion and high coupling. Tests become painful because I cannot fake one piece. I raise cohesion and cut coupling with smaller services, interfaces, and dependency injection. If they ask how I would split a 2,000-line class, that is the language I use.

High: TaxCalculator that only computes tax. Low: UserManager that sends email, writes SQL, and renders HTML. Coupling: new PostgresRepository() inside a domain service is tight. Injecting IOrderRepo is looser.

No. Useful programs couple to some interfaces. I want coupling to abstractions I control, not a vendor SDK in every class. I also do not add an interface for a class that will never have a second implementation.

Too many fields, unrelated imports, methods that do HTTP and SQL and Excel, name ends in Manager, two thousand lines. I would split along SRP and ask which tests they would write.

A service that needs five other databases for one request is high coupling. A service that owns one bounded context is higher cohesion. I would not split a microservice per table. Same OOP ideas, larger boxes.