Re: Downcasting - whats the problem?
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 05/18/04
- Next message: Leandro Guimaraens Faria Corsetti Dutra: "Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)"
- Previous message: Daniel Parker: "Re: Downcasting - whats the problem?"
- In reply to: Object Developer: "Downcasting - whats the problem?"
- Next in thread: Universe: "Re: Downcasting - whats the problem?"
- Reply: Universe: "Re: Downcasting - whats the problem?"
- Reply: Object Developer: "Re: Downcasting - whats the problem?"
- Reply: Daniel Parker: "Re: Downcasting - whats the problem?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 17 May 2004 23:53:59 GMT
Responding to Developer...
> I would like to ask what will be a very basic question for many on
> this list, so I hope those people offer some helpful advice on this.
> I would like to understand what the real problem is with downcasting
> in a staticly typed language. I know about the OCP, and I understand
> the reasons for why this type of thing is wrong:
The basic problem with downcasting is that it is treating an
non-navigable relation as if it were a navigable association. An OO
is-a relation is not navigable because there is only one instance in
hand that resolves the entire tree. IOW, there is no to/from to navigate.
In addition, accessing subclass specialization through the superclass is
a no-no that defeats the point of restricting access to properties.
When one accesses a superclass one is only supposed to be able to access
the properties that the superclass makes available. If one needs to
access subclass specializations, there should exist a relationship
directly to the subclass that can be navigated for access to those
properties.
1 R1 1
[Client] ---------------- [Super]
+ doCommon()
A
| R2
+----------+----------+
| |
[SubA] [SubB]
+ doA()
[SubA] and [SubB] must provide implementations for doCommon(). If the
solution requires Client to access doCommon() behavior all is well
because that responsibility is exposed in [Super]. That is, Client
navigates R1 -> Super to access the behavior.
However, if a Client must access the doA() responsibility, it can't do
that by "navigating" R1 -> Super -> R2 -> SubA to get to SubA. To
access that specialization it needs a path directly to [SubA]:
1 R1 1
[Client] ---------------- [Super]
| 1 + doCommon()
| A
| | R2
| R3 +----------+----------+
| 1 | |
+----------- [SubA] [SubB]
+ doA()
so that it can navigate R3 -> SubA.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH
- Next message: Leandro Guimaraens Faria Corsetti Dutra: "Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)"
- Previous message: Daniel Parker: "Re: Downcasting - whats the problem?"
- In reply to: Object Developer: "Downcasting - whats the problem?"
- Next in thread: Universe: "Re: Downcasting - whats the problem?"
- Reply: Universe: "Re: Downcasting - whats the problem?"
- Reply: Object Developer: "Re: Downcasting - whats the problem?"
- Reply: Daniel Parker: "Re: Downcasting - whats the problem?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|