Mar 22, 2010
Welcome to the world of design patterns, and yes you're not alone.
I used to feel the same way, esp when i started, and still feel this way now. I am trying to tackle this problem in my recently started series. I am trying to explain them in terms of a scenario, so new comers will understand what should be the thought process. Yet only one on strategy pattern. Another on decorator pattern is in process.
I am trying to learn from the mistakes i made, While trying my level best to make it as simple as possible, i made the pattern to much isolated. Anyway, it may help you to get started with at least one
Apr 16, 2010
Just to let you know that i have just published another article in this series.
The intention behind this series i have already mentioned. Your feedback is tooooooo much welcome, as it will help me shape this series. It's a bit delayed publication. I was supposed to publish it 2 weeks before, but things came up. Anyway i am going to write another on Creational Patterns (Simple Factory, Factory Method, Abstract Factory and builder). Hopefully this won't get delayed. But feedback will be vital. Thank you
Jul 29, 2010
Hm... I quickly scanned through your replies to the question above... and there's one thing I noticed and that I dislike. He explains that using specific patterns in nothing that comes naturally into his mind. Your replies basically work like "Learn about patterns, look for examples, identify pattern usage in code, etc.".
I have a different suggestion:
Reflect your code.
Patterns are common solutions for common problems/requirements. I believe that - before you come to understand every pattern in detail (hint: get the design pattern framework, it will help in regards to a deep understanding in this topic), you need to identify problems that you have with your code.
If everything's fine... why change? However, I guess not everything is fine... and I guess you will also guess that sometimes. And this is when pattern come into play.
Consider the following situation: Imagine a class that has a set of properties and you are about to implement lets say the fifth constructor ovverride to initialize the class properly. When others come across that class they might find it difficult to understand which constructor to use and when. Here you have your problem. Because ctors MUST have the same name, you couldn't offer any design time help by for instance naming the ctors after their concrete purpose.
The solution: Factory methods. Simple declare the ctor private so that it cannot be called and implement static public Factory methods that return new instances of your class. Those can be named after their purpose.
You are developing a classic three tier application. In your database, three tables exist that contain data that depend on eachother. For each table you have a datalayer class accessing the data and a business logic class implementing business rules. However, when you want to make use of the data you might find yourself in a situation in which your presentation layer needs to know the implementation of your complex implementation. For example it needs to update your three business objects and then persist them in the correct order (yeah, I know that there are better ways). Here you have you problem: Maybe you need to do this in different places... and actually it makes no sense that some instance of a highlevel module know about a complex implementation on the low level end.
The solution: The Facade pattern. Simply implement a class that knows your subsystem dn publishes simple methods that can be used to do whatever needs to be done... however, your high level classes do not have to know the subsystem anymore.
Now I've done it, too. Presenting examples, ... ;-)
But basically, what I really wanted to say is: Whatever you do, ask yourself if it can be done better and identify possible problems... the moment the recognize that something's going wrong or may lead to a problem, you will try finding a solution and eventually come across some pattern that solves it. The more you go this way the more you will get used to implementing those patterns right in the beginning.
I know programmers who still instantiate and dispose objects manually even when they implement the IDisposable interface, instead of using the using statement... I know this has nothing to do with patterns... but it's a common way of thinking: Disposing your objects manually increases the possibility of forgetting... the using statement does this automatically instead.
P.S.: More than 3000 Views... and only a hand full of replies... guys... this is entitled as a forum. Would love to see more discussion here...