{
    "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."
        }
    ]
}