Where to start with .NET Design Patterns?

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

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.

 

Anyway, hope this helps. Best of luck friend.

I'd recommend you start off with the book "Head First Design Patterns" as it uses an easy-going style explaining several patterns
http://oreilly.com/catalog/9780596007126

Good Luck!

First: Go through different types of Patterns

Father of all design patterns: GOF
http://dofactory.com/Patterns/Patterns.aspx

or

http://www.allapplabs.com/java_design_patterns/adapter_pattern.htm

Second:Try to understand these patterns.

Third: Find out the benefits and disadvantages of each and every design patterns

Fourth: Try to use it in your applications.Before using it , think properly. And ask questions like
                1. Is appropriate patterm? 2.Why should I use it? 3.Am I getting benefits?

Fifth: If you are a dotnet developer, then try to find out which patterns are used in dotnet framework and try to understand it and ask yourself why these patterns are used.

By going through such approach , you will have better understanding of design concept.

Once you know design patterns , it doesnt mean you can use these patterns anywhere beacuse
>>it will increase the complexity 
>>it will spoil structure of your project

NOTE: So always point out your design problem in your application and then think about design patterns.

So be careful while using design patterns.:) 

Hope this will help you...

You can also check examples for abstract factory at
http://www.dotnetpal.com/pattern/abstractfactory.html

For Factory medhod Design Pattern
http://www.dotnetpal.com/pattern/factorypattern.html

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

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

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