Click here to Skip to main content
15,867,835 members
Please Sign up or sign in to vote.
1.00/5 (2 votes)
See more:
Which pattern can be implemented if there is a situation like that in e-commerce system:

There exists a customer and the message (notification) which is about the product's changes like price etc. It is related observer pattern in that notify part. But I have a doubt which design pattern should i use Facade or Adapter while providing communication customers' accounts via mail, or facebook and other social websites. Because they are different APIs and the social and mail accounts have different interfaces to realize communication.
Posted
Comments
Sergey Alexandrovich Kryukov 29-Dec-13 16:01pm    
To me, it sounds that you are trying to misuse the idea of design patterns, or you simply did not provide adequate information. The goals and requirements of the product should be first analyzed much deeper, even some tentative root solutions should be considered, and only then you should look around for the available design patterns to see if they can help. You even need to take into account available resources, code asserts you have, things like that.
—SA
pasztorpisti 29-Dec-13 16:06pm    
Exactly. Reading the question immediately reminded me about some monsters created by "pattern magicians". In my opinion patterns mainly exist to speed up communication between developers and not for actually "building the whole software from them".

You can create a good interface that is a common denominator of many other APIs only if already know the other APIs and the intersection of their functionalities. Often the good solution is not a bloated wanna-be-smart and generalized interface but one that contains only a few simple-stupid functions that are needed by your software. What I recommend: 1. as a first solution create a simple-stupid interface that reflects the requirements of YOUR product. 2. implement the interface for many APIs.

The interface my contain a few functions like sendNotificationMessage() or like() or whatever. The interface my contain some optinal functions that don't have to be implemented by all APIs if implementation is not possible and maybe a special function that can query the capabilities of the actual implementation (for example wheter like-ing is available). This way if a new API comes all you have to do is taking a look at the interface of the interface of your app and create an implementation for the give API.

In my opinion don't try to solve everything with patterns. This problem is too small to build a complex "system" around it. History will decide whether you need to create that "system" or "manager" or "handler" or whatever kind of monster in the future...
 
Share this answer
 
v2
Comments
Sergey Alexandrovich Kryukov 29-Dec-13 16:05pm    
There is a number of good points in this post, I voted 5.
At the same time I added a comment and a short answer (Solution 2) which I believe explain the root of the problem, please see.
—SA
Sergey Alexandrovich Kryukov 29-Dec-13 16:10pm    
I just added the [EDIT] to Solution 2 to credit your answer and to try to explain your last point, please see. :-)
—SA
pasztorpisti 29-Dec-13 16:13pm    
:thumbsup: :-) :-) :-)
Nelek 29-Dec-13 18:05pm    
My 5 as well
pasztorpisti 29-Dec-13 20:10pm    
Thank you!
Please see my comment to the question. I strongly believe that the project should not be driven by design patterns, but your project should drive the choice of design patterns. Sorry if this advice is not specific enough, but it is no less specific than your description of the goals of your product you need to develop.

[EDIT]

Please see solution 1: this is a good idea: "don't try to solve everything with patterns". Why? Because otherwise you can put yourself in a Procrustean bed: http://en.wikipedia.org/wiki/Procrustes#Contemporary_usage[^].

—SA
 
Share this answer
 
v2
Comments
pasztorpisti 29-Dec-13 16:11pm    
+5, I agree again. An interesting thing is that I've already met a few exceptionally good programmers who didn't really know extensively about patterns but still wrote great code. An experienced programmer uses the good constructs wherever needed. This fact is somewhere a proof of your statement and my opinion that patterns are rather to name "complex software constructs" to speed up communication between developers. Of course patterns can be a good learning source for the beginner.
Sergey Alexandrovich Kryukov 29-Dec-13 16:16pm    
Thank you. One of the developers who learned about those patterns very late was myself. (I doubt I was "exceptionally good", but some considered me as successful enough by that time. :-) And, up to this very time, I actually don't remember a single case when I ever use any of the patterns 100% literally (except some simplest ones, like RAII or Singleton), but maybe this is only because I rarely do any routine development. If you read the Wikipedia article on pattern, you can find well explained "criticism" section... "To speed up communications between developers" is a really good concept...
—SA
pasztorpisti 29-Dec-13 16:39pm    
I my opinion the most important thing is clear separation between modules with clear interfaces. A typical codebase often just grows and adding some new critical functionalities often appear as a dirty layer on top of what we already have (because the blurry requirements and unknown future, and quickly adding "triable things" with shortcuts). When the "final form" of the feature is more or less known then a good programmer is able to remove the added dirty layers (the result of the heavy plumbing) and incorporate them without all the dirty tricks and shortcuts by keeping the nice modularity and interfaces. In my opinion a lot of programmers fail in this. I treat those who can do this as "exceptionally good". Some companies don't spare the time to cleanup the mess left there after plumbing (time and $) but good programmers navigate more confidently even in mess as they more or less see how should it look like. There is no need at all for design pattern knowledge to be able understand other's code and to create well separated modules and/or clean interfaces. What I would recommend those who want to learn patterns: they should rather try to become good enough to write clean interfaces (even an interfaces can be screwed up badly!). I've met a few interfaces already and when the protocol (the rules of using the interface, possible func call orders, etc..) isn't clear (especially if this is spiced up with total lack of comments) that can be terrible even if we have "the interface". So here when I use the "interface" word it shouldn't be treated literally (just like patterns).
Sergey Alexandrovich Kryukov 29-Dec-13 17:00pm    
Agree, those are really good points. And the advice on how to learn the patterns is really good.

I often give my own, some more generalized advice applicable to many problem: before trying to find a solution, try to solve it all by yourself. It gives a number of benefits: 1) even if the chance to invent something better and totally original can be pretty low, you are not loosing this chance, 2) even if your attempts to solve the problem independently are not very successful, you still can read about the solutions proposed by others afterwards and.., 3) perhaps the most important item: if you finally have to learn them, you can understand what you read much better.

—SA
pasztorpisti 29-Dec-13 17:10pm    
Agree, no one can escape fighting a few dragons themselves before becoming a hero. At the very beginnings I mostly created my own stuff (and the total lack of internet probably helped in this a lot). Today I think it doesn't consume a lot of time and energy to check out the available solutions even if all we do is just a shallow checking of the interfaces or public interfaces. Sometimes this gives some really good hints when designing our own interface. EDIT: of course reading other's code was quite uncomfortable for me too at first. That's a "skill" that must be gained as early as possible. Lazynass can be a big enemy in this case... :-)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900