XPost: alt.os.development
From: alexfru@chat.ru
"Maxim S. Shatskih" wrote in message
news:dtio5o$1a16$1@gavrilo.mtu.ru...
...
> Also, Dmitry, what do you think about inheritance? I've heard the
> following
> (roughly) opinion once from one software architect - "the original old
> historical OO paradigm treated inheritance as one of the 3 corner stones.
> But
> now, it is not so. The thing is that software architecting is managing
> _dependencies_ between components, which means - imposing some order and
> restrictions on them, so they remain manageable and not grow into the
> unmanageable pile of dirt. This effectively means - imposing strong
> contracts
> and decreasing the number of dependencies and their strength. Now note
> that
> inheritance is not about that, it's vice versa, it _introduces_ the
> dependency,
> and a very strong one, one of the strongest possible. So, inheritance
> should be
> treated as a handy tool, a replacement to code copy/paste, but not as a
> corner
> stone of the architecture".
Interestingly, the last time I saw and used inheritance in my practice was
when I was working on the following:
1. windowing systems (where all windows are derived from some base class)
2. patching/bugfixing ROMed code (where many functions were called by
pointers, which, fortunately, could be changed at runtime)
For the 1st thing it's just natural to use the two technics.
For the 2nd it was just inevitable due to the memory size and performance
constraints (ROM was internal and execution in it was preferred over
execution in any RAM (the external one is slow, the internal one is
precious) and therefore things must have been reused).
Back in the beginning of 90s, when OOP was introduced in Borland's Pascal,
some Pascal books mentioned another use of the OOP - extendable libraries
w/o source code. Basically, you can link against the same library all the
time, but due to the good design of the objects you could inherit things and
modify in a way you want w/o a need for the source code of the library.
The reasons that I can see why this isn't happening frequently are:
- performance (inheritance comes at the price of extra object storage
including virtual tables, and the costs of extra calls whether direct or
indirect)
- good design for this purpose may be costly. I remember looking through
Borland's Turbo Vision implementation source codes... The base objects at
first looked overcomplicated and having lots of unneeded stuff or stuff that
could be done in some other way, but the thing was that all that was done to
provide that kind of feature spectrum and flexibility Turbo Vision had. Even
though things like that (like TV) are more or less straightforward in
principle, quite some work needs to be done to make things right. I think
people don't reuse the code that way and just start over because they need
little and less general things right now and because they don't see a reason
to learn a some big piece of software to do the little things they need
right now. Sometimes it's good enough. Sometimes it's perfect. Sometimes
it's just bad because when moving towards more general and complicated
things, the old code for the little things must be thrown away and the
bigger one needs to be used or developed anyways.
As for extendable/flexible code w/o source, I don't know if it's an issue...
I mean, these days we have lots of tools for cracking and reverse
engineering code, so the absence of the source is probably not that big
deal. Yet there're many cheap coders to think about, who might probably
reimplement the thing given the specs :) At least, this isn't something one
could use as means of protection...
And then people make such bugs that it's not always practical to make
workarounds for the object code and therefore the source needs to be fixed
and recompiled.
Alex
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
