Re: OOP/OOD Philosophy

A number of observations come to mind in this discussion.

First that the word object is a conceptual framework of meanings in
Computer Science.

Software design objects are a family of concepts often complemented by
an iconic notation. The notation is used to experiment with and refine
software designs. The design of an information model uses different
families of objects than functional designs use and so on.

Different from this is OOP and OOP notations. These notations,
although overlapping with design, are largely inventories of
programming components and their particulars.

Not all Computer Scientists are successful with design objects. To be
successful, the individual using them must be able to think in very
abstract ways. Not everyone can and even when they can, corporate
policy and practice often make the effort impossible.

This frustrating truth is largely responsible for the Extreme
*whathaveyou-usually-Programming* phenomenons. With a straight face,
these proponents assert that if design is not egalitarian and if
companies don't respect it then -snip, snip- out with it except for
perfunctory lip-service.

One cannot glibly 'think' in OOD, there isn't any such thing. OOD is
very hard work, time-consuming, expensive and easy to derail (just have
bottom-up activity happening in the background that pre-empts the
designers).

Another common mistake is the literalization of the word 'procedural'
as an either/or alternative to OOP. OOP is equally procedural as a
temporal phenomenon. The consecutive operations are bundled
differently and obviously have their own mechanics.

Architecture is a whole other related subject. Again, design
discussions having to do with architecture too easily get entangled in
OOD and programming quagmires. Architects often have to spoon feed and
baby talk their way through corporate conversations.

The theory for all of this is the theory of language, the use of iconic
notations to conceptually talk about and build very complex software
frameworks with (generally speaking). Pholosophy is coincidental.

.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... >> Not all Computer Scientists are successful with design objects. ... I don't think deep abstraction is necessary either but the ability to ... methodology or tool exists - except maybe dance lessons. ...
    (comp.object)
  • Re: requirement engineering versus analysis
    ... > purpose of requirement engineering is to produce the specification? ... Whether the cycle scale is at the level of a code fragment (< 200 ... > analysis, design, coding, testing. ... software construction and the /methodology/ of software design. ...
    (comp.object)
  • Re: Software design and development
    ... > Software design and development ... building tools for developers, ... > I know a lot of technologies and tools. ...
    (comp.lang.java.programmer)
  • Software vs Hardware productivity (was: Re: Clause "with and use")
    ... that's just a matter of "features" if you will. ... bigger and that probably means they take more time to design than ... There just is no fair comparison of software design to hardware design ... That's no different than a memory chip designer taking credit ...
    (comp.lang.ada)
  • Re: A family of function application operators for Standard ML
    ... > easier to read (than the general pattern above). ... I want to commend this design of notation; I can see the designer has ... I am doubtful of any doubt to new notations if the doubt appeals to ... slippery slope in a functional programming newsgroup in a world full ...
    (comp.lang.functional)