This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Learning, Doing, Articulating
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
Some people learn by doing. Some people (like me) learn by reading. I've been doing C++ for a long time, but I would say that I learned it by reading the C/C++ Users Journal and various books and other documentation. The parts of C++ that I learned "by doing" have to do with compiler limitations and library bugs.
While the syntax and usage of a C++ is a fairly limited set of knowledge; good object-oriented design is much less limited. No set of books can cover everything, particularly not the compromises that often occur in real-world projects. So I've been learning OO by doing as well as by reading.
The third stage is taking the implicit / tacit knowledge acquired by doing, and articulating it. Not just to teach other people, nor to prove to others that you've acquired this knowledge, but to examine and re-examine what you think you know.
When asked questions about object-oriented design, I sometimes find it difficult to articulate everything that could or should be said... not because I don't know it, but often because something is so obvious to me that I would not think that I would need to mention that aspect.
For example, many people avoid multiple-inheritance in C++, but when asked why, they just say it's "bad" or "dangerous". While there can be problems with "diamond" inheritance (where multiple parents of a class have a common parent), multiple inheritance isn't all bad. Being able to "mix-in" Observer/Observable functionality into specific "child" classes in your class hierarchy might be an appropriate use of multiple inheritance. An aspect of multiple-inheritance that I would consider too obvious to mention (but I'll mention here) is that it can't be changed at run-time... it's inflexible (and 'abusive' to the concept) if you're trying to use inheritance to implement aggregation. You're not going to decide at run-time whether to add Observable behavior to some object, but you may want to change or add other behaviors at run-time: appropriate patterns for that would be Decorator, Composite, Delegation, Strategy, etc...
Because not everyone is at the "articulating" stage of knowledge, use auditions to evaluate programmers: pair-design and pair-program with the candidate on real-world problems, for example, keeping in mind that really good insights on various problems will take more than an hour or two...
Previous Topic
