I was thinking today about what design is and what it should do. My short version: good design keeps things intuitive for the user. Seems simple, but in reality it's not. I often forget about who I'm designing for at the moment (myself, another developer, user, another class?). Sometimes it's not so clear who the user actually is. In addition good design keeps things well-balanced, and that's the hardest part.
Let's look at example of creating a class. It is made up of several parts (interface, code, documentation, etc.) that potentially have different users. Actually everything starts with the application design. It should make it easier for me (the developer) to create classes that focus on one thing, but at the same time can be used in a variety of places. It would be best if the architecture design would take care of connecting classes together and initializing them (that's what dependency injection does).
Class interface must be simple so that whoever is using the class can use and reuse it easily. It should emphasize the one thing class is trying to do. Everybody is familiar with this (high cohesion, low coupling, etc.) These guidelines, however, come from a more general principle: KISS (keep it simple, stupid). Keep it simple for the user (another developer, another class that will use this class, for the build process to generate good documentation, ahhhh, so many users to make happy). Simple to understand, simple to use, simple to document.
There are a lot of potential issues with simplifying everything. At first it seems that by making things simpler you lose potential power, lose some features. For example a task item in it's simplicity could be just a text field describing the task (this is what BaseCamp does). In more complex scenarios the task would have text fields for the title, for notes, there would be an author, due date, duration, etc. The problem is that as the task entry becomes more and more complex it will be harder and harder to present information in the way that would be easy for the user to understand. It will probably require more detailed documentation (that probably nobody will care to read). If design is poor (and it's harder to make it good in more complex scenarios), the user will have to spend more time learning. In the first case the user could just jump in and create tasks quickly. Where is the balance?
It's different in every case. On one hand there's simplicity (one field) and on the other there's a complexity (many fields). As things move towards complexity they become less and less intuitive. As soon as they stop being intuitive and easy to use design is too complicated. In addition, as user learns, things become simpler. So design needs to be simple at first, but provide new features over time.
Start by making everything as simple as possible. Not as generic as possible, as simple as possible. Don't think about how how many ways something can be used. If you have a square hole you need a square plug. Creating a plug that can shape shift to fit in both square and round holes makes the plug either too complicated to use or of such a shape that it doesn't fit anything anymore.
Remember, potential users of your class include other developers who might want to reuse existing code. Aim to solve the problem at hand, but think about the possibility that the class could be extended in the future. Start by solving a problem. If a similar problem arises in the future you could try to go back and look at your code to refactor out common pattern that can be used to solve both problems. The simpler initial design wa,s the easier it will be to find such pattern and adopt it for new use.
I'm not saying anything new and that all of this is common sense that was around 50 years ago. Still, I think it's important to remind that no matter what you do, keep it simple (but don't lose perspective). In the end you will make things easier for yourself.
Joel is running a long series of articles on great design, if you are interested in more details on design topic.