There's a strong tendency in software development to make software as flexible as possible. Developers seemed obsessed by "what if" questions - what if someone wants to have a different algorithm for doing something? What if they want to fetch data from a file instead of a database? What if they want to use XML instead of a fixed file format? What if they want to use their own custom classes? What if they need extra features that you don't provide?

To allow for these "what if" scenarios, they make heavy use of design patterns. They use abstract factories to avoid hard-coding the class names. They use a strategy or an interpreter to avoid coding an algorithm directly. They use an observer pattern in case anyone wants to be notified of things that happen in their classes. They implement a visitor pattern in case someone wants to traverse their object network.

Unfortunately, there's a cost to making your software flexible - it becomes more complex. Flexibility and simplicity are at opposite ends of a teeter-totter. As you add flexibility, you reduce simplicity.

Which is most valuable? In general, I prefer to err on the side of simplicity. After all, it's easier to add complexity than to remove it. If you have a design that's already complex, it's hard to simplify it.

My rule of thumb is to make the design only as flexible as it needs to be. If there's no clear and immediate need for a more flexible design, choose a simple design instead. If you're wrong, you can change it later. If you choose flexibility over simplicity, you tie yourself into a complex design but may never need to use the flexibility that it gives you.