Topic: object-oriented design

topics > computer science > programming > Group: program design

database model
program design
object-oriented programming

declarative vs. procedural representation
design documentation
design for change
design pattern
entity-relationship database model
identifying program modules
information hiding
object-oriented classes
object-oriented modelling language
object-oriented packages
software models of reality
stepwise refinement
the 'uses' hierarchy for organizing systems
type hierarchy
types of object-oriented classes

Subtopic: top-level design up

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

Subtopic: abstraction levels up

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]

Subtopic: application framework up

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

Subtopic: inheritance vs. membership up

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]

Subtopic: procedures vs. objects up

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)

Subtopic: objects vs. events up

Quote: describe objects in terms of the module that creates them
Quote: describe modules by the observable event sequences (traces) at their interface

Subtopic: decomposition, aggregation up

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]

Subtopic: family resemblance up

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

Subtopic: Law of Demeter up

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]

Subtopic: class, object, base class, template up

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

Subtopic: problems with object-oriented design up

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

Related Topics up

Group: database model   (15 topics, 316 quotes)
Group: program design   (13 topics, 454 quotes)
Group: object-oriented programming   (26 topics, 822 quotes)

Topic: abstraction (62 items)
Topic: classification (65 items)
Topic: declarative vs. procedural representation (54 items)
Topic: design documentation (43 items)
Topic: design for change (76 items)
Topic: design pattern (17 items)
Topic: entity-relationship database model (22 items)
Topic: identifying program modules (26 items)
Topic: information hiding (50 items)
Topic: object-oriented classes (67 items)
Topic: object-oriented modelling language (6 items)
Topic: object-oriented packages (6 items)
Topic: software models of reality (24 items)
Topic: stepwise refinement (25 items)
Topic: the 'uses' hierarchy for organizing systems (18 items)
Topic: type hierarchy (18 items)
Topic: types of object-oriented classes
(18 items)

Updated barberCB 3/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.