Re: Object Oriented simpleton design pattern<g>

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Max Kudrenko" <vb_mvp@xxxxxxxxxxx> wrote in message
news:1177667633.347723.48570@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
We're all biased to some extent and that's normal. My bias, however,
makes me believe that Inheritance and Polymorphism are the joint
leaders in the usefulness as regards OO programming. I might have put
it slightly incorrectly as reuse in its own is indeed not much
interesting unless you can polymorph. For reuse without any changes,
any black boxes will indeed do. And even those created without any OO
intentions like many third-party libraries. A third-party DLL is also
a perfect black box (example of Encapsulation) and you can reuse its
functions as much as you want. But that's the difference between the
functional (or procedural) and OO approaches. In OO, you're not after
functions but rather functionality. And complex functionality is
rarely encompassed in a single function, for this you need something
more - interfaces or classes. But interfaces or classes are only
useful when you can inherit from them (implement or extend,
respectively). This is hardly possible with many third-party black
boxes. And almost impossible with VB. Real OO languages have this
support for inheriting many useful features built-in while VB has
none. What VB can do is implementing some custom functionality but
that means that each new feature must be first programmed somehow by
some one and then exposed to you to implement. And VB power is quite
restricted in both what can be programmed and what can be exposed. In
OO languages, however, such things come for free. If I want to make a
thread or a persistent object, I reuse Runnable or Serializable
interfaces (no matter under what name they come) without worrying how
do I create such interfaces in the first instance. So yes, VB may
support some form of Inheritance with its Implements keyword but
without providing what to inherit this is of little use. So OO
language is not only about allowing, say, Inheritance but also about
providing readily available concepts or building blocks to support it
from within. In other words, VB forces you to reinvent the wheel while
any OO language will let you just jump on your bike and ride. That's
my bias on it.



By "Real OO languages" I will assume you meant a fuller featured OOPL, as
opposed to something like "Real programmers use UNIX". The one is a factual
observation, the other speculation (and likely good for another long thread
<g>).

The VB environment is heavily "OO" and it is an OOPL. Period.

I keep harping on that, because like Marley's death, this must be distinctly
understood, else one is doomed to wander about inventing subtle nuances for
"functionality", "complex functions" vs "single functions", "usefulness",
"readily available", "black boxes", and other metaphysical diversions. None
of which has a damn thing to do with OO.

Implemenation inheritance is simply a means where a programmer can instruct
a compiler/runtime on how to assemble and manage multiple scraps of source
into one object at run time. VB has no direct support for this. C++ is a
master at it and that perhaps makes it a better OOPL. But as a finished
object ends up the same no matter what mechanisms were used to assemble it,
neither is more or less "real" than the other.

Such wanderings also detract from other far worse faults in VB as an OOPL.
The lack of custom constructors, the inability to override the New operator,
the lack of enforceable static members, poor container support, or
namespaces, are all items denied the VB programmer. But note, just like
implementation inheritance there are workarounds for everyone of these and
more. (Though mimicing overloads thru Variants has made more than one
programmer shudder. <g>)

Also, as I noted in another post, it too often leads those who assume they
are using a "real OO language" to pull out all the stops and use every
feature at their disposal to create some of the ugliest OO implementations
ever recorded. (In that department a newbie Java programmer will out-ugly a
newbie VB programmer every time. <g>)

VB is an OOPL and just as 'real' as anything else you pay money for and have
to agree to the licensing terms.

-ralph




.

Relevant Pages

  • Re: Stroustrups FAQ causes infinite loop when executed
    ... There may be ways in which inheritance could ... programmer could not have foreseen. ... >> complex calculations such as multiplying numerous transformation ... >> reason to cap the class. ...
    (comp.lang.cpp)
  • Re: Modularity problems with multiple dispatch
    ... rules for inheritance etc. Do the same for B', ... a so-called 'effective method' is run, ... but they cannot capture all aspects of a function's behaviour under run-time dispatch. ... means for the programmer that he/she should be prepared to ...
    (comp.lang.functional)
  • Re: Modularity problems with multiple dispatch
    ... rules for inheritance etc. Do the same for B', ... The programmer who tries to call f? ... Then the situation degenerates into single dispatch, and for that, we can use DbC and don't have that combination problem. ... my definition of an FPL is one that allows you to construct functions at runtime. ...
    (comp.lang.functional)
  • Re: Why cant C# or Java support multiple inheritance? But inherit multiple interfaces instead??
    ... > has terrible support for inheritance in general, ... programmer specify what specific class definition to use, ... > Funny, I don't seem to get them in Eiffel, which supports complete ... and recurring kinds of collaborations between those domain entities and ...
    (comp.object)
  • Re: Object Oriented simpleton design pattern
    ... makes me believe that Inheritance and Polymorphism are the joint ... For reuse without any changes, ... functions but rather functionality. ... any OO language will let you just jump on your bike and ride. ...
    (microsoft.public.vb.general.discussion)