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.


I wasn't quite sure what you meant there. I had originally thought of having some big do_control_action() member function, and saving all the running sums and previous values as class members. I thought you meant to just take that out of the class as an external function. But when you have multiple controllers, each will have its own data sets of running sums and previous values to manage, and that gets less OOPy.

I assumed the feedback calculations were substantial (you mentioned filters and FFTs, as I recall). Even in a pure procedural setting that would require some degree of modularization. I am arguing here that one probably wouldn't provide that modularization via OOP; one would provide is using structured programming techniques. Then that would, indeed, be encapsulated in some do_control_action() method of a single object in the OO solution. That method might look something like:

Controller::do_control_action()
{
     // extract necessary attribute data from objects and
     // format it into some sort of data structure the
     // procedural solution needs as input

     // Then invoke entry point in linked procedural package:
     doIt(big_honking_data_structure_reference);
}

So there is no evidence of the procedural view of the algorithm in the OO solution. Thus this is a sort of dual of the OOP solution included in a structured program you originally mentioned. IOW, if you were doing a structured program and wanted to invoke something done with OO, you would probably encapsulate it much the same way.

[We had a device driver that was done with OO techniques. But we wrapped in the C wrapper with 300+ functions in the API so that it could be used in a procedural context. That encapsulation made the OOness completely transparent to anyone developing using a procedural approach.]


*************
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



.