Design Patterns与Programming Paradigms 中文
- A detailed explanation of classic design patterns and programming paradigms, with practical examples and full comments.
- Implementations in different languages, including
C,Java,JavaScript,Python,Go, etc., reflecting language features. - Continuously updated and improved to create a resource library for design patterns and programming ideas.
| Design Pattern | Description | C Source | Java Source | JS Source | Python Source | TypeScript Source | Go Source |
|---|---|---|---|---|---|---|---|
| Factory Pattern | Provides a unified method for creating objects by a factory class. | C | Java | JavaScript | Python | TypeScript | Go |
| Abstract Factory Pattern | A super factory used to create other factory methods. | C | Java | JavaScript | Python | TypeScript | Go |
| Prototype Pattern | Uses clone() to copy an instance of an existing object. | C | Java | JavaScript | Python | TypeScript | Go |
| Builder Pattern | Builds a complex object step by step using several simple objects, similar to building a house. | C | Java | JavaScript | Python | TypeScript | Go |
| Singleton Pattern | Ensures that a class has only one instance and provides a global node to access that instance. | C | Java | JavaScript | Python | TypeScript | Go |
| Design Pattern | Description | C Source | Java Source | JS Source | Python Source | TypeScript Source | Go Source |
|---|---|---|---|---|---|---|---|
| Adapter Pattern | Provides a specialized compatibility solution for two incompatible interfaces. | C | Java | JavaScript | Python | TypeScript | Go |
| Bridge Pattern | Decouples an abstraction from its implementation by splitting the class into two independent hierarchies. | C | Java | JavaScript | Python | TypeScript | Go |
| Composite Pattern | Combines objects in a tree structure to represent part-whole hierarchies. | C | Java | JavaScript | Python | TypeScript | Go |
| Decorator Pattern | Puts an object into a specially wrapped object to give it new capabilities. | C | Java | JavaScript | Python | TypeScript | Go |
| Facade Pattern | Adds a high-level interface to an existing system to hide the complexity of its subsystems. | C | Java | JavaScript | Python | TypeScript | Go |
| Flyweight Pattern | Shares identical states among multiple objects to load more objects into limited memory capacity. | C | Java | JavaScript | Python | TypeScript | Go |
| Proxy Pattern | Uses a class to proxy the functionality of another class or several classes. | C | Java | JavaScript | Python | TypeScript | Go |
| Filter Pattern | Uses different standard conditions to filter a group of objects, connecting each condition logically. | C | Java | JavaScript | Python | TypeScript | Go |
| Design Pattern | Description | C Source | Java Source | JS Source | Python Source | TypeScript Source | Go Source |
|---|---|---|---|---|---|---|---|
| Strategy Pattern | Encapsulates each algorithm strategy into an interface, allowing strategies to be set as needed, decoupling concrete implementations from strategies. | C | Java | JavaScript | Python | TypeScript | Go |
| Observer Pattern | Notifies and automatically updates all dependent objects when the state of the subject object changes. | C | Java | JavaScript | Python | TypeScript | Go |
| Iterator Pattern | Provides a way to sequentially access the elements of a collection object. | C | Java | JavaScript | Python | TypeScript | Go |
| Template Method Pattern | Defines an abstract public class containing the basic structure of an algorithm, with some steps deferred to subclasses. | C | Java | JavaScript | Python | TypeScript | Go |
| Chain of Responsibility Pattern | Creates a chain of handler objects for processing requests, passing the request along the handler chain. | C | Java | JavaScript | Python | TypeScript | Go |
| Command Pattern | Wraps a request in an object and passes it to the invoking object. | C | Java | JavaScript | Python | TypeScript | Go |
| Memento Pattern | Captures the state of an object and stores it in a memento for future restoration. | C | Java | JavaScript | Python | TypeScript | Go |
| State Pattern | Changes the behavior of a class based on its state, with different behaviors for different states. | C | Java | JavaScript | Python | TypeScript | Go |
| Visitor Pattern | Encapsulates a visitor class, collecting operations for element classes, aiming to separate data structures from data operations. | C | Java | JavaScript | Python | TypeScript | Go |
| Mediator Pattern | Uses a mediator object to encapsulate a series of actions and allow communication between objects. | C | Java | JavaScript | Python | TypeScript | Go |
| Interpreter Pattern | Implements an expression interface and interprets variables and statements within a specific context. | C | Java | JavaScript | Python | TypeScript | Go |
| Principle | Description | Example Code | Counter Example Code |
|---|---|---|---|
| 1. Open/Closed Principle (OCP) | Open for extension, closed for modification. This means adding functionality through extensions without modifying existing code. | Example | Counter Example |
| 2. Single Responsibility Principle (SRP) | A class should have only one responsibility, and avoid multiple responsibilities. | Example | Counter Example |
| 3. Dependency Inversion Principle (DIP) | High-level modules should not depend on low-level modules. Both should depend on abstractions. Concrete implementations should depend on abstract interfaces, not directly on concrete classes. | Example | Counter Example |
| 4. Interface Segregation Principle (ISP) | A class should depend on the smallest interface possible, avoiding unnecessary interface dependencies. It emphasizes high cohesion and low coupling. | Example | Counter Example |
| 5. Composite/Aggregate Reuse Principle (CARP) | When reusing code, prefer composition over inheritance. Composition is more flexible than inheritance in most cases. | Example | Counter Example |
| 6. Law of Demeter (LoD) | An entity should minimize its knowledge of other entities to reduce coupling between system modules. | Example | Counter Example |
| 7. Liskov Substitution Principle (LSP) | Subclasses should be able to replace their base classes without affecting the program's correctness. Subclasses can override abstract methods of the base class but should not override non-abstract methods. | Example | Counter Example |
| Programming Paradigm | Description | Use Cases |
|---|---|---|
| Procedural Programming (PP) | Focuses on executing a sequence of steps, emphasizing program flow and each operation step, often implemented using functions or procedures. | Suitable for small projects or tasks with clear functionality, common in script programming or system tool development. |
| Object-Oriented Programming (OOP) | Organizes programs using classes and objects, emphasizing encapsulation, inheritance, composition, and polymorphism. Focuses on "who does what" rather than "how to do it". | Suitable for large and complex projects, especially those requiring good modularity and scalability. |
| Encapsulation | Bundles data and the functions that operate on that data, controlling access from the outside to ensure data security. | Used to ensure data integrity and security, typically used in complex object modeling. |
| Inheritance | Uses the parent-child relationship between classes, where subclasses inherit properties and methods from the parent class to reuse code. | Used for building shared code and functional hierarchies, such as inheriting from multiple types of animal classes. |
| Composition | Reuses functionality by using a relationship between objects rather than inheritance. | Suitable for flexible modular designs, especially when inheritance relationships become too complex. |
| Polymorphism | Allows the use of the same interface to call different objects, enabling dynamic method binding. | Commonly used to handle uniform interfaces for various types of objects, especially in event handling and strategy patterns. |
| Functional Programming (FP) | Describes programs using pure functions and immutable data, focusing on "what to do" rather than "how to do it". | Suitable for scenarios requiring high concurrency and maintainability, commonly used in data processing and stream processing systems. |
| Aspect-Oriented Programming (AOP) | Involves pre-compiling and dynamic insertion to mount code at specified points without modifying core business logic. | Suitable for decoupling concerns like logging, transaction management, etc., and typically used in enterprise applications. |
| Event-Driven Programming (EDP) | The execution flow of the program is driven by events, with operations triggered by listening and responding to events. | Common in GUI development, server-side applications, and real-time applications (like WebSocket, UI responses, etc.). |
| Reactive Programming (RP) | Focuses on data flows and propagation of changes, implementing reactive operations through asynchronous data streams that automatically respond to data changes. | Used for real-time data flows, UI updates, and asynchronous operations, commonly in real-time monitoring systems and stream data processing applications. |
| Design Principle | Description | Application Scenarios | Example Code |
|---|---|---|---|
| MVC (Model-View-Controller) | MVC is a common design pattern that divides an application into three components: Model, which handles data; View, which presents the user interface; and Controller, which processes user input and updates both the Model and the View. |
Suitable for applications that require separation of presentation and business logic, such as web development and desktop applications. By separating concerns, it improves system maintainability and scalability. | Demo Example |
| MVP (Model-View-Presenter) | MVP is a variant of MVC where the Controller is replaced with a Presenter. The Presenter is responsible for passing data from the Model to the View. The View only displays content and does not directly interact with the Model. |
Suitable for applications that require finer control over view presentation and user interaction, especially when the View undergoes frequent updates or changes. | Demo Example |
| MVVM (Model-View-ViewModel) | MVVM is a design pattern that separates the View from the state and business logic. By introducing a ViewModel, it decouples the View's display logic from the business logic. The ViewModel provides data to the View and responds to user actions. |
Suitable for applications requiring reactive data binding, such as modern frontend frameworks (e.g., Angular, Vue.js) and desktop applications (e.g., WPF). | Demo Example |
| DDD (Domain-Driven Design) | Domain-Driven Design is a software design approach that aims to separate business logic from implementation details, improving code maintainability and scalability. DDD structures the system into multiple layers, each with clear responsibilities and boundaries. |
Suitable for complex business logic and highly evolving business requirements, particularly for large-scale enterprise applications such as financial systems, supply chain management, and healthcare management. | Demo Example |
Welcome to Join
- WeChat: springbuild
- QQ: 12263539
- Email: [email protected]