Black Box Componentry

Object-orientation is a great improvement over the structured techniques. Take the concepts in the problem domain and build code around them. Leverage stability in the domain so that you don't have to write as much code over time. Sounds good, but where is the cross-domain reuse?

We've found that data is less important than behavior in choosing our classifications. We've also found that the LiskovSubstitutionPrinciple tends to make our classifications grow away from the kind of classifications that the man in the street would make. BertrandMeyer's attempts to keep covariance point toward this trend and attempt to mend it. Is keeping the domain connection worth it?

A Mailman is-a person. So what? I only care that someone/something can deliver my mail for me. Is-a means that we can use one thing in place of another. Is a 556 timer IC a 555 timer IC? Well, can I use it in place of one? Can I use email rather than a postman? Yup. At an analysis level, OO doesn't deal with these issues. Use an adaptor? Fine, but isn't there something more elemental here?

Whitebox reuse is flexible but it has its drawbacks. Unit test everything. If you have a blackbox, run the tests once and throw them away (figuratively). No one is going to invasively change your blackbox.

Miss inheritance? Use delegation.

-- MichaelFeathers

Oh, look, here's another spot I can stick the word MultiCaster. -- PeterMerel

Yes, looking at MultiCaster again.. in some ways it looks like a breadboard for software, but more powerful than that suggests. One real downside to the component metaphor is that it may cause us to see less than what is possible. As much as I like it, I am leery of it. -- MichaelFeathers

Michael, look around a bit more. After reading what you wrote I found a reference in the proceedings of a workshop on components. Blackboxes may have a future, but the whole area is full of difficulties. Take a look at the following talk by GregorKiczales at OOPSLA94. It discusses why we don't have prevalent black box reuse today. It also looks like a lead in to AspectOrientedProgramming: http://www.parc.xerox.com/spl/projects/oi/towards-talk/transcript.html. Also, I'd be cautious about talking to yourself this way. People are liable to wonder.

-- MichaelFeathers

An early description of blackbox systems is Designing Reusable Classes. See http://www.laputan.org/drc/drc.html

c := a + b;

a black box for

LDA A
ADD B
STO C

? Perhaps BlackBoxComponentry = abstraction? --RonJeffries

I'm afraid I don't really understand the opening comment. Is there a subtext that needs to be made explicit? I'm interested in covariance and circumstances where the LiskovSubstitutionPrinciple fails, and hence in MultiMethods and what some people call PostObjectProgramming?. However I don't see the connection with black/white boxes. The key idea, surely, is to have an interface, and the black/white thing is about how big that interface is. -- DaveHarris

I just notice that covariance pops up often when we assume that a class in code is the same as a class of real world objects, or a suitably vivid metaphor. Sort of carrying the representation too far. It is interesting to consider that hardware engineers do not have a superclass "clock" that they use for all timers. When you look across all of the things that an engineer would classify as a clock there is no set of operations which would serve as a universal base class. Because we make practically all of our own code, we do this sort of representational modeling and change capabilities on the fly as our understanding grows. What I am getting at is that perhaps the domain modeling that we do is analogous to the attempts to fly by making airplanes with flapping wings. You side with something that works and hope your attempt at emulation works. Fortunately for us, it does work most of the time, yet we are able to abstract further to the level of mechanism. When we cut to the essence -- how do I solve this problem? -- do we end up with objects which have no analog in the conceptual understanding of the problem, yet are as utilitarian as a screw or a microchip for solving the problem? - MichaelFeathers

Yes, this is about the extent to which subtyping and Liskov substitutability actually occur in the real world. Is the black/white connection due to the theory that white boxes are more useful, more adaptable when pure, simple substitutability breaks down? -- DaveHarris

I tend to think that Liskov substitutability is a law of nature. (See LiskovSubstitutionPrinciple) but it applies to the artifacts that we make rather than the concepts that we model. As long as we think that we modeling our ideas or things in the real world, we will confront covariance. I do think that whiteboxes are undeniably more flexible, but I wonder how long people will be willing to financially support that flexibility rather than go for JustGoodEnoughSoftware?. TheThirdWave is the scenario I hope plays out, but it is hard to bet on. -- MichaelFeathers

A difficulty with BlackBoxComponentry can be OverEngineering. When we build a class for today, it is usually simple and straightforward. When we build it for the ages, we add capabilities that someone "might need". This is especially true when we are going to have to package it as a black box, since there will be no way for folks to improve it later.

I've used a number of components in this form, and have many times regretted it: the capability I really needed could have been implemented directly more quickly than learning the black box ... and in much less space. YMMV --RonJeffries

I look at BlackBoxComponentry because I don't like being taken off-guard. But, frankly, I dread it. I'd much rather design with flexible clay than spend my life trying to fit square pegs in round holes. I don't want to have fifteen catalogs of software components on my shelf so that I have to spend by day hunting for the one that I need. I just hope that it is not inevitable. As we speak there are hordes of people pasting ActiveX controls on forms, gluing them together and making people happy. They "don't need no stinkin' OO expert." On the other hand, a teammate of mine spent two weeks trying to figure out how to use a vendor's universal data acq device driver for NT before we pulled the plug and started writing the specific narrow thing that we needed ourselves. -- MichaelFeathers

I just noticed that Object Magazine has now become Component Strategies. -- MichaelFeathers

You can see the bloat problem with BlackBoxComponentry by looking at the office productivity suites and the complaints about them. Few users use more than 20% of the functionality but one size must fit all so the installation is always bigger than it needs to be. To combat this the vendors want to reduce the granularity of the components. This might help but then the glue that ties them together becomes complex and heavy as it is written to suppport all possible combinations. Bottom line is that an general purpose solution for a large population of diverse uses will be big and complex and therefore hard to fully understand and probably slow and probably buggy.

I agree with the bloat/office software comment, but a properly designed and coded piece of software actually eliminates bloat problems, due to the fact that you can rip out what you don't need. I see a lot of useful applications that use components such as applications with plug-ins, like Total Commander and BorlandDelphi, ComponentPascal, etc . Plug-ins I think are a large part of our current component software examples, since most plug-in based software allows you to rip out and replace components in real time, while the program is running.

CategoryComponents