 |
|
| |
|
|
|
|
|
Software componentry - Differences from object-oriented programming | | Software componentry - Differences from object-oriented programming: Encyclopedia II - Software componentry - Differences from object-oriented programming | | The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented design and object-oriented analysis focus on modelling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways, ideally by end users as well as by programmers coding for those end users.
Software componentry, by contrast, makes no such assumptions, and instead states that software ...
See also:Software componentry, Software componentry - Software component, Software componentry - History, Software componentry - Differences from object-oriented programming, Software componentry - Architecture, Software componentry - Technologies, Software componentry - Literature | | | Software componentry, Software componentry - Architecture, Software componentry - Differences from object-oriented programming, Software componentry - History, Software componentry - Literature, Software componentry - Software component, Software componentry - Technologies, Business logic, Web Service, Third party software component | | |
| | | Software componentry: Encyclopedia II - Software componentry - Differences from object-oriented programming
Software componentry - Differences from object-oriented programming
The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-oriented design and object-oriented analysis focus on modelling real-world interactions and attempting to create 'verbs' and 'nouns' which can be used in intuitive ways, ideally by end users as well as by programmers coding for those end users.
Software componentry, by contrast, makes no such assumptions, and instead states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics. It accepts that the definitions of useful components, unlike objects, can be counter-intuitive. In general it discourages anthropomorphism and naming, and is far more pessimistic about the potential for end user programming. Some peers will even talk of software components in terms of a new programming paradigm: component-oriented programming.
Some argue that this distinction was made by earlier computer scientists, with Donald Knuth's theory of "literate programming" optimistically assuming there was convergence between intuitive and formal models, and Edsger Dijkstra's theory in the article The Cruelty of Really Teaching Computer Science, which stated that programming was simply, and only, a branch of mathematics.
In both forms, this notion has led to many academic debates about the pros and cons of the two approaches and possible strategies for uniting the two. Some consider them not really competitors, but only descriptions of the same problem from two different points of view.
It takes significant effort and awareness to write a software component that is effectively reusable. The component needs:
- to be fully documented;
- more thorough testing;
- robust input validity checking;
- to pass back useful error messages as appropriate;
- to be built with an awareness that it will be put to unforeseen uses
- a mechanism for compensating developers who invest the (substantial) effort implied above.
Other related archives.NET, 1968, 1986, 9P, Bonobo, Borland, Brad Cox, Business logic, Business object, CLX, COM, CORBA, CORBA Component Model, Compound document, D-BUS, DCOM, DCOP, Distributed computing, Donald Knuth, Douglas McIlroy, Edsger Dijkstra, Eiffel programming language, Encapsulated, Enterprise Java Beans, Fresco, GNOME, Garmisch, Germany, IBM, IDL, Inferno, J2EE, Java Beans, KDE, LCL, Microsoft, Mozilla Foundation, NATO, Newi, OCX/ActiveX/COM, OLE, Oberon programming language, Object Management Group, Object Oriented Programming, Object linking and embedding, Objective C programming language, Open Service Interface Definitions, OpenDoc, OpenOffice.org, Plan 9, REST, SOAP, SOM, Stepstone, Sun, Sun Microsystems, The Cruelty of Really Teaching Computer Science, Third party software component, UNO, Universal Network Objects, Unix, VBX, VCL, W3C, WDDX, Web Service, Web Services, XML-RPC, XPCOM, anthropomorphism, application server, bitstream, component, components, computer, computer scientists, distributed computing, electronics, error messages, freedesktop.org, inter-process communication, interface description language, literate programming, mathematics, mechanics, object-oriented analysis, object-oriented design, object-oriented programming, objects, operating system, paradigm, pipes and filters, serialization, software, software architectures, software crisis, software design patterns, software engineering, software frameworks, software objects, technology
 Adapted from the Wikipedia article "Differences from object-oriented programming", under the G.N U Free Docmentation License. Please also see http://en.wikipedia.org/wiki |
|
|
|
More material related to Software Componentry can be found here:
|
|
|
« Back
|
Search the Global Oneness web site |
|
|
|
|
|
|
