Principles & Design
No matches. Try a different term.
Object-Oriented Programming (OOP)
| Name | Description |
|---|---|
| Object | An instance of a class that encapsulates data and behavior. |
| Class | A blueprint for creating objects, defining their attributes (data) and methods (behavior). |
| Inheritance | A mechanism in OOP that allows a class to inherit properties and behaviors from another class, promoting code reusability and establishing a parent-child relationship. |
| Polymorphism | The ability for objects of different classes to be treated as objects of a common superclass, enabling methods to be invoked dynamically based on the type of object. |
| Abstraction | The process of hiding complex implementation details and exposing only the essential features of an object, making it easier to understand and use. |
| Encapsulation | The bundling of data and methods within a class, restricting access to the internal state of an object and promoting data integrity by controlling how data is accessed and modified. |
SOLID Principles
| Name | Description |
|---|---|
| Single Responsibility | A class should have only one reason to change, meaning it should have only one responsibility or job. |
| Open / Closed | Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification, allowing new functionality to be added without altering existing code. |
| Liskov Substitution | Objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. |
| Interface Segregation | Clients should not be forced to depend on interfaces they do not use. Instead, interfaces should be specific to the needs of the client. |
| Dependency Inversion | High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. |
Software Design Patterns
| Name | Description |
|---|---|
| Singleton | Ensures that a class has only one instance and provides a global point of access to that instance. |
| Factory Method | Defines an interface for creating an object but allows subclasses to alter the type of objects that will be created. |
| Abstract Factory | Provides an interface for creating families of related or dependent objects without specifying their concrete classes. |
| Builder | Separates the construction of a complex object from its representation, allowing the same construction process to create different representations. |
| Prototype | Creates new objects by copying an existing object, typically used when the creation of a new instance is more efficient than creating it from scratch or with initial parameters. |
| Adapter | Allows incompatible interfaces to work together by providing a bridge between them. |
| Decorator | Attaches additional responsibilities to an object dynamically, providing a flexible alternative to subclassing for extending functionality. |
| Observer | Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. |
| Strategy | Defines a family of algorithms, encapsulates each one, and makes them interchangeable. |
| Command | Encapsulates a request as an object, thereby allowing for parameterization of clients with queues, requests, and operations. |
Software Development Principles
| Name | Description |
|---|---|
| Modularity | Divide the software into separate modules to enhance maintainability, reusability, and scalability. |
| Decoupling | Minimize dependencies between modules or components to improve flexibility and facilitate easier updates or replacements. |
| SoC (Separation of Concerns) | Divide a software system into distinct sections, each addressing a separate concern, to improve readability and maintainability. |
| KISS (Keep It Simple, Stupid) | Strive for simplicity in design and implementation, avoiding unnecessary complexity that can lead to confusion and maintenance difficulties. |
| DRY (Don't Repeat Yourself) | Eliminate redundancy in code by abstracting common functionalities into reusable components, reducing the risk of errors and improving maintainability. |
| YAGNI (You Aren't Gonna Need It) | Avoid implementing features or functionalities until they are actually needed, preventing unnecessary complexity and over-engineering. |
| Fail-Fast | Detect and report errors as soon as possible to prevent them from propagating and causing further issues, facilitating faster debugging and resolution. |
| Convention Over Configuration | Use sensible defaults and conventions to minimize the need for explicit configuration, promoting consistency and reducing cognitive load. |
Software Development Paradigms
| Name | Description |
|---|---|
| Procedural Programming | Focuses on procedures or routines to execute a series of computational steps. |
| Object-Oriented Programming (OOP) | Organizes software design around objects that encapsulate data and behavior. |
| Functional Programming | Emphasizes the use of pure functions and immutable data to model computation. |
| Imperative Programming | Specifies a series of statements that change a program's state. |
| Declarative Programming | Describes what the program should accomplish rather than how to achieve it, allowing for a more abstract approach. |
| Event-Driven Programming | Relies on events triggered by user actions or system events to determine program flow. |
| Aspect-Oriented Programming (AOP) | Separates cross-cutting concerns (such as logging or security) from the main application logic. |
| Reactive Programming | Deals with asynchronous data streams and the propagation of changes, allowing for reactive and scalable systems. |
| Actor Model | Models concurrent computation as a collection of actors that communicate via asynchronous messages. |
| Distributed Computing | Designs software to run across multiple interconnected computers, enabling scalability and fault tolerance. |
Software Architectures
| Name | Description |
|---|---|
| Monolithic | Single, unified codebase deployed as one unit — simple to start, harder to scale and evolve independently as it grows. |
| Layered (N-Tier) | Organizes the system into horizontal layers (presentation, business, data); each layer only depends on the one directly below it. |
| Client-Server | Splits responsibility between requesters (clients) and providers (servers) communicating over a network. |
| Model-View-Controller (MVC) | Separates the application into three interconnected components: Model (data), View (user interface), and Controller (logic). |
| Model-View-ViewModel (MVVM) | A variation of MVC where the ViewModel mediates communication between the View and Model, enabling data binding in UI frameworks. |
| Hexagonal (Ports & Adapters) | Isolates core domain logic from external concerns via ports (interfaces) and adapters (implementations), keeping the core independent of frameworks, UI, and databases. |
| Onion Architecture | Concentric layers around a domain core with dependencies pointing inward only — outer layers depend on inner ones, never the reverse. |
| Clean Architecture | Robert Martin's synthesis of hexagonal and onion: entities at the center, use cases around them, and the Dependency Rule enforcing inward-pointing dependencies. |
| Component-Based | Constructs software from reusable, self-contained components with well-defined interfaces. |
| Service-Oriented Architecture (SOA) | Designs software as a collection of coarse-grained services that communicate through standardized protocols, often via an enterprise service bus. |
| Microservices | Decomposes the application into small, independently deployable services that own their data and communicate over the network. |
| Service-Oriented Integration (SOI) | Integrates disparate systems by exposing capabilities as services through well-defined interfaces. |
| Serverless | Application logic runs as ephemeral, event-driven functions on managed infrastructure, with no server provisioning or capacity planning. |
| Event-Driven Architecture (EDA) | Components communicate by producing and consuming events asynchronously, decoupling producers from consumers in time and identity. |
| Event Sourcing | Persists application state as an append-only log of events; current state is derived by replaying them, enabling full audit and time travel. |
| CQRS (Command Query Responsibility Segregation) | Separates read and write models so each side can be optimized, scaled, and evolved independently. |
| Pipes and Filters | Processes data through a sequence of independent transformation stages (filters) connected by pipes, each stage doing one thing. |
| Space-Based | Removes the central database bottleneck by distributing state across an in-memory data grid; processing units scale horizontally for high-load systems. |
| Domain-Driven Design (DDD) | Models software around a rich understanding of the business domain, using ubiquitous language and bounded contexts to align code with the problem space. |
| Model-Driven Architecture (MDA) | Treats models as the primary development artifacts, generating code from platform-independent and platform-specific models. |