I am currently learning the proxy pattern and have found two different implementations of it in two different books. Please see the links for patterns UML Diagrams as I cannot embed the pictures yet.
Pattern 1
Pattern 2
My teacher says that Pattern 1 is the correct implementation, although most of the tutorials and sources use the Pattern 2 implementation. My teacher argues that Pattern 2 is wrong because "It allows the proxy to call all public methods on the RealSubject, which makes it not really different from the adapter pattern", while Pattern 1 "enforces that the proxy only can call the functions from the interface class inside the real subject"
My questions are:
What are the real differences between these two UML diagrams? Don't they show the same thing in essence?
If Pattern 2 is wrong, why does the majority of sources, including books, use it to show the Proxy pattern?
Thank you for your answers.
The difference between the two diagrams is that in #1 the Proxy references the Subject interface, whereas in #2 the Proxy references the concrete Subject implementation (a.k.a. RealSubject).
Both of these diagrams are correct, because the Gang of Four Proxy pattern covers a number of different use cases: on page 208 they list remote proxy, virtual proxy, protection proxy, and smart reference as different implementations of the same pattern. The implementations vary to the extent that some of them are aware of their concrete subject and some are not.
This distinction between awareness or ignorance of the concrete subject often causes confusion about the differences between the Proxy and Decorator patterns. It should not confuse Proxy with Adapter; because in the Adapter pattern, the Client and Subject have entirely different interfaces (hence the need for an Adapter). Proxy (and Decorator) share a common interface with their Client and Subject.
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.
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 have an interface that is implemented by thirty concrete classes. The concrete implementers are subdivided into two groups, with each group inheriting from a common abstract class. The abstract classes define the constructors for the concrete implementers, including passing in a database connection object for each "side" of the two sides (they have different databases, among other differences).
All the current interface methods each have several parameters needed for the concrete classes to "get the job done", but not all are used in every implementer.
When I went to add a new method to the interface this morning, I realized that the database connection is going to be needed for only one of the concrete implementers, but the rest will not need it. So, that gets me wondering, should I pass it in as a parameter? It is needed to "get the job done", but for only one of the concrete classes, and that class has the database connection already. If I passed the database connection in as an interface parameter, then the other 29 classes will not use it.
What is a good line to draw for what is an acceptable interface parameter? Any reading/content on the subject I will thankfully devour as well.
All the current interface methods each have several parameters needed
for the concrete classes to "get the job done", but not all are used
in every implementer.
That sounds to me a lot like the interface is slowly turning into a bit of a "god interface". Check whether this is the case by asking yourself a couple of questions:
Does the interface represent a single behavioural concept in your model, or has it become a bit of a convenient dumping ground for method signatures from several concepts? Could it be called something like e.g. Serializable, or would it more accurately be called SerializableAndSomethingElse.
Could you carve the interface up into several more cohesive interfaces, and have the 30 different objects implement just the ones they need?
When I went to add a new method to the interface this morning, I
realized that the database connection is going to be needed for only
one of the concrete implementers, but the rest will not need it. So,
that gets me wondering, should I pass it in as a parameter?
No. In fact, if the database connection is only needed by one of the implementers then it doesn't sound like it belongs in the interface at all. The interface should represent the abstract API, where as it sounds as though the database connection is a part of the implementation of that API.
If it's not part of the abstraction -- then it shouldn't be in the interface. And if it's only used by 1 of 30 implementing classes, then it's definitely not part of the abstraction.
I did a quick google search for 'api design' and the first hit was:
slides of a presentation by Joshua Bloch.
His points that are relevant to your question:
"When in doubt leave it out"
'Don't let implementation details “leak” into API'
"API design is tough", but also, "API design is a noble and rewarding craft"
"Expect to make mistakes"
It sounds like you have a tough problem to solve -- but good luck!
It sounds like you are following implementation driven design as opposed to use case driven one. You'll be able to answer some of these questions yourself by considering the perspective of the caller. I've got more details in this blog post:
http://theamiableapi.com/2011/08/29/considering-the-perspective-of-the-caller/
Cheers,
Ferenc
The constructor arguments to your various classes should be collaborators (or configuration values) used in processing. This is the how. These can vary for the 30 different implementations. If the database connection is required for some and not others, then only supply it as a constructor argument to one.
The interface then forms a basis for the processing should be done. This is the what.
You should strive for an interface where the API name, arguments and methods are at the same conceptual level. Constructor arguments are likely to be at a lower conceptual level.
Anyone have a naming strategy that works well for service proxy classes?
For example, if I am given three web services within two projects as follows:
XWs
AService.asmx
YWs
BService.svc
CService.svc
What would use as the Service Reference Name & Namespace for AService, BService and CService ?
In general, I'd like something in the proxy name/namespace to indicate that the thing being used is not a concrete class, but represents a proxy - both so it doesnt clash with usage of concrete classes [and force usage of aliasing or namespace-qualified class names], and so we're not hiding the fact that there's a hop happening (I guess the Wcf Service Proxy generator's default suffix of Client covers that). Also important is that it deals with cases where one is writing a wrapper/shim service that is forwarding a [sub]set of calls to another referenced service.
I've used various styles (Adding Ws, ServiceProxy, Ref or Proxy suffixes? Prefixing with ServiceName.), but have never been fully happy with them.
What's worked well for you? Any style guides make reference to a naming style?
Edit: While Cheeso's answer covers the bulk of my question, I'm still interested in hearing answers on:
A strategy for namespacing proxy classes as in the example above
A style guide that mentions a naming strategy for proxies
I originally used names like ServiceNameProxy and ServiceNameSvcProxy. But, like you, I haven't been particularly satisfied with those names, and as a result I did not stick with them. Now I just resort to ServiceNameService or ServiceNameSvc.
Is the key thing you want to communicate to users of the class that the class is a proxy? The distinction you are making - between a proxy class and a concrete class - seems like applies and alligators. The opposite of concrete is abstract, no? And the proxy class generated by svcutil.exe is, in fact, concrete.
With a naming convention, I think you are trying to indicate that the proxy class communicates to a remote service. (When we call it a "proxy", we mean to indicate it stands in front of something, in this case the remote service. ) If that is the case, then why not ServiceNameService or ServiceNameConnection, or along similar lines? Like System.Data.OleDb.OleDbConnection or System.Data.SqlClient.SqlConnection.
My own chosen naming convention is in line with that. It indicates that the class represents a service, which is assumed to be remote. I don't care so much to accentuate the fact that it is a proxy-to-a-service. For practical purposes the fact that it is a Service is the key thing.
I am also exploring options here. I just read this article by Miguel Castro and he recommends separating out the service, service host, data contract and service contract and I am primarily trying to decide if I should keep all of my service contracts in a separate contract namespace or let those live in each service namespace. Reason for separating them out into their own namespace is that if other services utilized them they are in a more neutral location.
So for example this:
companyname.services.contracts.service1contract
companyname.services.service1
or this:
companyname.services.service1
companyname.services.service1contract