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

This is exactly what I did. I tried the GoF book first, but that failed miserably. I then found the &quot;Head First Design Patterns&quot; and that got me started. After that, I bought the kit from this site. It was an eye opener! --- Hector SosaJun 05, 2010

Hello fellow developer. You’re certainly not alone. Every developer goes through a stage where the cone of uncertainty is wide and confidence is low. Fear not. Clearly you sound like a dedicated developer, wholike most of us loves the art of creating practical and useful tools and such for the virtual medium. My suggestion to you is to start with a factory pattern and perhaps a dependency injection pattern. Both are relatively simple to implement and are among the most commonly used patterns.

I learn best by examples so I’m going to give you a piece of an example without providing any code. I recently used a factory pattern to create a Web based app using .NET that would allow a user to upload a file that my app would need to be able to read, parse and store into a database. Initially the requirements called for only one specific file format, but I wanted to make the app scalable enough to handle many different file formats, just in case the requirements changed at some point. It’s not advisable to scope creep your own projects, but I knew I could accomplish this with minimal code addition.

So how did I solve this problem? Factory pattern to the rescue. I designed the app in such a way that the factory could choose which parser to execute depending on which file format was uploaded to the system. One of the positive side effects is that going forward, if new requirements emerge to include a new file type, the core factory code never need be modified. I simply add the definition of the file format as a custom type and add the parser code to handle the parser execution and presto, a new file format is ready to be accepted.

The dependency injection pattern comes in handy when abstracting your code for unit testing. It gives you the freedom to pass in a data source or “instance” variable so that your base code has no concrete dependency on any specific data source. This may be something that you’re already doing, but where unaware that there was actually a pattern associated to the method, which happens a lot at first. Sometimes you might find yourself realizing that you’re already using several patterns in slight variations. Those revelations are awesome.

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.

Thats it.

Long explanation:
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.

Another example:
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.

Regards,
-Chris

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...

Just to let you know that i have just published another article in this series.

http://www.codeproject.com/KB/recipes/DecoratorPrimerA.aspx

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