Originally posted by Peer Reynders: OOA/D usually stands for Object Oriented Analysis and Design - the "D" stands for "design", not "development". As such you may expect to see some example code but don't expect lots.
I respectfully disagree. The whole purpose of design is to assist in producing good code. So to lean what good design is, you need to learn how design translates into code, and what good code is. Be wary of books that don't connect the design to code.
My personal favorite is the above mentioned "Agile Software Development" by Robert C. Martin.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Aug 19, 2005
Originally posted by Ilja Preuss: I respectfully disagree. The whole purpose of design is to assist in producing good code. So to lean what good design is, you need to learn how design translates into code, and what good code is. Be wary of books that don't connect the design to code.
I�m not advocating BUFD (Big Up Front Design) here. I almost felt like celebrating when I read Martin Fowler�s Is Design Dead? six years ago, as it emphasized the importance of code and refactoring. However OOA/D covers such a large range of activities that you can only dedicate so much room to "code" � there are other forms of communication necessary during Analysis and High Level Design. Granted Graig Larman's text is, as one reviewer put it, "tediously thorough" but that's what makes it valuable as a reference not just as a learning tool. If you�d use the amount of example code as a discriminator you�d miss out on Rebecca Wirf-Brock's Object Design Roles, Responsibilities, and Collaborations (no code), Eric Evan�s Domain Driven Design � Tackling Complexity in the Heart of Software (a little Java code), Martin Fowler�s Analysis Patterns � Reusable Object Models (some Smalltalk code) - just to name a few examples. Yet I believe that these books make important contributions to the reader�s capability of cracking the type of problems which software is supposed to help solve.
use uml either to generate code or for communication/understanding of your system, though system-complete code generation with uml will still take some years... if you use uml for upfront design, where you map from diagrams to your code manually it becomes a maintaining horror, because your design emerges after development time. keeping two models (uml+java) synchronized manually is tough error prone work.
so only learn uml roughly and invest more effort into refactoring, which connects closely to (emergent) object oriented design. but i think uml-diagrams are a great way to communicate with yourself and with colleagues.