Re: Lahman, how ya doing?

Responding to Hansen...

I've read of differences of opinion on whether programming philosophies, like OOP versus structured, can be mixed. It seems that few people think they can or should. But I can imagine an OOP simulation included in a very structured analysis program that, in an algorithmic fashion, sends some parameters to Controller, pushes an event on to the queue to get that going, and then gets a data set to analyze.

I am definitely in the camp that holds that the paradigms can't be mixed. But that is voluminous forum thread material, so let's not go there.

I will make two points, though. Remember that the OO approach grew out of simulation needs and some argue that Simula was the first OOPL. So the militant use of abstraction and flexible logical indivisibility in OO development is pretty much ideal for simulation.

The second point is a reminder that awhile back I suggested (I think -- hard to keep the threads straight) that all the heavy duty processing in the feedback loop that drives the controller and all the heavy-duty thermo to compute temperatures could be done outside of OO as realized code. That's because it is pure algorithmic stuff that is well-defined outside the scope of this problem. For that kind of thing procedural or functional programming is usually a better choice because it is computationally more intuitive one doesn't have to worry about the requirements changing once it works correctly.

That would leave you with a rather small OO problem to glue those two streams on computation together through scheduling the sampling.

Well, I did see the results of a survey of programmers about the advantages of OOP, and code reuse was at the bottom. It was still an advantage to be included in a list, but it was the least of the advantages. Some shops that have tried to make generic and eminently reuseable libraries have found it so time-consuming that it was just abandoned.

So the programmers that were surveyed write their own String or Array classes for each application? Good luck. Everybody gets reuse of computing space objects through commercial libraries. That's because they are very narrowly defined data holders. So is an event queue; it's just a smart stack.


And the algorithmic programmer gets code reuse with stdio.h and math.h, too. I don't think that's what they were talking about as an OOP advantage.

Right. Through most of the '80s the vision was reuse of _problem space_ objects. But problem space entities are not mathematically defined and they tend to be complicated and locally customized. So just documenting what objects you have in your library is daunting, much less dealing with "universal" interfaces, determining an common suite of responsibilities, etc., etc.

As far as object reuse in general is concerned, I agree it never lived up to the hubris of the '70s and early '80s. The problem is that one can provide quite different valid syntaxes for the same semantics. So when an object moves to a new reuse context the new client may be expecting to use a different access syntax (interface) than the one provided with the object for the original client. So even though client and service are very clear about the semantics of the service, they can't talk to one another.


I thought it would have more to do with tailoring something for a specific purpose versus building a Swiss army knife. You created your own queue in the sample code, and it would probably take about half a page to manage the pointers and so on. Compare that with the STL queue structure.

The thing is that an event queue is just a stack and every application's event queue is going to look the same way once one come up with a generic scheme for identity, etc. and one decides whether one needs to support concurrency, etc. There is an initial cost in extracting the invariants of an event queue, but once that is done all one needs is one. [Note that all translation code generators provide an architectural library that has an event queue class. They reuse (link in) that library when generating /any/ application and it Just Works.]

That works because an event queue is essentially a computing space entity that is very narrowly and precisely defined. Problem space objects rarely have that simplicity and clarity. Instead, we actually emphasize abstracting only what we need to solve the problem in hand. IOW, problem space entities are almost always swiss army knives that have a ton of stuff one will never need to solve the current problem. They also have stuff that will be used in ways the manufacturer never imagined. But there is pretty much only one thing an event queue is good for.

Basically there are three solutions. One can modify the new client to use the access interface provided with the service rather than the one it wants to use. That means touching the implementation of the client, which is a major no-no in OO development. The second possibility is to add the interface that the new client wants to see to the service. That results in rapid increase in the complexity of the interface, much of which is redundant. That redundancy hurts if one uses the interface to "tailor" the object (e.g., provide a burdened cost from a base cost and burden rate) because it requires double edits if the tailoring changes, which is fragile.

The third solution is to provide "glue" code between the interface the reuse client wants and the interface the service object provides (e.g., a Facade pattern).



Glue? Is that also called a wrapper?

Usually. There are other techniques that can be used, like inclusion polymorphism to reduce (abstract) what the client needs to know about the specific service, to alleviate the problem.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.