I'll bite. - Ouch!
OS kernels
Device drivers
Image processing
Genetics applications
Natural language processing
Cryptography
All of these can be, and I believe have been, successfully analysed and designed using OOD techniques. Examples:
- The Mach Kernel
Mach provides a small set of abstractions that have been designed to be both simple and powerful.
- Devices as Objects
Devices make good objects. Programmers seem to understand and respond well to this technique. As an example, a uCR library includes classes for communicating with a host through a PCI bus.
- GD
1. To create a new, empty image, send a new() message to GD::Image, passing it the width and height of the image you want to create. An image object will be returned.
- bioperl;
Bioperl Bio::Root::Root Object
All objects in Bioperl (but for interfaces) inherit from the Bio::Root::Root.
That leaves
Quickie sys-admin scripts
Good design takes time. Quickies are rarely well designed, they simply get the job done, but if the quickie need to be frequently re-used with small changes...
Would you care to state examples that are intractable to non-OO solutions?
Math.
When you invoke the 'add' method (often overloaded to the symbol '+') on a variable (object) that happens to be an integer, the cpu processes that operation as an integer. If the object that is the subject of that method happens to be a IEEE representation of a floating point value, then the cpu hands that method off to a math co-processor. Try 'add' on a string and you'll get an exception. This is true, regardless of the processor or the language used.
Some languages happen to overload the symbol '+' to perform a concatenation operation on a string, and that too is a OO concept (overloading). However, as was pointed out in these halls not too long ago, that is a pretty bad idea. The semantics of concatenation and those of numeric addition are completely different. 1 + 3 and 3 + 1 are commutative, but "foo" concat "bar" and "bar" concat "foo" are not.
This battle of wits you propose would be a two way street.
As I tried to indicate in my post, I was simply looking for good, well-defined examples of problems that are, or seem to be intractable to OOD, purely for research purposes.
Too many OOD books and courses concentrate on design problems, often concocted or artificially simplified, that naturally lend themselves to OOD. If your going to explore the real benefits (or otherwise) of a subject, it is better to start with difficult examples. If you can solve the difficult ones and show benefits, then the easy natural ones speak for themselves. This was the purpose of my request.
| [reply]
[d/l] |
I would say most business/databasebase applications are not well modelled
by OOD. That does not say such apps are intractable or even difficult to do
in OO, just that contrary to popular wisdom and some large investment in OO
languages for business applications, people are still left groping for a
better way to model such applications.
| [reply] |
I think I understand where your coming from on this. The problems with making OO work with database applications are fairly well documented and have been the subject of a discussion here quite recently.
To be really useful (to me), the problems need to be fairly clearly defined, specific examples. Preferably with an indication of what problems where encountered in modelling them using an OO regime.
| [reply] |
| [reply] |