Can someone point out the main differences between the two?
It seems that, at least conceptually, the two are very closely related. If I were to hazard a guess, I would say that the publish/subscribe method is a subset of the mediator pattern (since the mediator need not necessarily be used in the publish/subscribe manner, but the latter seems to require a sort of mediator object). Is that anywhere near close to it?
How I would describe the difference is that in mediator you probably care if the end application receives the message. So you use this to guarantee who is receiving the message. Whereas with pub/sub you just publish your message. If there are any subscribers they will get it but you don't care.
According to this page, the publish-subscribe model is an implementation of the mediator pattern.
Edit
I should note that the design patterns are called "patterns" precisely because there are going to be differences among every implementation. They aren't so much a set of decreed, canonical forms as they are a collection of observations on how people already write software. So there really isn't any way for a design to "strictly" adhere to a design pattern.
The implementation could be the same, but logically they are different (The difference is simple, but it is hard to see).
I'll explain it in a simple way below.
Pratically, in the implementation of the Publish/Subscribe pattern you will have at least an object with the methods "publish" and "subscribe".
But you can have also more of them, so the communication between components is not centralized by definition.
In the implementation of the Mediator pattern you will have JUST ONE object with methods "publish" and "subscribe". So the communication is "centralized" by definition.
In the GoF book, publish/subscribe is known as the Observer Pattern. The Mediator Pattern can be implemented using the Observer Pattern; but that is not the only way to implement a Mediator. The book describes this on page 278.
Colleague-Mediator communication. Colleagues have to communicate with their mediator when an event of interest occurs. One approach is to implement the Mediator as an Observer using the Observer pattern. Colleague classes act as Subjects, sending notifications to the mediator whenever they change state. The mediator responds by propagating the effects of the change to other colleagues.
Another approach defines a specialized notification interface in Mediator that lets colleagues be more direct in their communication... When communicating with the mediator, a colleague passes itself as an argument, allowing the mediator to identify the sender.
Note that even when implementing a Mediator as an Observer, it is described as communicating only among its colleagues whereas an Observer in general would likely communicate with other objects as well.
I think one main point of difference is the context of the problem.
Although a problem could be solved with either pattern, the real concerns are:
1: "How much change to bring about by the events are dependent on the general context ?"
2: "How frequently are the listeners expected to change?"
The classical case for the mediator pattern best illustrates this where you have a complex UI with a lot of components and the updation on each has a complex inter-dependency on the state of other similar components.
Although you can solve this problem with the pub/sub pattern; wherein your components listen for events and contain the logic necessary to update, the context object (along with the event) carry all necessary information. Here the advantage is obviously the proper encapsulation of logic pertaining to a component within itself. The downside is that if such components are supposed to change often then you have to replicate this logic fully in each new component you bring in.
To use a mediator is to introduce another layer and further abstract from the components. These components become thinner as they only deal with representation (UI look and feel) thus, become very easy to change. The only problem I have with this approach is that the updation logic now seems to spill to other components and any updation of the system would require one to change the component and the mediator if the component behavior is also to change.
That to me is the major dilemma/trade-off we need to solve. Please correct me if I haven't got anything correctly.
Related
I have been solving following problem. I'm a newbie in C++ and I need to implement
a state machine for an embedded software. This state machine should constitute
core of an application logic. It should control transitions between states
"STANDSTILL", "RUN" and "FAULT" of a controller. These transitions occur based
on: logic inputs state, analog inputs state, messages received over communication lines and messages created internally in the controller's software.
I would like to implement this state machine in such a manner that I utilize the
power of the C++ (object oriented programming). So I have spent some time in
looking for some appropriate design pattern. I have found the "state" desing
pattern but I am not sure whether it is a good choice for me. As far as
I understand the definition in right manner it is intended for situations when I
have some object (so called context object) which behavior (methods of its public interface) is strongly dependent on its state.
My first idea was that the so called context object could be the controller itself. (I mean a class which will realize the software model of the whole device.) The state dependent methods could be the methods asociated with the above mentioned inputs processed by the state machine i.e. logic inputs, analog inputs, messages received over communication lines and internal messages. But I am not sure whether it is good approach. Does anybody have any experience with such usage of the state design pattern? Thanks for any suggestions.
Just because you are using C++, you are not necessarily using object-oriented design. Nor do you have to use OOD when implementing trivial things. It is quite feasible to implement a state machine without involving OOD, since it is such a simple data structure. Basically it is just an array (of function pointers) with named members.
The "pattern" is known as finite state machine. A typical C implementation for embedded systems can be found here. You could write a simple class around that array. State machines in embedded systems are almost always static and read-only, so the class would have to be a "Singleton". You'll find that there's no obvious benefit of using a class here.
the state pattern is a good design to start with. But as mentioned, there are existing tools that can generate the code for you. Another one you could look at is http://scxmlcc.org. This one create code that uses 'the power of C++' and is also based on the state pattern design.
I have a web service that triggers some long operations on the server via asynchronous methods. Each operation has 3 methods:
One of them start the operation and immediately returns a ticket number.
One of them is called continuously from the client; it receives the ticket number and returns a boolean value, saying whether the operation is done.
The last one of them is called only after the operation is finished; it receives the ticket number and returns the result of the operation.
I'm not sure how to call this methods. I think about calling the methods something like this:
OperationName_Start
OperationName_IsReady
OperationName_GetResult
but I'm afraid I could be reinventing the wheel. Is there any well known naming convention for this usage pattern?
Its a shame you couldn't get an answer the first time around. I would strongly suggest reading this SOA Principles Link to gain a better understanding of the principals and importance of web service naming.
It's key to remember to name from the perspective of the consumer and maximise consumability and re-useability. Its also useful to remember that when you invoke a service, your are performing and action on an object i.e. you should have a verb and a noun. Also remember that web services are very very similar to functions in an object oriented language, so its helpful to think of what the code of the function of the web service would look like.
It's helpful to consider scenarios like:
What would happen if i changed the system the web service was calling?
Is there another scenario that could call this service?
How granular should the service be? What are the performance impacts of these decisions?
Without knowing the business context of what you are trying to achieve, we'll assume a basic example of submitting and electronic payment.
In this scenario, you may have:
ElectronicPayment_SendPayment (Note: the use of 'Send' keeping the business context, not the technical context; send could be via email, post, webservice. From your 'Start' example, what are you starting; here, the intent of the service is apparent)
ElectronicPayment_CheckStatus (Note: this is from the consumer's perspective. It's likely that checking processing status is a generic service, that could be seperated into something along the lines of CheckProcessingStatus (TicketNumber tN)
ElectronicPayment_RetrieveReciept (Note: Request/Response pattern with semantic link. Business Context of receipt and payment maintained)
Naming is highly contextual, and the above is not perfect, but hopefully it helps yourself and others who stumble upon this.
From the lack of answers, I assume that apparently there isn't a widely used standard on this issue, so it's OK to roll my own.
I chose to stick with:
OperationName_Start
OperationName_IsReady
OperationName_GetResult
We are currently building a pile of SOAP Web Service to front the access of various backend systems.
While defining our Request/Response message XML, we see multiple services needing the ‘Account’ object with different ‘mandatory/optional’ fields.
How should we define and enforce the validation of these ‘mandatory/optional’ fields on the same Message? I see these options
1) Enforce validation with XSD by creating different 'Account' Complexe Type
Pros : Design time clarity.
Cons : proliferation of Object Type, Less reuse of Object,
2) Enforce validation with XSD by Extending+Restriction a single base 'Account' type
Pros : Design time clarity.
Cons : Not sure of the support of the Extend+Restriction feature (java, .Net)
3) Using a single 'Account' type and enforcing validation in runtime (ie in the Code).
Pros: Simple
Cons: No design time validation. Need to communicate field requirements via a specification doc.
What are you’re thoughts on that?
I would have to assume that: i) some of what you would call optional fields are actually fields that are not applicable (don't make sense) to all accounts and ii) we're not talking trivial scenarios (like two type of accounts with 2 fields each-kind of thing).
Firstly, I would say that unless you're really lucky, from a requirements perspective, then you're going to end up with some sort of "validation in runtime" no matter what option you're going with. XML Schema can't express some common data validation requirements, such as cross field validation; or simply because the data in your XML is not sufficient to feed the rules to validate the integrity of the message (the data in the message being a subset on what's available at the time the XML is being un/marshalled).
Secondly, I would avoid deriving new complex types through restricton; from an authoring perspective you don't achieve much in terms of reuse, and you might end up with problems in how that is interpreted by your XSD to code tooling. I like to think that the original intention of deriving through restriction was to provide a tool for people to use in xsd:redefine scenarios; for people that wouldn't want to fiddle with XML Schemas that were authored by someone else. If one owns (authors) the schema, one can work around the need to restrict by defining the "lesser" object first and extend from that.
As to the "proliferation of objects", you are kind of getting that with option #2 as well (when compared with #1); what I mean by that, all the tools I know will create a class for each named (global) complex type you have in your XSD; so if you have to have three type of accounts, you'll have three for scenario #1, and four, or so, if you choose to extend from one, or so, base classes; a worst case scenario for the later would be when you need three specializations (concrete if you wish); anyway, from my experience, the difference in real life scenarios is not something that would really tip the decision one way or the other.
Extending base types in XML Schema is good for reuse; however, reuse brings coupling; if you're analysing this from a forward/backward compatibility point of view, extending something in the base type could mess up some of the unmarshalling (deserialization) of the XML for clients of your service(s) that don't want to change their code base, yet you want to maintain only one Web Service endpoint for all; in this case, a forward-compatibility strategy that relies on an xsd:any at the end of a compositor (xsd:sequence) would be rendered useless in your first release that goes and extends your base type.
There is even more; because of this, I don't think there's a correct answer, just for the criteria you seem to imply by setting your pro/cons.
All of my preferred options below assume that you put high value on the requirement to ensure forward/backward compatibility of your services, and you want to minimize the cost of your clients having to deal with your services (because of XML Schema changes).
I would say that if all your domain (accounts in particular) can be fully modeled (assume no future change basically) and that there is enough commonality to justify reuse, then go with option #2. Otherwise, go with option #1 since I have yet to see things that don't change...
If the modeling of your domain can be done 80% or more (or some number that you think is high) and that there is enough commonality to justify reuse, then I would still go with option #2, with the caveat that any future extensions for common attributes across accounts, must be applied for each individual account (basically turning your option into a hybrid, by doing #1).
For anything else, I would go #1. Whew, I can't believe I wrote all of this...
So, I've come back to ask, once more, a patterns-related question. This may be too generic to answer, but my problem is this (I am programming and applying concepts that I learn as I go along):
I have several structures within structures (note, I'm using the word structure in the general sense, not in the strict C struct sense (whoa, what a tongue twister)), and quite a bit of complicated inter-communications going on. Using the example of one of my earlier questions, I have Unit objects, UnitStatistics objects, General objects, Army objects, Soldier objects, Battle objects, and the list goes on, some organized in a tree structure.
After researching a little bit and asking around, I decided to use the mediator pattern because the interdependencies were becoming a trifle too much, and the classes were starting to appear too tightly coupled (yes, another term which I just learned and am too happy about not to use it somewhere). The pattern makes perfect sense and it should straighten some of the chaotic spaghetti that I currently have boiling in my project pot.
But well, I guess I haven't learned yet enough about OO design. My question is this (finally. PS, I hope it makes sense): should I have one central mediator that deals with all communications within the program, and is it even possible? Or should I have, say, an abstract mediator and one subclassed mediator per structure type that deals with communication of a particular set of classes, e.g. a concrete mediator per army which helps out the army, its general, its units, etc.
I'm leaning more towards the second option, but I really am no expert when it comes to OO design. So third question is, what should I read to learn more about this kind of subject (I've looked at Head First's Design Patterns and the GoF book, but they're more of a "learn the vocabulary" kind of book than a "learn how to use your vocabulary" kind of book, which is what I need in this case.
As always, thanks for any and all help (including the witty comments).
I don't think you've provided enough info above to be able to make an informed decision as to which is best.
From looking at your other questions it seems that most of the communication occurs between components within an Army. You don't mention much occurring between one Army and another. In which case it would seem to make sense to have each Mediator instance coordinate communication between the components comprising a single Army - i.e. the Generals, Soldiers etc. So if you have 10 Army's then you will have 10 ArmyMediator's.
If you really want to learn O-O Design you're going to have to try things out and run the risk of getting it wrong from time to time. I think you'll learn just as much, if not more, from having to refactor a design that doesn't quite model the problem correctly into one that does, as you will from getting the design right the first time around.
Often you just won't have enough information up front to be able to choose the right design from the go anyway. Just choose the simplest one that works for now, and improve it later when you have a better idea of the requirements and/or the shortcomings of the current design.
Regarding books, personally I think the GoF book is more useful if you focus less on the specific set of patterns they describe, and focus more on the overall approach of breaking classes down into smaller reusable components, each of which typically encapsulates a single unit of functionality.
I can't answer your question directly, because I have never used that design pattern. However, whenever I have this problem, of message passing between various objects, I use the signal-slot pattern. Usually I use Qt's, but my second option is Boost's. They both solve the problem by having a single, global message passing handler. They are also both type-safe are quite efficient, both in terms of cpu-cycles and in productivity. Because they are so flexible, i.e. any object and emit any kind of signal, and any other object can receive any signal, you'll end up solving, I think, what you describe.
Sorry if I just made things worse by not choosing any of the 2 option, but instead adding a 3rd!
In order to use Mediator you need to determine:
(1) What does the group of objects, which need mediation, consist of?
(2) Among these, which are the ones that have a common interface?
The Mediator design pattern relies on the group of objects that are to be mediated to have a "common interface"; i.e., same base class: the widgets in the GoF book example inherit from same Widget base, etc.
So, for your application:
(1) Which are the structures (Soldier, General, Army, Unit, etc.) that need mediation between each other?
(2) Which ones of those (Soldier, General, Army, Unit, etc.) have a common base?
This should help you determine, as a first step, an outline of the participants in the Mediator design pattern. You may find out that some structures in (1) fall outside of (2). Then, yo may need to force them adhering to a common interface, too, if you can change that or if you can afford to make that change... (may turn out to be too much redesigning work and it violates the Open-Closed principle: your design should be, as much as possible, open to adding new features but closed to modifying existent ones).
If you discover that (1) and (2) above result in a partition of separate groups, each with its own mediator, then the number of these partitions dictate the number of different types of mediators. Now, should these different mediators have a common interface of their own? Maybe, maybe not. Polymorphism is a way of handling complexity by grouping different entities under a common interface such that they can be handled as a group rather then individually. So, would there be any benefit to group all these supposedly different types of mediators under a common interface (like the DialogDirector in the GoF book example)? Possibly, if:
(a) You may have to use a heterogeneous collection of mediators;
or
(b) You envision in the future that these mediators will evolve (and they probably will). Hence providing an abstract interface allows you to derive more evolved versions of mediators without affecting existent ones or their colleagues (the clients of the mediators).
So, without knowing more, I'd have to guess that, yes, it's probably better to use abstract mediators and to subclass them, for each group partition, just to prepare yourself for future changes without having to redesign your mediators (remember the Open-Closed principle).
Hope this helps.
The problem to model is this:
A hierarchy of levels within an Army, starting with the national army in whole, through field armies, subunits, and eventually the individual men. Each level may involve links to one or more other classes such as General or Officer or whatever. The units within say a field army need to be able to communicate with each other, especially for purposes of modeling morale, cohesion, etc, as well as with those of any enemy field army (e.g. a unit routing in my army affects the enemy morale positively). Furthermore, each unit needs to communicate with those above and below it in the hierarchy (for obvious purposes).
I was thinking of having the links in the physical hierarchy represented by actual pointers (possibly bilateral) in each of these entities' classes (e.g. army* in each unit and unit* or a whole collection of them in each army) and then making use of the observer design pattern to implement any communication in other cases (such as the case I mentioned above).
However, being no expert in design patterns or programming for that matter I do not know whether there is any other more efficient manner to do this. Any help would be greatly appreciated.
There is a model/design pattern for communicating events between disparate entities that may not know of eachothers existence before the communication happens. The pattern is called 'Publish/Subscribe'.
Each entity sends events it wants to publish to a broker and tells the broker about what kinds of events it would be interested in. The broker handles making sure the subscribing entities learn of events they find interesting that are published.
This is like the Observer pattern, but in the Observer pattern each interested entity subscribes individually to each entity it wants events from. I think this could result in a lot of overhead because that requires everybody to care about creation and destruction of things.
Anyway, there is a nice Wikipedia article on Publish/Subscribe.
I would use the Composite pattern (which basically means a tree of some form) for the individual armies. And possibly Observer for relationships up and down the hierarchy or with siblings. But Observer requires too much registering and unregistering for it to be workable in the general case.
Sounds like "Small Boy With A Pattern" syndrome. You're looking for a pattern instead of thinking about your problem.
The natural data structure for a hierarchy is a tree. I'd start with that.
If the requirement is that every unit in the tree must communicate with all others, I'd say that Observer is not for you. Every unit would have to be register with all the others. You'll have an N-squared firestorm of messages every time an event was fired.
Mediator might be better. Units would send events to the mediator, allowing consumers to register their interest in receiving a particular kind of message. Producers and consumers only know about the mediator, not each other. Loose coupling is your friend.
For modeling the structure, this looks like classic application of the Composite pattern. Then you can use Visitor or Interpreter for modeling the operations on sub-units.