Each software module should have one reason to change.

Robert C Martin

In other words...

The thing should do what it says on the tin.

Where
module = A class, function or method

Make your modules single purpose or responsibility.

Examples of Responsibility

• Persistence
• Logging
• Validation
• Business Logic

Responsibilites change at different times for different reasons.

Tight Coupling

This is when two or more modules are bound together in a way that makes modification difficult.

Loose Coupling

Offers a way to choose which modules are used in a particular operation.

Separation of Concerns

Programs should be separated into distinct sections, each addressing a separate concern or information that affects the program.

Cohesion

Group modules that belong together.

For example CRUD modules.

Key Takeaways

• Modules should have a single responsibility.
• Strive for high cohesion.
• Strive for loose coupling.
• Keep modules small, focused and testable.

Other Links

stackify.com/solid-design-principles