Creational Design Patterns

One of the goals of object-oriented design is to delegate responsibility among different objects. This kind of partitioning is good since it encourages Encapsulation and Delegation. Creational design patterns are based on these above principles. They can be further classified as:

Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist

Design Patterns in C#

I saw a book on the desk of my boss who is also a software architect. The book is called Design Patterns in C#. It is a really good read. According to me any software developer nowadays needs to be well aware of the different architecture patterns, because only if you are aware of the various architecture design, you can truly appreciate as to what enterprise software development is all about. With good architecture design principles you can wonders with your coding skills.

The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups:
Creational,
Structural and
Behavioral.

In my coming posts, i would discuss each category in detail. These are the basic design patterns, which every developer should be aware of atleast to some extent.

Who said this about programming? (Another good entry from joel's website)

The task of instructing [a programmable machine] could never become tedious, because given a tedious task, there would automatically be the interesting task of instructing the machine in the correct way to perform the tedious task for you.

I think its like:

"Drinking tequila can never become tedious because the task of trying to remember what the heck you did while drunk will always be interesting."

Does Refactoring Make Unit Tests Irrelevant?

I came across a very nice discussion on joel's website (www.joelonsoftware.com).

Argument 1:
I like the idea of using unit tests to help ensure that adding new code or refactoring old code doesn't introduce bugs.
I want to start using the idea, but I can see a problem...
When I'm refactoring, I'll probably be rearranging the "units" of software. If my unit tests refer to the old "units", haven't I just broken all of my tests? So I now have to write new unit tests for my refactored code? New code to test new code -how does that help prevent bugs?
What am I missing here?

Argument 2:
Refactoring as I understand it is rebuilding code within the same unit. Such as rewriting a search function from one algorithm to another that at least in theory is more efficient based on the needs of the application.
However if we ARE changing how units are organized it would have a good chance of forcing a rewrite on unit tests. But then again being forced to acknowledge such a fundemental system change is important as it tends to imply we may be about to break other parts of your application that assume a piece of code is in one particular file/class/etc.

Arguemnt 3:
You'll be writing and fixing tests as you refactor so there is no time when you are writing all new tests or fixing all old tests. You are implementing small chunks at a time and creating/fixing unit tests as you go.

Refactoring requires unit tests. If your code changes breaks the test, then the test has done its job to tell you you have not refactored correctly.

To put it simply:
Refactoring makes Unit Tests ESSENTIAL.

Long time no blog

Its been long, really long that i havent blogged. I had written a blog last time on 29th Spetember. A lto has happened since then. The biggest thing is that i have got a job. Yes i am working as a .NET professional now. Its been more than two months and tell you what i am just loving my job. I am working as a .NET Developer. Christmas is approaching now. It would be fun.
Would update all of my blog readers later in detail.

Have a nice weekend everybody
Ankit