Architecture:MediaWiki/Pattern language

Classes in the MediaWiki code base use the pattern language outlined below. As per version 1.35, the pattern language is aspirational. That is, the patterns described here do not describe current reality, but are intended as a guide for creating new code and for improving existing code.

Patterns, in no specific order:

• entry point pattern
• wiring pattern (including hook handlers)
• view pattern
• cursor pattern (iterators, etc)
• batch pattern
• pager pattern
• input form pattern
• service object pattern
  • stateless service pattern
  • service container pattern
  • data access object pattern
    • lookup pattern
  • factory pattern
    • registry pattern
• handler pattern
  • content handler pattern
  • API module pattern
  • action pattern
  • special page pattern
  • media handler pattern
  • page pattern (page types?)
  • provider pattern (vague, could be a factory)
• codec pattern (serializer/deserializer)
• command pattern (aka business action)
• validator pattern
• formatter pattern
• skin pattern
• renderer pattern
• localizer pattern
• builder pattern
• event pattern
• listener pattern
• job pattern
• data update pattern
• output aggregator pattern
• data object pattern
  • record pattern (has ID)
  • immutable value pattern
    • exception pattern
  • active record anti-pattern
  • content pattern (deprecate?)
• parser pattern (?)
• cache pattern
• writer pattern
• hook handler pattern
• client object pattern
• adapter pattern
• maintenance script pattern

Patterns

These patterns serve as reusable solutions to common problems encountered in software architecture and design. While some patterns are specific to certain technical layers, others can be applied across multiple layers, enhancing the flexibility and maintainability of the codebase. This overview categorizes and describes each pattern, offering insights into their applications and potential restrictions.

Entry Point Pattern

Defines a clear entry point for application execution, ensuring that the application starts predictably.

Wiring Pattern

Involves the configuration of components and their dependencies, often utilizing hook handlers to manage events and interactions.

View Pattern

Separates the presentation layer from the business logic, allowing for a clean and maintainable user interface.

Cursor Pattern

Utilizes iterators to traverse collections of data, providing a consistent way to access elements without exposing the underlying structure.

Batch Pattern

Processes a group of items together, optimizing performance and resource usage by minimizing the number of transactions.

Pager Pattern

Facilitates the navigation of large datasets by dividing them into manageable pages, improving user experience and performance.

Input Form Pattern

Standardizes the creation and validation of input forms, ensuring consistent data collection and user interaction.

Service Object Pattern

Encapsulates business logic within service objects, promoting separation of concerns and enhancing testability.

Stateless Service Pattern

Designs services that do not maintain state between requests, allowing for scalability and easier management.

Service Container Pattern

Manages the instantiation and lifecycle of service objects, providing a centralized location for dependency injection.

Data Access Object Pattern

Abstracts the data access layer, providing a consistent interface for interacting with data sources.

Lookup Pattern

Facilitates the retrieval of objects or services based on a key, promoting loose coupling and flexibility.

Factory Pattern

Creates objects without specifying the exact class of the object being created, promoting encapsulation and flexibility.

Registry Pattern

Maintains a centralized registry of objects, allowing for easy access and management of shared resources.

Handler Pattern

Defines a mechanism for processing requests or events, often used in conjunction with other patterns.

Content Handler Pattern

Manages the processing and rendering of content, ensuring that the correct format and structure are applied.

API Module Pattern

Encapsulates the functionality of an API, providing a clear interface for interaction with external systems.

Action Pattern

Defines a specific action or command that can be executed, often associated with user interactions.

Special Page Pattern

Handles unique or specialized pages within an application, providing tailored functionality and presentation.

Media Handler Pattern

Manages the processing and delivery of media content, ensuring compatibility and performance.

Page Pattern

Defines various types of pages within an application, promoting consistency in structure and behavior.

Provider Pattern

Offers a way to supply dependencies or services, often acting as a factory for creating instances.

Codec Pattern

Handles the serialization and deserialization of data, ensuring compatibility between different formats.

Command Pattern

Encapsulates a request as an object, allowing for parameterization and queuing of requests.

Validator Pattern

Standardizes the validation of input data, ensuring that it meets specified criteria before processing.

Formatter Pattern

Handles the formatting of data for presentation, ensuring consistency and adherence to standards.

Skin Pattern

Allows for the customization of the user interface, enabling different visual styles without altering functionality.

Renderer Pattern

Manages the rendering of content, separating the logic of content generation from its presentation.

Localizer Pattern

Facilitates the translation and localization of content, ensuring that applications can support multiple languages.

Builder Pattern

Encapsulates the construction of complex objects, allowing for step-by-step creation and configuration.

Event Pattern

Defines a mechanism for event-driven programming, allowing components to communicate through events.

Listener Pattern

Handles the subscription and response to events, promoting decoupling between event producers and consumers.

Job Pattern

Encapsulates a unit of work that can be executed asynchronously, promoting scalability and responsiveness.

Data Update Pattern

Manages the process of updating data, ensuring consistency and integrity throughout the application.

Output Aggregator Pattern

Combines multiple outputs into a single response, optimizing performance and resource usage.

Data Object Pattern

Represents a data structure, often used to transfer data between layers of an application.

Record Pattern

Defines a data structure with a unique identifier, facilitating easy retrieval and management.

Immutable Value Pattern

Creates objects that cannot be modified after creation, promoting safety and predictability.

Exception Pattern

Consistently handles error conditions, promoting robustness and maintainability.

Active Record Anti-Pattern

Identifies the pitfalls of using an active record pattern, where business logic and data access are tightly coupled.

Content Pattern

Manages the representation and processing of content, though its relevance may be diminishing.

Parser Pattern

Facilitates the interpretation and processing of structured data, ensuring that it can be transformed into usable formats.

Cache Pattern

Improves performance by storing frequently accessed data in memory, reducing the need for repeated data retrieval.

Writer Pattern

Handles the output of data, ensuring that it is formatted and delivered correctly.

Hook Handler Pattern

Manages hooks within the application, allowing for extensibility and customization.

Client Object Pattern

Encapsulates the interaction with external services or APIs, promoting separation of concerns.

Adapter Pattern

Facilitates compatibility between incompatible interfaces, allowing for seamless integration.

Maintenance Script Pattern

Defines scripts for performing maintenance tasks, ensuring that they are executed consistently and reliably.

Conclusion

While some patterns may be confined to specific technical layers, others can be leveraged across multiple layers, providing flexibility and promoting best practices in software design.

Some patterns may be confined to technical layers, but others may be applicable on all layers. Some layers may have restrictions on what other patterns they can make use of.