In general, I know that there are 3 big types of design pattern
Creational Pattern (Factory, Singleton, etc)
Structural Pattern (Composite, Adapter, Proxy, etc)
Behavioral Pattern (Specification, Command, etc)
But I dont know which type I can put the Repository pattern in.
Is Repository pattern in one of three above type? Or is it kind of in the middle of (2) and (3) pattern?
Repository can be viewed as a special kind of Façade (structural) but also as a special kind of Factory (creational). Also, as the Repository often expose collection-like interface, then it might be a special application of Iterator (behavioral).
What I am trying to say is that neither those categories nor patterns themselves are any sort of definite doctrine. There are just some ideas and a language that tries to make them more explicitly visible. These categories are just helpers trying to express somehow what some patterns do. Also patterns are just various expressions of a generic loose coupling principles. Their borders are blurry.
A repository is a specialisation of the Facade pattern which is structural.
I assume you refer to the repository pattern by Martin Fowler.
He says:
Repository: Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
He himself categorizes the pattern as "Object-Relational Metadata Mapping".
If you want to use the categories in the GOF book, I'd put it into the structural pattern category as the focus of this pattern is to present an interface/view to a client, similar to the Adapter/Facade/Proxy patterns.
Related
I have a question about Facade design pattern. As i started learning design patterns from the book: Elements of re-useable object -oriented-software, there is a good explaination of what it is and how it solves the problem.
This Picture comes from that book:
Problem:
Suppose i add some extra functionality in the subsystem for which Domain is an Facade/interface. With this design, i think it's not possible to add extra functionality in the subsystem without changing the Domain class?
Second, suppose i use an abstract class Domain(to create a hierarchical structure) and delegate all the requests to it's subclasses so that whenever i want to add new functionality , i simply extend my new class/subsystem with Domain(abstract), would that be wrong or still i will have a Facade structure?
Same thing happends in Adapter pattern. We can have different kind of adapter and instead of hard-coding one class , can we create such an hierarchial structure without violating any OOD rule?
The facade as well as the adapter design patterns are part of the so called "wrapper" patterns (along with decorator and proxy). They essentially wrap certain functionality and provide a different interface. Their difference is on their intent:
facade: is used to provide a simple interface to clients, hiding the complexities of the operations it provides behind it
adapter: allows two incompatible interfaces to work together without changing their internal structure
decorator: allows new functionalities to be added to an object statically or dynamically without affecting the behavior of objects of the same class
proxy: a class (proxy) is used to represent and allow access to the
functionality of another class
If your components "in the back" add new functionality and you want your facade to expose this functionality, you would have to adjust your facade to do so.
If you have the Domain class (facade in your scenario) as an abstract class that others extend, you do not have a facade, you have whatever inheritance you created with your classes. Simply put there is no "wrapping" for achieving the intent of the facade pattern.
With this design, I think it's not possible to add extra functionality in the subsystem without changing the Domain class?
True. However, the changes you make may (or may not) affect the client (Process) class. If you add a new method to the Façade, it won't break the "old" clients. Although it's not its explicit intention (which is to hide complexities of a sub-system), Façade can provide a stable interface to its clients that can be extended. When I say interface, I don't mean a Java or C# interface. It's a programming interface.
A real-world example is the JOptionPane Façade in Java/Swing. Check the Java doc at the link I put and you'll see that some of its methods existed in 1.4, some in 1.6, etc. Basically, since this class is part of a Swing library, it had to remain stable so old clients of it's interface would not break. But it was still extended with new functionality by simply adding new methods.
I would say this is how Façades are typically extended, not with sub classing or hierarchy. Hierarchies are difficult to maintain, because they are brittle. If you get the abstraction wrong (the root of the hierarchy), then it affects the entire tree when you need to change it. Hierarchies make sense when the abstraction in the hierarchy is stable (certain).
The Adapter pattern has hierarchy because an Adapter adapts a method to work with several variants of a service that cannot be changed. You can see examples of several stable (abstract) services such as tax calculation, accounting services, credit authorization, etc. at https://stackoverflow.com/a/13323703/1168342.
My understanding of "factory-related" design patterns and their OOP-implementations has always been pretty simple.
A "Factory method" is a method inside a class that has an interface (or an abstract class) as a return type and constructs objects implementing this interface based on some internal logic.
A "Factory" is a class that only contains factory methods
An "Abstract factory" is an interface (or an abstract class) that only contains factory methods
But I recently stumbled upon Wikipeda articles on the subject (Factory, Abstract factory) that made me somewhat confused, especially about what a "Factory" is in OOP.
Here are several quotes:
A subroutine that returns a "new" object may be referred to as a "factory", as in factory method or factory function.
Factories are used in various design patterns
The "Abstract factory pattern" is a method to build collections of factories.
A factory is the location of a concrete class in the code at which objects are constructed
which arouse some questions:
(1)&(2) Does this mean that a factory is not a class or an object, but a piece of logic?
(2) Is "Factory" not a pattern itself?
(3) What does "collection" mean here? Is it just a way of saying "you can have several factories that implement the same interface (which is an abstract factory)"?
(4) What???
Can anyone clarify what this means? Is my initial understanding of factories incorrect?
Look at this wiki which says:
In object-oriented programming (OOP), a factory is an object for
creating other objects – formally a factory is a function or method
that returns objects of a varying prototype or class from some
method call, which is assumed to be "new".[a] More broadly, a
subroutine that returns a "new" object may be referred to as a
"factory", as in factory method or factory function. This is a basic
concept in OOP, and forms the basis for a number of related software
design patterns.
So to answer your questions specifically:
(1)&(2) Does this mean that a factory is not a class or an object, but a piece of logic?
No, it means that you can create other objects using an object(factory).
(2) Is "Factory" not a pattern itself?
There are different design patterns out of which factory pattern is one. So when you are creating objects using a factory then that patter of creating other objects is "Factory pattern"
I think you generally have it right. But, people don't like general, so it's the specifics where things go pear-shaped.
There a few things to consider:
Wikipedia is sometimes woefully bad on technical subjects because they are trying to get to a single answer where different domains or programming languages may use the terms slightly differently. Not only that, many people are not skilled at technical writing and forget that Wikipedia is for the masses, not a graduate-level computer science theory class. As such, they tend to overly focus on minutiae or use language more complicated than necessary. So, don't worry about Wikipedia. And, although there is an edit history, no real names tend to be attached to these and no one really cares who wrote which words, so no one is that motivated to do that well. Having expressed that quite cynical opinion of the whole endeavor, reading the Talk pages are very interesting, in a Cunningham's Law sort of way.
(2) The name "Factory" is a pattern, but remember that patterns are general ideas, not implementations. Different languages may employ the same idea in different ways, and those different ways may not agree. A particular language or community starts to use the term in the way most meaningful to them, however, despite what anyone else thinks. That idea may show up in bare, procedural logic; classes; objects; or whatever the tool provides.
Design Patterns (the book(s)) are generally describing shortcomings in tools. They also aren't really design patterns in the way the authors think they are. Mark Jason Dominus has a wonderful talk on this, "Design Patterns" Aren't. His basic idea is that the Gang of Four misunderstand Christopher Alexander in that they (accidentally) prescribe solutions rather than promote the idea of a locally-relevant architectural language. So, the Gang of Four patterns become reified in languages almost exactly as the described single possible solution. Readers then force those patterns as a globally-relevant language completely disconnected from what you personally are trying to build, then argue about what it all really means out of any sort of context using extremely ill-suited examples that don't matter to what anyone is trying to build. There's no reason your recommendation engine and someone's first person shooter should have the same architectural language other than your tool forcing it on both of you. FWIW, paying attention to Mark Jason Dominus is a very good professional development move. His Higher-Order Perl is one of the best programming language books I've read and certainly better than anything I've written. He knows a lot of different languages (and languages that are very different) and thinks very deeply about things.
In (3), the term "collection" is unfortunate because we tend to use that to mean a set of things that co-exist at a particular time in the same container (box, book, whatever). I think they are trying to suggest that the abstract factory is a template for future factories that cannot be presently enumerated, which is a fancy way of saying that we can use it to build factories we don't even know about yet.
In (4), the term "location" is unfortunate. An abstract factory is a way of producing concrete factories, which is a way of producing objects.
I recently written a ValidationBundle, to validate the arguments passed to a method. Validation bundle accepts different types of Validator's. Upon validating the bundle, it invokes each one of the validators registered with the bundle. I was wondering if any pre-existing design pattern is followed or not?
Well, the Builder pattern is obviously used to construct the ValidatorBundle and the Iterator pattern is used to loop through it.
This isn't the typical Strategy implementation you would see in a tutorial, but assuming there is an abstract Validator which is implemented by DataTypeValidator, ArgLengthValidator, etc., then I think it's fair to label them as "a family of interchangeable algorithms," which qualifies as the Strategy pattern.
Going beyond design patterns, it would be interesting to see this implemented with a different paradigm. Specifically, I think this type of validation could be implemented as a cross-cutting concern with AOP.
I have a class hierarchy of patterns: patterns are split into simple patterns and compound patterns, both of which have concrete implementations.
Patterns have a Match method which returns a Result, which can be a Node or an Error.
All patterns can check for a memoized result when matching. Simple patterns return an error on EOF.
Is there a pattern that allows a more simple way to reuse implemented functionality than mine? Let's say we're using a single-inheritance, single-dispatch language like C# or Java.
My approach is to implement Match at pattern level only and call a protected abstract method InnerMatch inside it. At simple pattern level, InnerMatch is implemented to handle EOF and calls protected abstract InnerInnerMatch, which is where concrete implementations define their specific functionality.
I find this approach better than adding an out bool handled parameter to Match and calling the base method explicitly in each class, but I don't like how I have to define new methods. Is there a design pattern that describes a better solution?
Possibly Strategy pattern
The strategy pattern (also known as the policy pattern) is a software design pattern that enables an algorithm's behavior to be selected at runtime. The strategy pattern
defines a family of algorithms,
encapsulates each algorithm, and
makes the algorithms interchangeable within that family.
And perhaps Chain of Repsonsibility
The chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.
But the Chain of Responsibility would depend more on how you want to handle allowing multiple 'Patterns'(your Objects, not 'design patterns') to be 'processed' in order.
Chain of Responsibility might also be good for allowing you to have dynamic Pattern "sets" that different inputs can be processed with. (Depending on your needs.)
You'll have to encapsulate your input values, but that isn't too big of deal.
What is the difference between an 'Abstraction' and a 'Facade'?
Is there a difference at all? Or are the terms interchangeable?
The facade pattern is an simplified interface to a larger, possibly more complex code base. The code base may be a single class, or more. The facade just gives you a simple interface to it.
Abstraction, is used to represent a concept, but not to be bound to any specific instance. (Ie: An abstract class). This doesn't imply simplifying (like the facade pattern does), but rather making a 'common' interface or representation.
Facade is a specific design pattern, meant to hide the internal stuff inside a package / module from its clients behind a well-defined interface. It usually hides several interfaces/classes behind a single common one, hence its name.
'Abstraction' is a general term, meaning to hide the concrete details of something from the outside world.
So these two are not interchangeable terms.
Facade is a GoF design pattern, very specific. In essense, it's about hiding over-complex functionality from the main body of your application.
Abstraction is a more vague term related to hiding functionality of a service from its client.
Abstract to me means taking the common parts of a collection of things and creating a base thing from them, which the collection can then draw on, sort of like a parent class.
A façade is a face (literally speaking), so they analogy of a base class doesn't quite hold. A façade is more of an interface, so it wouldn't have to be related to the things that use it. I think of it more like a mask. My class will have a "disposable" mask, for example.
So the difference, in my mind, is that an abstract pattern allows a hierarchy to be built, where as a façade pattern allows classes look similar.