Report Offensive Message
Good idea - badly done
I voted no because in concept it is not, but in practice... well we have horrible languages like C++ combined with non-agile diagrams like UML.
OO really dates back to the 1950s when some smart guy at Burroughs put code to interpret data together on a tape on the B220 system. Alan Kay picked up on this (and later coined the term object oriented).
The first real OO language was Simula by Dahl and Nygaard, being an extension of ALGOL (that immediately makes it far better than C++... ALGOL was done by many people including John Backus who developed FORTRAN. They carefully avoided the pitfalls of FORTRAN, gave .EQ. the neater mathematical '=', and assignment ':='. C forgot these lessons and put FORTRAN's junk back in, since programmers believed that "confusion of concept = efficient code", and anything with clean concepts must be "training wheels for idiots", an attitude which I think is finally dying).
Fundamental to OO is the concept of modularization based on a 1970 CACM paper by David Parnas. Parnas has since pointed out that modularization is important, but more so is the design of modules, that is the interfaces between them. Parnas coined the term 'information hiding', which many simplistically interpret as meaning get and set routines, but really I think Parnas meant 'implementation hiding' and hiding of certain assumptions to ensure loose coupling. Interfaces should be designed so modules go together like a tight-fitting jigsaw puzzle, but loosely coupled at the same time. The test is that a completely different module should be able to replace another module and the system still works.
http://sunnyday.mit.edu/16.355/parnas-criteria.html
http://www-sst.informatik.tu-cottbus.de/~db/doc/People/Broy/Software-Pioneers/Parnas_new.pdf
Parnas says OO has really been a disaster since many believe they are writing good code by just writing in an OO language.
Later the concept of Design by Contract (DbC) was developed and put in the Eiffel language by Bertrand Meyer. Along with Smalltalk, Eiffel is at the pinnacle of OO languages, but DbC is an important concept to specify clean module interfaces. Most class interfaces just express the static properties of a module, what routines exists and parameters and results are expected. DbC extends this to the dynamic properties of a class, what are the valid states and refine further the domains of parameters and results.
DbC is Test-Driven Development (TDD) on steroids. TDD results in rather random tests separate from a module from which a module is then developed. However, DbC says this is an essential part of a module's specification, and automatically provides testing. All you need is then a small test harness. Thus essential parts of a module specification are in the module itself, not in a separate test module as with TDD.
Some think that OO design is doing UML diagrams. UML is just too heavy and too light at the same time. It is too heavy for most development. It really is against agile development. But it is too light, it is not formal enough for serious and critical development (despite the fact it looks serious).
That is where DbC is just right. It is built into a programming language (Eiffel) and can be used (with a little or more effort) in other languages. DbC says that a program written in an executable language IS your specification document. That is really agile.
Using the jigsaw analogy, most static interface design is like having the pieces fit together, but there is no check that the resulting picture makes sense. DbC helps make sure the resultant picture also makes sense and this is a very important aspect that most development techniques ignore.
So DbC is light and agile.
However, DbC is also formal. It formally captures exactly what the interaction between modules should do. It is based on formal concepts like Z, and Hoare logic {P} S {R} (if precondition P is met, after code S is executed, result R will hold).
So if I consider technologies like C++ and UML I would vote yes OO is too complicated, but OO well done with better languages and DbC with the original thinking of David Parnas makes me vote no.
OO really dates back to the 1950s when some smart guy at Burroughs put code to interpret data together on a tape on the B220 system. Alan Kay picked up on this (and later coined the term object oriented).
The first real OO language was Simula by Dahl and Nygaard, being an extension of ALGOL (that immediately makes it far better than C++... ALGOL was done by many people including John Backus who developed FORTRAN. They carefully avoided the pitfalls of FORTRAN, gave .EQ. the neater mathematical '=', and assignment ':='. C forgot these lessons and put FORTRAN's junk back in, since programmers believed that "confusion of concept = efficient code", and anything with clean concepts must be "training wheels for idiots", an attitude which I think is finally dying).
Fundamental to OO is the concept of modularization based on a 1970 CACM paper by David Parnas. Parnas has since pointed out that modularization is important, but more so is the design of modules, that is the interfaces between them. Parnas coined the term 'information hiding', which many simplistically interpret as meaning get and set routines, but really I think Parnas meant 'implementation hiding' and hiding of certain assumptions to ensure loose coupling. Interfaces should be designed so modules go together like a tight-fitting jigsaw puzzle, but loosely coupled at the same time. The test is that a completely different module should be able to replace another module and the system still works.
http://sunnyday.mit.edu/16.355/parnas-criteria.html
http://www-sst.informatik.tu-cottbus.de/~db/doc/People/Broy/Software-Pioneers/Parnas_new.pdf
Parnas says OO has really been a disaster since many believe they are writing good code by just writing in an OO language.
Later the concept of Design by Contract (DbC) was developed and put in the Eiffel language by Bertrand Meyer. Along with Smalltalk, Eiffel is at the pinnacle of OO languages, but DbC is an important concept to specify clean module interfaces. Most class interfaces just express the static properties of a module, what routines exists and parameters and results are expected. DbC extends this to the dynamic properties of a class, what are the valid states and refine further the domains of parameters and results.
DbC is Test-Driven Development (TDD) on steroids. TDD results in rather random tests separate from a module from which a module is then developed. However, DbC says this is an essential part of a module's specification, and automatically provides testing. All you need is then a small test harness. Thus essential parts of a module specification are in the module itself, not in a separate test module as with TDD.
Some think that OO design is doing UML diagrams. UML is just too heavy and too light at the same time. It is too heavy for most development. It really is against agile development. But it is too light, it is not formal enough for serious and critical development (despite the fact it looks serious).
That is where DbC is just right. It is built into a programming language (Eiffel) and can be used (with a little or more effort) in other languages. DbC says that a program written in an executable language IS your specification document. That is really agile.
Using the jigsaw analogy, most static interface design is like having the pieces fit together, but there is no check that the resulting picture makes sense. DbC helps make sure the resultant picture also makes sense and this is a very important aspect that most development techniques ignore.
So DbC is light and agile.
However, DbC is also formal. It formally captures exactly what the interaction between modules should do. It is based on formal concepts like Z, and Hoare logic {P} S {R} (if precondition P is met, after code S is executed, result R will hold).
So if I consider technologies like C++ and UML I would vote yes OO is too complicated, but OO well done with better languages and DbC with the original thinking of David Parnas makes me vote no.
Posted by Ian Joyner
25th Oct
