A style of design in which work starts from and goes back to how the design looks in its use. Definitely affects naming, but also affects the class partitioning at the interface to the client. Used by some people but documented nowhere to my knowledge.
is a development technique, or development attitude, which says that how the designed interface appears in its use in the client code is very important. Therefore, the function names are chosen to appear "natural" when used, and the class partitioning may change so that the class.function appearance again is "natural" to the user of the classes. I once gave an award certificate to a person who had developed a knack for developing his classes this way. They were always a pleasure to use, and their internal design was also sound. That award was to distinguish this person's design style from the other two people who got certificates, one for Programming As Theory Building (PeterNaur
's wonderful term), and the other for Designing With Responsibilities. Their code and classes all looked good, and different. --AlistairCockburn
I find this related to some of the discussion in DesignByContract
, and maybe ComponentOrientedDesign?
. (I think I mentioned this in TypesAreContracts
, but) as a HumanFactors
guy, I tend to think in this way; I frame design problems in terms of how my APIs and component interfaces "look". i.e. what it will be like for the other programmers to write client code against my interface. I'm glad to see I'm not the first person in the world to think this is a good idea. -- RusHeywood
This sometimes falls out naturally from CodeUnitTestFirst
. -- DaveHarris
Not wanting to turn this into an XP page, but it seems to me that CrcCard
s and ResponsibilityDrivenDesign
lead us in the direction of DesignFromTheClientSide
. The focus on the messages we can send an object from the outside seems naturally to support ClientFocusedDesign?
, or should I say DesignForUse?
also pushes us towards IntentionRevealingMessages?