Software Design: Making Software Manageable

Flashcards based on lecture notes about software design principles, focusing on separation of concerns, encapsulation, modularity, coupling, cohesion, information hiding, and interfaces.

Separation of Concerns

A design principle that divides system into smaller units (with minimal overlap) to reduce complexity and improve independence

Encapsulation

Placing information (data and methods) into a unit and hiding it to prevent unwanted access, design units/modules with all relevant data and exposing it via an interface.

Modularity

Structuring software into independent modules or units.

Coupling

The degree of interaction between units (e.g., method calls between classes).

Cohesion

The degree to which a unit fulfills one purpose. Maximize choesion → purpose of each unit is more clear

Information Hiding

Revealing as little information to the outside as needed to prevent data manipulation and ensure integrity.

Interface

A contract that defines what a class must do, without specifying how. It only contains method signatures, and classes implement it to define behavior.

Abstraction

Hiding and generalizing details to reduce complexity; level of abstraction differs during the design..

DRY

Don't Repeat Yourself is a design principle to avoid code clones.

Why minimize coupling?

~Reveal as little information to the outside as needed
• Prevent data manipulation (i.e., check for modification in the capsule)
• Ensure integrity of the unit
• Allows access via a single, controlled interface

Why maximize cohesion?

Why are the sub-units in a unit not working together? Why are the sub-units working so much with those of other units? In essence: What is the purpose of each unit?

Advantages of separation of concerns

• Each unit is easier to understand and analyze

• Independent units are easier to maintain, change, and reuse (less impact on other units)

• Clearly defined sub-unit responsible for external exposure (avoids that something gets changed unexpectedly)

• Teams can work in parallel on individual units (also benefits planning and tracking)

• Easier to quality assure and test individual units (unit tests, reviews, …)

• Enables iterative development and integration

Disadvantages of separation of concerns

It can be challenging to define a good separation of concerns (a wrong design can have severe consequences due to redesign later)

Needs experience and typically some experimenting (concepts look different in different languages)

Separation of concerns often leads to overhead (restructuring, defining interfaces, additional code, …)

Functions cannot be defined in isolation

A good separation is defined by

A unit should solve one well-defined problem
Limit the sizes of interfaces/interactions between units
Each problem should be solved at one place only
A method should have a small/clear implementation

How to do coupling

Depends on the level of abstraction (and programming language)
• Methods (within a class) call each other
• Classes call the methods of other classes Information is hidden by visibility: private, public, protected, package The interface to a class are its public methods

Interfaces are useful for

“Making behavior accessible independently of concrete implementation”

Example of Low vs. High Coupling

• Low coupling: classes interact only through simple interfaces → easier to change and maintain

• High coupling: classes rely heavily on each other’s internal logic → fragile and hard to update

What’s an example of high vs. low cohesion?

• High cohesion: a class that only handles user login

• Low cohesion: a class that handles login, file saving, and sending emails

What are Java’s visibility levels and what do they mean?

• private: accessible only within the class

• public: accessible from anywhere

• protected: accessible within the same package or subclasses

• no keyword (package-private): accessible within the same package