Clean Code and SOLID Principles

This article is a glossary entry on Clean Code & SOLID – including exam questions, core elements, and tags.

In a Nutshell

Clean Code stands for readable, maintainable, error-free code. SOLID are five central guidelines for object-oriented design.

Compact Technical Description

Clean Code focuses on naming, structure, reusability, and small, understandable functions, among other things.

SOLID:

• S (SRP): A class has exactly one responsibility.
• O (OCP): Open for extension, closed for modification.
• L (LSP): Subtypes must cleanly replace base types.
• I (ISP): Many small interfaces instead of few large ones.
• D (DIP): Dependencies via abstractions, not concrete classes.

Exam-Relevant Key Points

• Clean Code = readable, maintainable
• SRP: one class = one task
• OCP: extensible without modification
• LSP: subclasses correctly substitutable (IHK-relevant)
• ISP: interfaces separated (practice)
• DIP: dependency via interfaces
• Cost-effectiveness: fewer bugs, easier onboarding
• Documentation: mention principles in architecture description

Core Components

1. Meaningful names
2. Encapsulation/SRP
3. Inheritance according to LSP
4. Avoiding God Objects
5. ISP interfaces
6. Abstraction/DIP
7. Unit tests
8. Refactoring
9. Diagrams for explanation
10. Code analysis tools (SonarQube)

Practical Example (SRP)

class ReportPrinter {
  public void print(PDFReport report) {
    // only printing, no report creation
  }
}

Advantages and Disadvantages

Advantages

• Understandable code
• Better testability
• Less coupling
• Structured architecture

Disadvantages

• Higher initial effort
• Excessive application can cause fragmentation

Typical Exam Questions (with Short Answer)

1. What does Clean Code mean? Readable, maintainable code.
2. What are the SOLID principles? SRP, OCP, LSP, ISP, DIP.
3. What is a God Object? A class with too many responsibilities.
4. Why is DIP important? Decouples high-level from low-level.

Free Answer

SOLID are guidelines, not rigid rules. In exams, it counts to be able to explain a principle and justify it with an example – without overengineering.

Learning Strategy

1. Read small Clean Code chapters.
2. Refactor your own code (SRP/LSP).
3. Formulate one example per principle.
4. Avoid overly large classes.

Topic Analysis

• Core: OOP, design principles
• Challenges: Overengineering
• Security: fewer hidden states
• Documentation: architecture decisions
• Cost-effectiveness: lower bug rate

Further Information

1. https://refactoring.guru/design-patterns/principles
2. https://www.sonarsource.com/products/sonarqube/