Re: Lahman, how ya doing?

Responding to Hansen...

So it's not just me! I've been starting to notice that C++ seems to make it harder than it has to be to do things that must be common in OOP.

C++ is generally regarded as the most technically deficient of the popular OOPLs. A major reason was the that performance and low-level machine control were primary design objective. That results in a lot of compromises. Given the design goal, it is not bad. However, the prices one pays are that a higher skill is required to use it properly and there are a lot more opportunities for foot-shooting.


It didn't take me long to realize that a generic pointer can only hold any variety of classes if they were all derived from a single base class (e.g. the recipient of an event, or the object to read data from), but you can't invoke methods unique to a derived class with a pointer to the base class. I suppose there's dynamic typecasting techniques to get around that, but it just seemed easier to let my base class keep accumulating virtual member functions as derived classes gained their own functions.

Actually C++ provides dynamic_cast for this. It exists as a mechanism to deal with an external stream of arbitrary objects where one needs to determine the nature of the object in hand to access its specializations.

However, I regard that as one of C++'s deficiencies because too many people abuse it to navigate from superclass to subclass during routine collaborations. Subclassing relationships are not navigable for collaboration because there is only one instance in hand to navigate.

If one needs to access the subclass specializations (and the object is not supplied externally), then there should already be a direct relationship path to the subclass that can be navigated. That path will provide type safety and whatnot. If that relationship is not properly implemented and instantiated, then that is a design fault.


*************
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: Lahman, how ya doing?
    ... >> variety of classes if they were all derived from a single base class ... I regard that as one of C++'s deficiencies because too many ... >people abuse it to navigate from superclass to subclass during routine ... >collaboration because there is only one instance in hand to navigate. ...
    (comp.object)
  • Re: MustInherit in Window forms
    ... and it'll be run if the SUBCLASS implementor chooses not to implement ... much depends on whether your base class is usable itself: ... > DisconnectFromAbrServer() method there, and it'll be run if the base class ... > implementor chooses not to implement a custom version of the method. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: using dict for data attributes instead of self
    ... >So why does he wants a dictionary-like base class if he never uses any ... (IMO that __setitem__ subclass override trick is not a good substitute ... BTW, the above was probably written before you could subclass the builtin dict, but now ... A subclass could use lists as additional ways to store info if needed. ...
    (comp.lang.python)
  • Re: Convenience constructors and non-final setters
    ... any subclass has no choice than use ... functionality, the base class might be better off as an interface. ... ColoredCartPoint and ColoredPolarPoint concrete subclasses that implement ...
    (comp.lang.java.programmer)
  • Re: Fat Interface vs. Type Switch
    ... this sort of design often reflects a more subtle design ... It can be used to effectively navigate a subclassing ... > subclass specializations. ... Suppose I query a server for trades that satisfy the criteria of some ...
    (comp.object)