I will agree that OOP seems to have some slight advantages when it comes to things that can be easily viewed as relatively simple "device drivers". Specific GUI widgets may be such a case. However, I have not found a way to view everything as a convenient device driver. Many things in custom business applications are simply too interrelated and have constantly-changing "interfaces".
Your use of the term "device driver" borders on EquivocationFallacy, top. On one hand, it includes lots of things (such as GUI widgets), usually not considered to be "device drivers" by the programming community. OTOH, the fact that you use this particular term, generally associated with low-level programs to control hardware, suggests an implication that these sorts of tasks (where a RelationalDatabase would be clearly inappropriate) are somehow "lesser" than, say, OnLineTransactionProcessing? or other "business" applications. (This is an unfortunate prejudice that exists in much of the programming community, as systems programming is both essential and honorable, but it exists).
- And in fact we're an elite. I was not aware of this negative prejudice. Systems programmers are like the Special Forces in the military, doing dangerous, dirty, messy, extremely difficult work; granted, ordinary people don't want to do this sort of thing -- you have to be a little crazy to be interested -- but which is essential, and that the average soldier/programmer actually is incapable of doing. The rigors of device driver bootcamp leave all but the toughest of application programmers fleeing back to their report generators. -- dm
- Certainly, the prejudice is undeserved.... but I have observed.
- I did not mean to imply a social worth hierarchy. For low-level programming indeed does require a lot of skill. I am trying to characterize software patterns, not human pay levels. As far as the fuzziness of the term, I generally mean that GUI components *resemble* device drivers, not that they are device drivers. Nor do I necessarily think that systems programming is about devices, except maybe at the lower levels.
- Resembles in what sense? We need to clear this up ASAP; "device drivers" is incorrect terminology.
- One can view it as a relatively independent little machine with a clear-cut interface. Note that there may be virtual devices and actual devices. GUI widgets are often purposely made to resemble physical controls on control panels, for example. A precise definition? I'll have to think about that one. You are welcome to offer candidates.
- DeviceDrivers are not (in general) about controls, virtual or otherwise. (Though there probably is a device driver which interfaces with the control hardware; the important thing is that drivers are about hardware). Unless you have a widget that renders directly to a frame buffer (something you will not find in most modern environments), it has little to do with device drivers. Most widgets interact with a lower-level UI toolkit, several levels in the SW stack above the actual display hardware.
You ought to be clear as to what you mean by a DeviceDriver. If by that you mean systems programming; then your assertion that the RelationalModel is inappropriate only for "device drivers" is demonstrably incorrect. If, on the other hand, a "device driver" is defined as "something that a RelationalDatabase is inappropriate for", then your claim is a tautology and therefore vacuous.
Please elaborate.
Attempts to make entity-based device-driver things just don't seem to capture the same simplicity of a simple device driver. For example, it does not seem to work out well to make an "Invoice" device, a "Customer" device, etc.
You can erect a better StrawMan than that. Nobody, outside of you, would ever suggest that invoices, customers, and such are "devices".
- Some have characterized OO as "making little independent machines". Keep in mind that NobodyAgreesOnWhatOoIs. If you disagree with the "little machine" view, then perhaps you are not the target audience.
- While nobody agrees on what OO is, there is a common subset that has widespread agreement. And it's not about "device drivers"; use of OO to implement device drivers is a recent phenomenon.
- Perhaps if we identify this "common subset", then we can see if there is not a better term than "device driver". Some have called objects and object design as "building little machines".
Business rules are just too interweaving and interrelated to isolate behind clean, stable interfaces. Which "noun" behavior belongs with becomes rather arbitrary. It may change over the course of a project. For example, discounts may be based on where the customer lives one year, and then changed to reflect purchasing history the next. Thus, attaching discounts to Customer is in vain. Plus, there is often no need to reuse entity-specific behavior between different applications/projects. They are very specific to a given need.
- Many OO practitioners can deal with "rules" belonging to more than one noun just fine. Even in an EverythingIsanObject language, this isn't a big problem. The big problem that you raise is dealing with change and SchemaEvolution; which isn't easy to deal with in any paradigm.
A device-driver viewpoint tends to only work when these conditions are true:
What is a "device-driver viewpoint"? I'm not aware of any such paradigm. If you want to make claims about OO, say OO. For what it's worth; OO is most decidedly not usable only under the following constraints.
- Relatively small or simple interface
- Interface is relatively stable. Changes are mostly additions instead of rearrangements.
- Will need to be reused multiple times
- Features or implementation not likely to be moved from driver to driver.
- Little or no inter-driver coordination is needed.
- Little or no need to study or change the internal state besides what the interface provides.
-- top
Have you ever written device drivers, top? You seem to have several misconceptions about them. What environment did you write them in?
In an informal sense I did a fair amount with pre-Windows printers. But generally I am talking about TextbookOo-like examples. RobertCecilMartin has some examples on his website.
The sort of OO that is found in textbooks ought not be considered a representative sample of real-world problems. Just because some textbook has toy examples, that doesn't mean that more difficult (and more RealWorld) problems are somehow out of reach.
[Since whatever you want to talk about seems to revolve around this, and we apparently haven't seen the kinds of examples you have in mind, would you please provide a more specific pointer, so that we can all talk about the same thing. I wandered around "his website" (may or may not be the one you meant) for a while and didn't see any such thing.]
http://www.objectmentor.com/resources/articles/dip.pdf
[Oh yeah, actually I have read that before. Pretty shallow article; primarily he's illustrating his own idiosyncratic definition of OO. As far as I know, he's the only pundit who uses that DependencyInversion definition. If you think it's a weak technique, I sympathize; to my mind it's more closely related to pre-OO structured programming techniques.]
[Anyway he uses the phrase "I/O driver", not "device driver". I think he was ill-advised to do so, since it sounds like a kind of device driver. Perhaps "I/O handler" would be a safer phrase for what he's talking about.]
[But even he isn't saying that everything should be viewed as an I/O handler. That's merely a toy example. His actual point is about DependencyInversion. It's just that it's unclear what he means by that without an example, is all.]
A question for you, Top. Back up a step and ignore "device drivers" for a second. Instead, please describe the applications/environments/functions, etc. which, in your opinion:
Be specific. :)
WhenToUseWhatParadigm is perhaps the best place to discuss this, and may already have the answers.
Extrapolating Device Drivers