After reading about bridge design pattern I inspect other design patterns and find out: patterns which using aggregation of abstract class / interface in some way using Bridge.
Does it?
Related
As i know many design pattern in oop languages, in Lua just capabilities of itself. So i want to know and if there is example of design pattern which apply in Lua.
Singelton and command no need special implementation as i see.
As it known, there are Creational, Structural and Behavioural design patterns. But I didn't find which the class of MVC pattern. What should it be?
MVC is not a design pattern defined by Gang of Four. Rather it is a more high level architectural pattern which encompasses several design patterns defined by Gang of Four. At a minimum the MVC pattern uses Observer pattern which is a Behavioral pattern. There are some more design patterns used by MVC. Sometimes the patterns it uses may depend on the particular implementation too.
So to sum up MVC uses several design patterns defined by Gang of Four to achieve it's mission. Hence it is a collection of design patterns.
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.
I'm working on the issue of design patterns. In this case I want to implement design pattern 'Facade'
I know that 'Cocoa Touch' offers us complete solutions for applying design patterns in our projects (for example NSNotificationCenter - implements observer design pattern)
My questions is next: - do we have ability to using design pattern 'Facade' as well as in the case of the observer design pattern.
Now I implement 'Facade' like this:
For example i have some classes which implements some calculations. The 'Facade' class combine all classes which I needed to calculations.
For example i have classes A, B, C and Facade (which contain A, B and C classes).
When I want to calculate something I just create my 'Facade' and pass some argument for calculation. In this case I don't know about classes A, B, C and this Facade object provides me one access point only.
This design pattern encapsulates objects and simplifies the application.
Is it correct implementation?
Another a good example for implementing facade pattern - pizza call service.
For example, pizza service (subsystem) is very large and it consists of three departments (interfaces) : order department, discount department, delivery department. Each departments has own logic and interfaces.
You can simply implement facade pattern on it.
Here this example in more details.
A Facade is defined as unified interface to a bunch of interfaces - sort of higher level interface to reduce the complexity. Instead of dealing with several classes and knowing the API's of each its reduced to the facade. Your explanation looks OK to me.
It is correct explanation (i don't see implementation). Nice association to Facade pattern in real life is remote control - you can run TV functions, DVD and so on.
The motivation behind the facade pattern is to provide a simplified interface for often-used cases, while accommodating the ability to reach past the simplified interface and interact with more complex aspects of the classes behind the facade when neccessary. As you've described your implementation, it would certainly seem to fit the description, and there is no reason you couldn't use a facade pattern in combination with a notification/observer pattern...
Can I implement Strategy Pattern using AOP. I would like to either
1. Override the default algorithm
2. Or Would like to dynamically select any of the given algorithm.
Thanks,
Look at "AspectJ Cookbook" by Russell Miles. It provides implementation of almost all classical design patterns from the point of AspectJ's view. Here is direct link to strategy pattern http://books.google.com/books?id=AKuBlJGl7iUC&lpg=PP1&pg=PA230#v=onepage&q&f=true.