| To add to this, don't diminish simple and easy abstractions. There's often a tendency in software development to make use of the fanciest, most complicated tool available, rather than the most practical one. It's easy to forget that just wrapping something up in a handful of static functions and a couple data types is still abstraction, and often it's the right level of abstraction. Design patterns are a great thing to understand but they can be dangerous when used incorrectly. I've had to deal with overly design patterned code and it can be a nightmare. You go searching and searching for the "sharp tip of the spear" where you can actually get something done and then you find out that you need some sort of special object. Then you find out that the object doesn't have a constructor it has to come from a factory method. And you can't just call that factory method with parameters, oh no, you need to pass in some special property bag object, and so on. Don't worry about trying to show off, worry about making your life easier. The ideal situation is that if you want to do some new thing X that is similar to but slightly different from other stuff your system does then you will not only have a good idea of how to do that with the existing primitives, utility methods, abstractions, etc. but it will also be a fairly straightforward task to add that functionality. Ask yourself these questions about your code base: - how easy is it to read the code and figure what it does? - how easy is it to figure out how to use it? - how confident can you be that the code is correct just by looking at it? - how difficult is it to maintain and add new functionality to? - how easy is it to test? Let those guide your designs. |