Quote: use a consensus-driven process to design a vocabulary and a good enough class hierarchy; no optimum classification [»taivA11_1997]

Quote: need experience on the problem domain before designing the generic, more abstract classes

Quote: all operations of a class should support the same level of abstraction; e.g., separate operations on file descriptors from operations on file names [»stroB_1991]

Quote: unnecessary functions in a class constrain the system's evolution [»stroB_1991]

Quote: an application framework defines a complete application without content; the programmer supplies application-specific code as building blocks [»stroB_1991]

Quote: use inheritance ("D is a kind of B") for well-defined relationships and membership ("D has a B") whenever multiple members are possible [»stroB_1991]

Quote: design for inheritance or prohibit it; inheritance commits forever design decisions about usage, protected methods, and other aspects of a class' inner workings [»blocJ_2001]

Quote: the procedure-oriented and object-oriented views of programming are fundamentally different for both design and implementation [»stroB_1991]

Quote: you can not simultaneously focus a design on both the entities and their actions

Quote: movement sequences (actions) typically involve an object; the object ties the movements into meaningful chains; e.g., cooking an egg [»bernNA_1947]

Quote: do not query an object, make a decision, and perform an action (procedural, bug prone) [»huntA1_2003]

Quote: tell objects what needs to be done, keep decisions inside objects (object-oriented, encapsulated)

Quote: describe objects in terms of the module that creates them

Quote: describe modules by the observable event sequences (traces) at their interface

Quote: subject-oriented programming--decompose design into design subjects, one per requirement; model each subject with an object-oriented design language; may overlap [»clarS11_1999]

Quote: with objects, decompose software into virtual machines that describe both data and its behavior; like real-world entities [»coxBJ1_1983]

Quote: object-oriented languages support aggregation/decomposition by using an object as a variable of another object [»taivA9_1996]

Quote: Kevo uses family resemblance instead of explicitly sharing object representations [»taivA11_1997]

Quote: avoid talking to more objects than necessary; protects against change; e.g., Law of Demeter [»huntA1_2003]

Quote: Law of Demeter prohibits calls to returned objects; leads to many small wrapper functions

Quote: reduce class dependencies by following the Law of Demeter; restrict message-sending to arguments, self, and self's components [»liebKJ9_1989]

Quote: relax the Law of Demeter by declaring acquaintance classes; documents dependencies [»liebKJ9_1989]

Quote: Law of Demeter reduces method complexity and nested message sending; increases number of messages and their arguments [»liebKJ9_1989]

Quote: represent a separate idea as a class; a separate entity as an object; commonality between classes as a base class; and a container of objects as a template

Quote: object-oriented design limited: too large, limited reuse, too specialized, does not match requirements [»clarS11_1999]

Quote: basic classes occur in the middle of the class hierarchy but object-oriented class design proceeds from top to bottom [»taivA11_1997]

Quote: UML and other object-oriented design languages align well with code and poorly with requirements [»clarS11_1999]

Quote: design by functional decomposition aligns poorly with object-oriented code [»clarS11_1999]

Quote: problem of scattering--a simple requirements change causes widespread change across the class hierarchy [»clarS11_1999]

Quote: when graphical tools become popular, a new programming paradigm makes them obsolete; e.g., flowcharts and structured programming; UML may indicate a paradigm shift [»soukJ8_2007]