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:
Mach provides a small set of abstractions that have been designed to be both simple and powerful.
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.
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 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.
In reply to Re: Re: Re: Re: (OT) Terminology Oriented Programming
by Anonymous Monk
in thread (OT) Terminology Oriented Programming
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |