There is much value in existing design patterns that other developers have created.  While there is value in them, they aren't always right in every situation, which is why each design pattern usually lists the situations in which they should be used.  It is up to you as the developer to determine whether it is right for the situation.  This is the biggest challenge for me because it's interpretive; you have to interpret whether your situation fits within this pattern.  With all of my study of design patterns, I still don't understand this concept.

What if you make the wrong choice?  I think that is the reason for a lot of hesitation on behalf of developers to use and study design patterns.  However, in my experience, most of what I know is because I did make the wrong choices in my design.  When asked about the failures with the light bulb, Thomas Edison responded "I have now eliminated 1000 ways it does not work and I get closer and closer to success."  However, design patterns can work the other way; we can "what if" ourselves to death wondering if this is the best design, and constantly seeking perfection or seeking to refactor because we want to try out a new design pattern we learned about.  A balance is needed.

There are other principles that can help with this.  Nilsson mentioned in his book, Domain-Driven Design, about the Single Responsibility Principle (SRP).  This principle is designed to simplify object-oriented development by creating each object to have only a single responsibility.  Using this principle, this means that a business object can represent the data provided from the data source, but it's the responsibility of another class to instantiate it (such as a factory).  You can see an example of this in the previous section.

I must admit, I often violate this principle.  For instance, I often think it as beneficial to store an internal static method that instantiates an object from the data that it is loaded from.  Sometimes, I have a class that serves two functions embedded in the same class, and although it makes the class much bigger by adding methods/properties, it is easier to manage this way.

Because of this, I'm of the opinion that if it really works and I'm consistent with my implementation, then I'm OK if it violates some patterns/principles.