This is taken from the General forum at the request of oaksoft. I've collated my arguments from all the posts below:
Quote:
--------------------------------------------------------------------------------
Niall, could you explain your reasoning behind your OO flawed comment. Being a relative newbie to the OO world I would find the observations of someone like you interesting.
--------------------------------------------------------------------------------
Sure.
My main problem with OO is mostly how it is presented. It is usually presented to novices as the pinnacle of software design that should be used wherever possible, and thus ignoring that often it is a sub-optimal method of design. Let me give you an example.
In pure OO design, everything is represented by some kind of object and the program is a set of inter-related objects. Objects are conceptualised, designed and named in human terms eg; a button, a window, a file etc. Mostly, what is to the human is also to the computer because a lot of these objects are human-convenience abstractions.
However, what is convenient to a human is often not to a computer. Inefficiencies multiply as layer upon layer of abstraction is forced against the natural way of functioning of a computer. Thus, as any CS student or teacher knows, a naive approach to OO design in purely human terms runs terribly inefficiently - often unusably so.
In fact, one could say that the experienced OO designer has learned where to depart from pure OO in order to write working code. The more experience they have, the more subtle and complex departures from "correct" OO they do. And best of all, 90% of experienced OO designers don't even realise they do this.
I prefer to look at OO as a limited tool. In many places true it is the optimal solution. In many others, a functional approach is better. In still others, one might find procedural code the best. My point is, OO is not some uber-technology - its optimal usage is much more limited and the optimal design combines OO with many other design techniques at once.
Indeed, this is why I often say you should view OO as a format for conveniently laying out your code in a maintainable fashion. I write my assembler in an OO format for maintainence and extensibility, and before I read any snide comments on this I suggest you go read my assembler before you do (look at NedHAL). It has constructors, destructors, instance data etc.
Obviously, not using a uniform OO design methodology comes with a price - mostly that other programmers get confused when working with your code. Depending on your environment, it may in people-cost terms be better to use pure OO all the way through. However, I would argue that in many projects, any newbie OO engineer will have the same problems with OO code written by a very experienced engineer - for precisely the reasons listed above.
Lastly, I'll give an example of some coursework my class had to do during my compsci degree. It was to write a program which read from one large file and spat records into three or four other files based record content. The typical class effort took between twenty and thirty seconds to complete, whereas mine took less than half a second. The difference? They used a pure absolutely correct OO design whereas I tailored mine (ie; broke purity) to how the computer actually works.
And that, in a very small nutshell, is why I think OO is flawed. Not in itself inherently, but in how it is presented, used and marketed.
--- cut ---
XML is flawed because it's OO, and thus my previous explanation about the flaws in OO apply.
Furthermore, it is built on top of existing paradigms without renovating them, requires a large and complex decoding engine (already a sign of something wrong with it eg; SGML) and does nothing to prevent introduction of incompatible tags (eg; like how Netscape kept extending HTML to stop sites being compatible with anything except their browser). While it's a useful technology which certainly makes some things much easier, Tornado is a completely different beast.
--- cut ---
I don't know much about web services, but I still hold that XML uses an OO approach. To work with XML, you use a DOM and it's most certainly OO in every implementation I've seen. It also has all the problems I've mentioned in previous posts, and I don't see it being the technology to link disperate code together. Why? Further problems I see is its text-based format (unsuitable for high-performance areas), lack of flexibility in encoding (much more code needed, inefficient, can have difficulty encoding exotic formats) and lack of power in the model itself (it could do with being programmable ie; scripting).
--- cut ---
Perhaps you already view my position as being absolutely correct and thus can't see the point I'm making? My point is that there is a myriad of approaches and instead of us trying to impose one over all others (eg; MS .NET, Corba) we should be aiming for a truly agnostic method of joining bits of code together. Tornado is my version of that agnostic approach, where solutions written with any variety of approaches work equally hand-in-hand with one another.
Basically, I propose making all code modular and reusable to a tiny grain (eg; a module to generate random passwords, or a module generating the current date etc) and linking them together in a far more generic fashion than OO. This is obviously like .NET or Corba, but they're based around objects whereas Tornado is not - it's based around processors of data with their inputs and outputs connected by streams of data. This has elements of UML clearly but more in its abstract sense as all UML implementations that I know of are OO.
One clear difference in Tornado is that there is no fixed API at all between the "objects" nor any fixed naming of "objects" (eg; you don't have to specify which data processor, the system allocates you one most of the time - thus permitting complete substitutability of data processors).
Comments?
Cheers,
Niall
Quote:
--------------------------------------------------------------------------------
Niall, could you explain your reasoning behind your OO flawed comment. Being a relative newbie to the OO world I would find the observations of someone like you interesting.
--------------------------------------------------------------------------------
Sure.
My main problem with OO is mostly how it is presented. It is usually presented to novices as the pinnacle of software design that should be used wherever possible, and thus ignoring that often it is a sub-optimal method of design. Let me give you an example.
In pure OO design, everything is represented by some kind of object and the program is a set of inter-related objects. Objects are conceptualised, designed and named in human terms eg; a button, a window, a file etc. Mostly, what is to the human is also to the computer because a lot of these objects are human-convenience abstractions.
However, what is convenient to a human is often not to a computer. Inefficiencies multiply as layer upon layer of abstraction is forced against the natural way of functioning of a computer. Thus, as any CS student or teacher knows, a naive approach to OO design in purely human terms runs terribly inefficiently - often unusably so.
In fact, one could say that the experienced OO designer has learned where to depart from pure OO in order to write working code. The more experience they have, the more subtle and complex departures from "correct" OO they do. And best of all, 90% of experienced OO designers don't even realise they do this.
I prefer to look at OO as a limited tool. In many places true it is the optimal solution. In many others, a functional approach is better. In still others, one might find procedural code the best. My point is, OO is not some uber-technology - its optimal usage is much more limited and the optimal design combines OO with many other design techniques at once.
Indeed, this is why I often say you should view OO as a format for conveniently laying out your code in a maintainable fashion. I write my assembler in an OO format for maintainence and extensibility, and before I read any snide comments on this I suggest you go read my assembler before you do (look at NedHAL). It has constructors, destructors, instance data etc.
Obviously, not using a uniform OO design methodology comes with a price - mostly that other programmers get confused when working with your code. Depending on your environment, it may in people-cost terms be better to use pure OO all the way through. However, I would argue that in many projects, any newbie OO engineer will have the same problems with OO code written by a very experienced engineer - for precisely the reasons listed above.
Lastly, I'll give an example of some coursework my class had to do during my compsci degree. It was to write a program which read from one large file and spat records into three or four other files based record content. The typical class effort took between twenty and thirty seconds to complete, whereas mine took less than half a second. The difference? They used a pure absolutely correct OO design whereas I tailored mine (ie; broke purity) to how the computer actually works.
And that, in a very small nutshell, is why I think OO is flawed. Not in itself inherently, but in how it is presented, used and marketed.
--- cut ---
XML is flawed because it's OO, and thus my previous explanation about the flaws in OO apply.
Furthermore, it is built on top of existing paradigms without renovating them, requires a large and complex decoding engine (already a sign of something wrong with it eg; SGML) and does nothing to prevent introduction of incompatible tags (eg; like how Netscape kept extending HTML to stop sites being compatible with anything except their browser). While it's a useful technology which certainly makes some things much easier, Tornado is a completely different beast.
--- cut ---
I don't know much about web services, but I still hold that XML uses an OO approach. To work with XML, you use a DOM and it's most certainly OO in every implementation I've seen. It also has all the problems I've mentioned in previous posts, and I don't see it being the technology to link disperate code together. Why? Further problems I see is its text-based format (unsuitable for high-performance areas), lack of flexibility in encoding (much more code needed, inefficient, can have difficulty encoding exotic formats) and lack of power in the model itself (it could do with being programmable ie; scripting).
--- cut ---
Perhaps you already view my position as being absolutely correct and thus can't see the point I'm making? My point is that there is a myriad of approaches and instead of us trying to impose one over all others (eg; MS .NET, Corba) we should be aiming for a truly agnostic method of joining bits of code together. Tornado is my version of that agnostic approach, where solutions written with any variety of approaches work equally hand-in-hand with one another.
I can't find the relevant post on your suggestion for a solution to the problems of OO.
One clear difference in Tornado is that there is no fixed API at all between the "objects" nor any fixed naming of "objects" (eg; you don't have to specify which data processor, the system allocates you one most of the time - thus permitting complete substitutability of data processors).
Comments?
Cheers,
Niall
Comment