Would like to know what a programmer should know to become a good at Designing particluarly in Java/J2EE technologies.
Firstly Good Design transcends whichever language you choose to use to implement the design. Good software design is about managing complexity to create easy to understand code which is robust and maintainable. Key points are
- Work in the highest level of abstraction you can at any time
- Encapsulate and hide areas of complexity
- Understand what value there is in clear and consistent naming
In my mind Good design is achieved by a combination of understanding good practice and being creative. And in my experience the hardest part of design is in achieving the right functional decomposition of the problem into smaller sub-problems. It is important to understand that the process of achieving this decomposition is almost always an iterative process rather than a methodical top down process. You have to be prepared to modify or throw away your previous design decomposition until you have something which is maintainable.
It is hard to talk about good design and not to mention two things in particular
- Object Oriented Proctices
- Design Patterns
While some languages are object oriented, some are purely object based and others, like C, were created prior to object based design becoming wide spread, the principles and practices can be applied in any language. Most of the code I write is in C and I try to use object like practices where possible.
Design Patterns present good solutions to common problems and give these solutions names. I have found the study of Design Patterns a key to understanding what good design can achieve.
For beginning to understand design, you should probably first write some toy-projects. Write them, take a step back once in a while and reflect, go back and rewrite. Lather, rinse and repeat.
Making mistakes in design is the best way to understand how you should do better next time. There are of course some methodologies you should be aware of, most important of which patterns and information hiding. Beyond that there are various sources/books for software architecture. For example: Software Architecture in Practice (2nd Edition) (The SEI Series in Software Engineering) by Len Bass, Paul Clements, and Rick Kazman
Try to look closely at where information belongs. Should the interest-rate be a field in Account or AccountType for (a small) example.
Last but not least, try to involve yourself in discussions about design. Debate with your peers, but also pick the brains of more experienced designers/architects.
And stay critical! Although Software Design is more of an exact field than building design with (some) clear pros and cons, taste/preference and rhetoric is still part of the deal.
I would recommend a couple of things:
- Read about some design patterns. The original Gang of Four book helps with OO design. If your are writing Enterprise applications I can't recommend Martin Fowlers Enterprise Application Architecture book too much.
Patterns give you the essential words to describe designs both to yourself and to others. Just reading about the different approaches makes you see new possibilities. If you are looking at J2EE, patterns like Inversion of Control are essential.
- Obsess about loose coupling
The essentials of good design is preventing tight coupling. Anything that can be used to move your code in to loosely couples layers is going to help your overall design.
- Read other people's code. Study some high profile open source code in the your technology area.
Just studying other peoples code quickly gives you a feel for nice looking designs compared to cluttered Big Ball Of Mud approaches.