Giới thiệu
"Mỗi pattern mô tả một vấn đề xuất hiện đi xuất hiện lại trong môi trường của chúng ta, và sau đó mô tả cốt lõi của giải pháp cho vấn đề đó, theo cách bạn có thể dùng giải pháp đó hàng triệu lần mà không bao giờ làm nó theo cùng một cách hai lần."
Singleton
"Đảm bảo một class chỉ có một instance duy nhất, và cung cấp một điểm truy cập toàn cục đến instance đó."
Factory Method
"Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." — Gang of Four, Design Patterns: Elements of Reusable Object-Oriented Software, 1994.
🏭 Abstract Factory
"Provide an interface for creating families of related or dependent objects without specifying their concrete classes." — Gang of Four, Design Patterns: Elements of Reusable Object-Oriented Software, 1994.
Builder
"Separate the construction of a complex object from its representation so that the same construction process can create different representations." — Gang of Four, Design Patterns: Elements of Reusable Object-Oriented Software, 1994.
Prototype
"Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype." — Gang of Four, Design Patterns: Elements of Reusable Object-Oriented Software, 1994.
Adapter
"Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces." — Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software
Bridge
"Decouple an abstraction from its implementation so that the two can vary independently." — Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software
Composite
"Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly." — Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software
Decorator
"Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality." — Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software
Facade
"Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use." — Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software
Flyweight
"Use sharing to support large numbers of fine-grained objects efficiently." — Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software
Proxy
"Provide a surrogate or placeholder for another object to control access to it." — Erich Gamma, Design Patterns: Elements of Reusable Object-Oriented Software
Chain of Responsibility
Chain of Responsibility — "Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it." — GoF, 1994
Command
Command — "Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations." — GoF, 1994
Interpreter
Interpreter — "Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language." — GoF, 1994
Iterator
Iterator — "Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation." — GoF, 1994
Mediator
Mediator — "Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently." — GoF, 1994
Memento
Memento — "Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later." — GoF, 1994
Observer
"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."
State
"Allow an object to alter its behavior when its internal state changes. The object will appear to change its class."
Strategy
"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."
Template Method
"Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure."
Visitor
"Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates."
Giới thiệu SOLID
"In software architecture, the SOLID principles are not just rules — they are the distillation of decades of collective experience about what makes code that survives." — Robert C. Martin (Uncle Bob)
S — Single Responsibility
"A class should have only one reason to change." — Robert C. Martin, *Agile Software Development, Principles, Patterns, and Practices*, 2002
O — Open/Closed
"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification." — Bertrand Meyer, *Object-Oriented Software Construction*, 1988
L — Liskov Substitution
"If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T." — Barbara Liskov, "Data Abstraction and Hierarchy", OOPSLA 1987
I — Interface Segregation
"No client should be forced to depend on methods it does not use." — Robert C. Martin, *Agile Software Development, Principles, Patterns, and Practices*, 2002
D — Dependency Inversion
"A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions." — Robert C. Martin, *Agile Software Development, Principles, Patterns, and Practices*, 2002
Giới thiệu DI
"Dependency Injection is where the dependencies are pushed into the object from the outside, rather than the object pulling them in from the inside. It is about inverting the control of the dependencies." — Martin Fowler, "Inversion of Control Containers and the Dependency Injection Pattern", 2004
Hình thức DI
"There are three main styles of dependency injection: Constructor Injection, Setter Injection, and Interface Injection. The question is which to choose, and when." — Martin Fowler, "Inversion of Control Containers and the Dependency Injection Pattern", 2004
DI Container
"A DI container is a framework for automating dependency injection. It's not a requirement — you can to manual DI — but as applications grow, the container becomes an essential tool for managing complexity." — Mark Seemann, "Dependency Injection in .NET", 2011
DI thực tế
"The real power of DI is revealed in real-world applications where infrastructure changes, services grow, and testability becomes critical. Theory is good — practice is better." — Mark Seemann
Giới thiệu Kiến trúc
"Architecture is about the important stuff. Whatever that is." — Martin Fowler
Layered Architecture
"Layered architecture is the most common architectural pattern and the de facto standard for most business applications." — Mark Richards, Software Architecture Patterns
Microservices
"Microservices are small, autonomous services that work together." — Sam Newman, Building Microservices
Event-Driven Architecture
"Events are the atoms of the reactive universe. They are immutable, they happened in the past, and they carry meaning." — Gregor Hohpe, Enterprise Integration Patterns
Hexagonal Architecture
"Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases." — Alistair Cockburn, người tạo ra Hexagonal Architecture
Onion Architecture
"The fundamental principle of Onion Architecture is that the domain is the core — everything else wraps around it like layers of an onion." — Jeffrey Palermo
CQRS
"CQRS is simply the separation of reads and writes into different models, using commands to mutate state and queries to return state." — Greg Young
Event Sourcing
"Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just the current state — the full story." — Martin Fowler
Domain-Driven Design
"The heart of software is its ability to solve domain-related problems for its users. All other features are secondary." — Eric Evans
MVC Architecture
"MVC is not a design pattern — it's a compositional pattern that describes the structure of a system of cooperating objects." — Trygve Reenskaug
MVP Architecture
"The presenter acts as the middleman, mediating between the view and the model, ensuring that the view remains completely passive and testable."
MVVM Architecture
"The ViewModel is the bridge that connects the View to the Model, transforming data into something the View can consume while keeping the View completely ignorant of the Model."
Serverless Architecture
"Serverless doesn't mean there are no servers; it means you don't have to think about them. Focus on your code, not your infrastructure."
SOA Architecture
"Services are the building blocks of SOA. Each service is a self-contained, reusable unit of functionality that can be composed to create complex business processes."
Pipeline Architecture
"A pipeline is a set of data processing elements connected in series, where the output of one element is the input of the next. Pipelines are the backbone of modern data processing and CI/CD systems."
Space-Based Architecture
Space-Based Architecture (SBA) — "Eliminate the database as the synchronous bottleneck by distributing shared state across a grid of processing units using tuple-space memory." — Microsoft Patterns & Practices, 2005
Blackboard Architecture
Blackboard Architecture — "Multiple specialized subsystems (knowledge sources) cooperate to solve a complex problem by working together on a shared structured memory (blackboard), coordinated by a control component that decides which knowledge source to activate next." — H. Penny Nii, 1986
Interpreter Architecture
Interpreter Architecture — "A system where a program's source code or intermediate representation is executed directly by an interpreter engine, which evaluates instructions one by one without requiring a separate compilation step to machine code." — John McCarthy, 1960
Microkernel Architecture
Microkernel Architecture — "A minimal core system provides essential services, while additional capabilities are delivered through plug-in modules that can be independently developed, tested, and deployed." — OS Design Principle, 1980s
Component-Based Architecture
Component-Based Architecture (CBA) — "A software engineering paradigm that emphasizes the decomposition of systems into independent, reusable, replaceable, and composable components, each encapsulating a set of related functionality with well-defined interfaces." — Clemens Szyperski, 1997
Giới thiệu TDD
"Clean code that works — in 30-minute cycles." — Kent Beck, "Test-Driven Development: By Example", 2002
TDD Cơ bản
"The secret to getting good at TDD is to do it. A lot. On small things. Until it becomes reflex." — Kent Beck
TDD Patterns
"Patterns are not just solutions to problems — they are insights into the nature of the design space." — Christopher Alexander
TDD & SOLID
"TDD is not about testing. TDD is about design. The tests are just a means to an end." — Uncle Bob Martin
TDD Real-World
"In real projects, TDD is not a luxury — it's a survival mechanism." — Michael Feathers
TDD Nâng cao
"The most important thing about legacy code is it's code that nobody understands." — Michael Feathers