Design Patterns have proven to be quite useful in software engineering practice. When used appropriately they have proven to have many benefits and have become an indispensable design approach for architects. A design pattern is essentially a reusable approach towards repeatable problems in context. Not only do they have benefits for architects and software engineers/developers but also other role players in an agile process including: project sponsors, project managers, testers as well as users. There are many design patterns and the field is always changing as new anti-patterns are found to disprove the existing approaches making way for new patterns. These patterns may also be elaborated for use at object and class scope levels. The Gang of Four have become a fundamental aspect of object-oriented theory and design. However, not every one is at home with utilizing such approaches within their mindset in practice. Having patterns baked in to the language is often seen as a good thing. And, perhaps this is a flaw in languages like Java which formally expect software engineers to have a design pattern style of thinking towards software development and even object-oriented design in particular. Whereas, functional programming languages take a different route and are simpler. Considering that there are a wide array of design patterns available and most with their relevant domain contexts it only seems plausible to have an intelligent template solution as a refactoring tool/library/plugin. This could be one extension to an intelligent agent model as part of the software engineering development process. The pragmatic agent would need to be able to interpret the code at both a logical but also at a more contextual basis and reason on the basis of understanding where it is appropriate to apply the right design pattern even to identify an anti-pattern. This context of software development automation could be extended to provide other uses within the refactoring process of both functional, service/object-oriented programming, data/object modelling, as well as various others as listed below.
23 Gang Of Four Design Patterns
Behavioral: manage relationships, algorithms, responsibilities between objects
- Chain of Responsibility (Object Scope)
- Command (Object Scope)
- Interpreter (Class Scope)
- Iterator (Object Scope)
- Mediator (Object Scope)
- Memento (Object Scope)
- Observer (Object Scope)
- State (Object Scope)
- Strategy (Object Scope)
- Template Method (Class Scope)
- Visitor (Object Scope)
Structural: build large object structures from disparate objects
- Composite (Object Scope)
- Decorator (Object Scope)
- Facade (Object Scope)
- Flyweight (Object Scope)
- Proxy (Object Scope)
- Adapter (Class/Object Scope)
- Bridge (Object Scope)
Creational: construct objects able to be decoupled from implementation
- AbstractFactory (Object Scope)
- Factory Method (Object Scope)
- Builder (Object Scope)
- Prototype (Object Scope)
- Singleton (Object Scope)
Software Design Pattern
Anti-Patterns
SOA Patterns
Data Science Design Patterns
Big Data WorkLoad Design Patterns
Architectural Patterns
Concurrency Patterns
Interactive Design Patterns
Big Data Architectural Patterns
Microservices Patterns
Microservices Architecture Patterns
Service Design Sheet
Linked Data Design Patterns
Ontology Design Patterns
SourceMaking
Enterprise Architecture Patterns
Enterprise Integration Patterns
Cloud Design Patterns
