UMLs were developed as architectural tools for Object Oriented Design (OOD). Like a blueprint for building a house, a UML diagram is an aid and nothing more. The more detailed a UML, the easier it is to build a program because it tells you what goes where. So, a rudimentary UML is better than none at all. (The ones I sketch on the back of used daily calendar pages are definitely rudimentary.)

You also brought up our old friend perfection in reference to flawless UMLs. Remember that seeking perfection is like going after the Holy Grail—an impossible and even foolhardy task because you’ll never achieve it. On the other hand, excellence is a process whereby you seek out improvement incrementally. The more you do it, the better you get at it. (That’s why I’m using discarded calendar pages instead of pulling brand new paper out of my laster printer! I need to get better at the process first.)

Working out an operation prior to encapsulating it is hardly a sin! However, encapsulating operations is the essence of OOP. Further, unit-testing is another essential step in building a real-world application, and so as a developer builds a program, he wants to make sure that all of the pieces (objects) are working prior to putting them all together. So it seems to me that you’re involved in a type of unit-testing prior to encapsulation. In game development (as you well know) virtually all objects interact with other objects. As a result, you probably need to know which objects should be unit-tested with other objects and see if the objects work as expected and interact as expected. To interact, they need some form of encapsulation so that they are tested as objects and not solely as operations. Your technique seems to involve an extra step, but there’s nothing wrong with that. As you get better, you won’t have to work as hard!

Kindest regards,
Bill

I personally don’t think many people out there can code in such an encapsulated manor straight off the bat. It would require a very seasoned coder who can churn out flawless UML.

Remember to separate what varies from what stays the same and encapsulate what varies.

Take care,
Bill

very great to encapsule the code, or change it after.

It just went up this morning; so it’ll take a while for folks on this list to respond. So many people just develop with a single giant class because that’s what they’re used to and it feels safe. I hope that little by little people try programming with some of these principles–they really do work! When I was developing examples for this post, it was super easy to make changes.

As an alternative to either a Flowchart or a Class Diagram, maybe a “Responsibility Chart” would be the way to develop!

Kindest regards,
Bill