Principles & Design
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. |
| Service-Oriented Architecture (SOA) | Designs software as a collection of services that communicate through standardized protocols. |
| Microservices Architecture | Breaks down applications into small, independently deployable services that work together. |
| Component-Based Architecture | Constructs software from reusable, self-contained components with well-defined interfaces. |
| 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. |
| Model-Driven Architecture (MDA) | Focuses on models as the primary artifacts of the development process, generating code from these models. |
| Domain-Driven Design (DDD) | Centers software design around a rich understanding of the domain and domain logic. |
| Event Sourcing | Stores all changes to application state as a sequence of events, allowing for easy replay and auditing. |
| CQRS (Command Query Responsibility Segregation) | Separates read and write operations for data storage, optimizing each for its specific purpose. |
| Actor Model | Models concurrent computation as a collection of actors that communicate via asynchronous messages. |
| Reactive Programming | Deals with asynchronous data streams and the propagation of changes, allowing for reactive and scalable systems. |
| Service-Oriented Integration (SOI) | Integrates software systems using services exposed via well-defined interfaces. |
| Distributed Computing | Designs software to run across multiple interconnected computers, enabling scalability and fault tolerance. |