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.
Related
I am familiar with the term: Separation of Concerns. It's pretty much advocating modularity in your code.
However, when I was reading about AOP, it specifically says that it allows you separate cross-cutting concerns.
So my question is, if AOP separates cross-cutting concerns, what kind of concerns does OOP separate?
OOP separates concerns that in a real-world scenario would be coupled each other with direct associations.
For example, a company has many employees, and employees have a salary.
AOP is about concerns that aren't direct associations but more like sentinels that go beyond object to object relationships.
A typical sample scenario for AOP is logging. Logging is still represented by an object called Logger but actually the logging action is like an observer that filters out the normal flow and extracts information intercepting the flow behind the scenes.
While logging can be implemented without AOP, actually you end up dirtying your code with something that has nothing to do with the purpose of a given action (for example: register an user has nothing to do with logging).
Therefore, you should understand that AOP enforces and improves a good separation of concerns, even taking some requirements out of your eyes, keeping the code simpler.
The short answer: OOP separates abstraction levels. Well-designed OOP code will use a consistent set of abstractions throughout a module.
Long answer: OOP is built on four 'pillars':
Data abstraction
Encapsulation
Inheritance
Polymorphism
These allow a programmer to easily build layers of abstraction, each level using the lower abstractions to provide higher abstractions.
For example, you can build a TCP/IP stack from frames, messages, routing and sessions (Abstractions). When using a session, you do not need to know about how frames are resent, and collision detection (encapsulation). Also, you can send a message without knowing if you are using IP4 or IP6 (polymorphism). And all levels can use the same CRC checking through e.g. inheritance. So these 4 pillars together allow a way of programming where very clean abstraction levels can be created. But all too often, OOP software becomes a mess where the abstraction levels are not cleanly separated.
AOP is complementary to OOP. OOP is focussed on abstraction levels and structures, AOP is focussed on behavior related to 'concerns'. They are orthogonal ways of looking at code.
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...
I am interested to know which GoF design pattern translates directly to a specific SOLID principle? Like for instance I think (in my opinion) the strategy pattern translates to the Dependency-Inversion Principle.
Unfortunately, I could not find any literature that examines their relationships. It would be nice to have to learn both more effectively with each others perspectives.
SOLID principles are applied in most of GoF's design patterns.
S: Single responsability principle: the classes that are part of the
DP, have only one responsability
O: Open/Closed principle: it is easy
to extend with new functionality, for example the strategy pattern
allows you to implement an additional algorithm without having to
change the other classes that contain other algorithms
Liskov Substitution Principle: also applies to strategy for instance
GOF are patterns i.e. proven design solutions to recurring problems. SOLID are principles and are not tied to any specific problem domain hence true in any scenario
What is the difference between Object-Oriented Modeling and Object-Oriented Programming? I overheard a conversation on my subway train this morning and it seems that these things are different. Aren't they?
Object-Oriented Modeling refers to the process where you are designing how the code will look like. You will use a modeling language like UML to do Object-Oriented Modeling. Object-Oriented Programming refers to a programming paradigm where you use objects. These objects have been designed during the desing phase using Object-Oriented Modeling techniques, and they are implemented during the construction (programming phase) using a language that supports Object-Oriented programming and based on the model.
Modeling is creating an abstraction of a problem, where as programming is the implementation of such an abstraction.
Modeling can be done in many ways: textual, formulas, diagrams... UML is one standard of modeling object oriented concepts.
Programming can be done in different ways too, depending on the tool, language etc. There are ways to generate the program right out of the modeling tool, typically out of UML models. This goes even a step further, where UML models are "executed" directly.
Other common confusions about object-oriented programming exist too - starting from "it's the thing where your drag and click", over hybrid 3rd generation concepts I refer to as "processing Objects" to practical patterns and ending with pure OOP.
I'd say the modeling precludes the programing, where the modeling is the physical design, before the programming is implemented.
http://en.wikipedia.org/wiki/Object-Oriented_Modeling
http://en.wikipedia.org/wiki/Object_oriented_programming
I just found this:
Object-oriented modeling is a formal
way of representing something in the
real world. It draws from traditional
set theory and classification theory.
object-oriented modeling is not
limited to computer-related elements.
One may use object-oriented modeling
to represent many different types of
things, from organizational
structures, to organic materials, to
physical buildings.
Object-Oriented Modeling is used to define, usually without any actual code, the classes, methods, and variables. There are many tools out there to help with such modelling. Netbeans is one such package. Netbeans can help you model your code and will even attempt to help you get started after you make your class diagrams.
I found this extraction is from the DTMF website about Key concepts of object oriented modeling.
Abstraction: DENotes the essential
characteristics of an object that
distinguish it from all other kinds of
objects and thus provide crisply
defined conceptual boundaries.
Example: A Cheesburger - is good to
eat and fun to cook.
Modularity: Decomposition of
abstractions into discrete units.
Example: The various "layers" of a
cheesburger - the bun, the lettuce,
the ketchup, the mayonnaise, the
burger, the cheese, onions, pickels,
etc.
Encapsulation: Process of
compartmentalizing the elements of an
abstraction that constitute its
structure and behavior; encapsulation
serves to separate the interface of an
abstraction and its implementation.
Example: • To cook the cheeseburger:
- Is the stove available? Are the burners working? Are the ingredients
available? • To eat the
cheeseburger: - Is it made correctly?
Is my plate clean or disgusting?
Hierarchy: A ranking or ordering of
abstractions. Example: A
cheeseburger is really a subclass of a
hamburger with cheese added which is a
sub class of sandwich which is a
subclass of the Hierarchal superclass
food.
Key Elements: Classes – A collection
of definitions of state, behavior,
and/or identity • Properties •
Methods
Objects: Instances of a class
Associations: Relationships •
Dependency • Identity •
Aggregation • Composition • And
others
Well, given that code is a means of communicating, object-oriented programming in an object-oriented programming language is a form of modelling.
One can however model at a more abstract level using modelling languages that are less expressive, but perhaps more useful for other purposes. For the purposes of developing software, modelling not relatively closely tied to programmes is mainly an exercise for a certain class of person who thinks it is terribly important, and is paid as if it were, but it is not.