--- title: "Design Principle vs Design Pattern" description: "Design principles and design patterns are two essential concepts in software engineering." author: "Ravi Vishwakarma" published: 2024-06-10 updated: 2024-06-10 canonical: https://www.mindstick.com/blog/304335/design-principle-vs-design-pattern category: "c#" tags: ["c#", ".net", "javascript", "java"] reading_time: 4 minutes --- # Design Principle vs Design Pattern Design principles and design patterns are two essential concepts in [software engineering](https://www.mindstick.com/blog/11283/sei-cmm-model-software-engineering-institute-capability-maturity-model), but they serve different purposes. #### Design Principles: [Design principles](https://www.mindstick.com/interview/33805/what-are-the-crucial-core-graphic-design-principles) are general guidelines or rules that developers should follow to create well-structured, maintainable, and scalable [software systems](https://www.mindstick.com/blog/11192/facts-about-eastern-software-systems). These principles are more abstract and provide high-level guidance on how to design software. They are often derived from best practices and lessons learned from experience. \ **Here's a list of some key design principles commonly used in software engineering:** 1. [**SOLID Principles**](https://www.mindstick.com/articles/33658/solid-principles-in-software-development-area): 1. Single Responsibility Principle (SRP) 2. Open/Closed Principle (OCP) 3. Liskov Substitution Principle (LSP) 4. Interface Segregation Principle (ISP) 5. Dependency Inversion Principle (DIP) 2. **KISS (Keep It Simple, Stupid):** Favor simplicity in design and implementation. 3. **DRY (Don't Repeat Yourself):** Avoid code duplication and promote reusability. 4. **YAGNI (You Ain't Gonna Need It):** Only implement features when they are actually needed. 5. **Law of Demeter (LoD) / Principle of Least Knowledge:** Limit the interactions between objects, favoring loose coupling. 6. **Composition Over Inheritance:** Prefer composing objects over inheriting behavior to avoid deep class hierarchies and promote flexibility. 7. **Separation of Concerns (SoC):** Divide a system into distinct sections, each addressing a separate concern. 8. **Principle of Least Astonishment (POLA):** Designs should behave in ways users expect, minimizing surprises. 9. **Fail Fast:** Identify failures as soon as possible to reduce the cost of fixing them. 10. **Don't Design by Committee:** Avoid overly complex designs resulting from input from too many stakeholders. #### Design Patterns: [Design patterns](https://www.mindstick.com/blog/303616/design-patterns-in-programming), on the other hand, are reusable solutions to [common problems](https://www.mindstick.com/articles/13043/handy-tips-for-fixing-wireless-routers-common-problems) encountered during [software development](https://www.mindstick.com/services/erp-software-development). They provide specific implementations of design principles and are more concrete than principles. Design patterns capture solutions to recurring design problems and encapsulate them in a structured format that can be easily reused. Here's a list of some common design patterns used in software engineering: ## Creational Patterns: 1. [Singleton Pattern](https://www.mindstick.com/blog/10912/java-singleton-pattern): Ensures that a class has only one instance and provides a global point of access to it. 2. Factory Method Pattern: Defines an interface for creating objects but lets subclasses decide which class to instantiate. 3. Abstract Factory Pattern: Provides an interface for creating families of related or dependent objects without specifying their concrete classes. 4. Builder Pattern: Separates the construction of a complex object from its representation, allowing the same construction process to create different representations. 5. Prototype Pattern: Creates new objects by copying an existing object, avoiding the need for subclassing. ## Structural Patterns: 1. Adapter Pattern: Allows incompatible interfaces to work together by providing a wrapper that converts the interface of one class into another interface that a client expects. 2. Decorator Pattern: Attaches additional responsibilities to an object dynamically, providing a flexible alternative to subclassing. 3. Proxy Pattern: Provides a placeholder for another object to control access to it. 4. Facade Pattern: Provides a simplified interface to a complex system of classes, acting as a unified interface to a set of interfaces in a subsystem. 5. Composite Pattern: Composes objects into tree structures to represent part-whole hierarchies, allowing clients to treat individual objects and compositions of objects uniformly. ## Behavioral Patterns: 1. Observer Pattern: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. 2. Strategy Pattern: Defines a family of algorithms, encapsulates each one and makes them interchangeable. 3. Command Pattern: Encapsulates a request as an object, allowing for parameterization of clients with queues, requests, and operations. 4. State Pattern: Allows an object to alter its behavior when its internal state changes, encapsulating state-specific behavior into separate classes. 5. Chain of Responsibility Pattern: Passes a request along a chain of handlers, with each handler deciding either to process the request or to pass it along the chain. #### #### Design Principle VS Design Pattern | Aspect | Design Principles | Design Patterns | | --- | --- | --- | | Purpose | Provide general guidelines for [software design](https://www.mindstick.com/blog/300319/the-importance-of-typography-in-software-design). | Offer specific solutions to common design problems. | | Level of Abstraction | High-level concepts and guidelines. | Concrete implementations of design principles. | | Generality | Broad and applicable to various scenarios. | Specific to particular problems or situations. | | Examples | SOLID principles, KISS, DRY, YAGNI. | Singleton, Factory Method, Observer, Decorator. | | Focus | Emphasize how to design software effectively. | Focus on solving specific design problems efficiently. | | Applicability | Applicable across different domains and technologies. | Context-specific and may vary based on the problem. | | Adoption | Used as guidelines to inform software [design decisions](https://answers.mindstick.com/qa/112854/how-does-swarm-intelligence-inform-urban-design-decisions). | Applied directly in code to solve specific problems. | --- Original Source: https://www.mindstick.com/blog/304335/design-principle-vs-design-pattern Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.