api: YAML JSON TOON Database
version: 1.0.0
format: json
dataset:
  slug: solid-principles
  title: SOLID Principles
  description: Five design principles for writing maintainable object-oriented code.
  summary: "The five SOLID principles of object-oriented design with a description and an example each, followed by related design principles: DRY, KISS, YAGNI, the Law of Demeter, composition over inheritance, separation of concerns and Tell, Don't Ask."
  use_when:
    - You need the principle behind a design decision or a code-review comment.
    - You are teaching object-oriented design.
  caveats:
    - Principles are guidelines that conflict at times; DRY can push toward abstractions that YAGNI warns against.
    - Taken to extremes, they produce over-engineered code.
  related:
    - creational-patterns
    - structural-patterns
    - behavioral-design-patterns
    - design-pattern-anti-patterns
  category: Design Patterns
  category_slug: design-patterns
  tags: design-patterns,solid,oop,software-engineering
  view_count: 0
  entry_count: 12
  fields:
    - section: data
      field: principle
      type: string
      example: S - Single Responsibility
    - section: data
      field: description
      type: string
      example: A class should have only one reason to change.
    - section: data
      field: example
      type: string
      example: Separate UserAuth from UserProfile.
data:
  - principle: S - Single Responsibility
    description: A class should have only one reason to change.
    example: Separate UserAuth from UserProfile.
  - principle: O - Open/Closed
    description: Open for extension, closed for modification.
    example: Add new payment types without changing existing processor.
  - principle: L - Liskov Substitution
    description: Subtypes must be substitutable for their base types.
    example: A Square should not extend Rectangle if width=height invariant breaks.
  - principle: I - Interface Segregation
    description: Prefer many small client-specific interfaces over one large interface.
    example: Separate Printer and Scanner interfaces.
  - principle: D - Dependency Inversion
    description: Depend on abstractions, not concrete implementations.
    example: Controller depends on ILogger interface, not FileLogger.
  - principle: DRY - Don't Repeat Yourself
    description: Every piece of knowledge should have a single, authoritative representation.
    example: Define a validation rule once and reuse it instead of copying it into several handlers.
  - principle: KISS - Keep It Simple
    description: Prefer the simplest design that solves the problem.
    example: Use a plain function before introducing a class hierarchy.
  - principle: YAGNI - You Aren't Gonna Need It
    description: Do not add functionality until it is actually needed.
    example: Skip a plugin system until a second implementation exists.
  - principle: Law of Demeter
    description: A unit should talk only to its immediate collaborators, not reach through them.
    example: Call order.total() instead of order.getCustomer().getAccount().getBalance().
  - principle: Composition over Inheritance
    description: Combine small objects to get behavior instead of extending class hierarchies.
    example: Give a Car an Engine object rather than making Car a subclass of Engine.
  - principle: Separation of Concerns
    description: Divide a program into parts that each address a distinct concern.
    example: Keep data access, business rules and presentation in separate layers.
  - principle: Tell, Don't Ask
    description: Tell objects what to do instead of asking for their state and acting on it.
    example: Call account.withdraw(amount) rather than reading the balance and deciding outside.