Re: I/O class: how to design for special case

Responding to Elliott...

Bottom line: I think the implementation changes for whoever should
logically understand how to apply the Mystery Number.



Yes, that makes sense. The performance constraints muddy the waters a
bit though. Ideally the caller shouldn't need to know about the Mystery
Number, but to hide it from the caller would involve an extra buffer
copy.

Right. Dealing with nonfunctional requirements often means sacrificing maintainability to some extent because those requirements are orthogonal to the customer problem. So it may be more robust for Cfoo to encapsulate the buffer management, but practicality may demand that the client do the right thing as a precondition to invoking Cfoo.

However, I would push back a bit on worrying about performance for this sort of situation. Somebody is going to have to pad/split the buffer based on the the Mystery Number, so that processing is fixed. The only marginal hit is a second buffer allocation and the data copy if Cfoo does it. Most of that hit will <probably> be in the heap allocation, so it may be possible to do something like a static buffer allocation that is done once to solve the performance problem.

That is, my push back is really to be able to demonstrate that (a) there is a performance problem and (b) having the client own the buffer management will really solve it. IOW, I would design it right until proven otherwise.

We're far enough down the road that we're committed to an object
design, and to implementing this via C++. Just as an academic exercise,
Would other design methodologies or language choices offer us any other
options here?

The first would be to use C rather than C++. B-) Commercial transformation engines that do full code generation from OOA models routinely target C in R-T/E applications to provide better performance.

Methodologically dependency management at the OOP level to make the code more maintainable can have a substantial hit in performance. John Lakos, in "Large Scale C++ Software Design", measured hits of up to three orders of magnitude if one did everything possible for dependency management so there is always a trade-off in how robust one wants to be.

<commercial>
One of the advantages of translation-based development is that one does not have to maintain 3GL code. The problems in physical coupling that lead to poor maintainability w/o dependency management are essentially inherent in the languages being 3GLs (though OOPLs tend to be worse than procedural languages because of their more complex use of type systems). Since a translationist just does OOA models, one doesn't care if the 3GL code is maintainable (i.e., if anything needs to change it is just regenerated after the model is changed). So the transformation engine can thoroughly optimize it into unreadability. [I know of one translation tool vendor who deliberately generates unreadable 3GL code just to make sure the developer doesn't muck with it w/o changing the models.]
</commercial>

Alas, at the paradigm level, OO development will inherently tend to have poorer performance than procedural or functional programming. That's because OO addresses the goal of maintainability through abstraction. But abstraction at the OOPL level means the language is doing some of the grunt work and it has to do it in a very generic fashion. That necessarily means one cannot provide as much tailoring of the specific solution as one would like. So juts to make the choice of using OO one has already acknowledged that maintainability is a higher overall priority than performance.

Unfortunately it goes further than simply targeting C from an OOA/D model. The paradigm itself strives to address issues like modifying global data through OOA/D practices. Some of those practices, like resolving inheritance, will usually lead to things like jump table indirection in the implementation no matter what 3GL one employs to implement the OOA/D.


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



.

Relevant Pages

  • Re: I/O class: how to design for special case
    ... > sacrificing maintainability to some extent because those requirements ... > buffer based on the the Mystery Number, ... > The only marginal hit is a second buffer allocation and the data copy ... I would design it right ...
    (comp.object)
  • [PATCH 3/3] pac7311: remove magic value for USB_BUF_SZ
    ... The length check in reg_w_varfunction is because the buffer contents ... symbol for better readability and maintainability. ... The change was tested with Labtec Webcam 2200. ...
    (Linux-Kernel)