Class Diagram Question

Class Diagram Question

Post by Simone Finot » Sat, 26 Jul 2003 00:08:24



H. S. Lahman ha scritto:

Quote:> Responding to Finotti...
> >>Hopefully invoking another object's operation in the constructor was
> >>done for the sake of simplifying the example and you wouldn't do that
> >>sort of thing in practice.  B-)

> > what's wrong with that?
> It depends upon the language, but generally constructors are the most
> fragile of methods because the compiler/interpreter is doing
> housekeeping that is invisible.  For example, the constructor code may
> require different privileges than the rest of the application so the
> invoked method might introduce an error that goes undetected because it
> was running at the wrong privilege level.  A less extreme example is
> reentrancy.  If the called method also instantiates an object the
> constructor code may be called recursively and it may not be reentrant.
>   A variation is that the constructor may optimize by invoking different
> version of 'new' depending upon the circumstances and there may be some
> interaction with the 'new' invoked by the called method.
> One also has a problem determining if they actually worked in most
> languages and, if not, what actually went wrong.  For example, there is
> usually no guarantee that an error handler around the constructor will
> be activated if something goes wrong because the constructor code itself
> may capture the error transparently.
> While such problems are very rare and one can debate whether they are
> features or bugs, they also tend to be subtle, non-portable, and
> intermittent.  So the general rule is: Don't Go There and keep
> constructors as simple as possible.

what you say seems to go against the RAII principle, that I found so
useful (at least in C++ programming). Do I have misunderstood you or you
don't agree with that principle?

--

questo articolo e` stato inviato via web dal servizio gratuito

 
 
 

Class Diagram Question

Post by H. S. Lahma » Sat, 26 Jul 2003 01:55:21


Responding to Finotti...

Quote:>>While such problems are very rare and one can debate whether they are
>>features or bugs, they also tend to be subtle, non-portable, and
>>intermittent.  So the general rule is: Don't Go There and keep
>>constructors as simple as possible.

> what you say seems to go against the RAII principle, that I found so
> useful (at least in C++ programming). Do I have misunderstood you or you
> don't agree with that principle?

C++ is the Poster Child for fragile OOPLs, so it is even more important
there to keep constructors simple.  B-)  But the issue is more general
than even OOP.  The same potential problem exists in non-OOPLs (e.g., in
error handlers).  Whenever there may be instructions _within the same
scope_ that one knows nothing about, it is dangerous to do * things.

I don't think RAII has anything to do with the issue.  A constructor is
a highly specialized, fundamental semantic unit in an OOPL.  What is the
purpose of a constructor?  It is to instantiate an object.  How does one
instantiate an object?  By allocating memory, initializing its state
variables, and instantiating relationships with other objects.  Doing
anything else in the constructor trashes another principle: cohesive
encapsulation.

To put it another way, anything else done in the constructor is
executing part of the problem solution rather instantiating an object.
Applying OO and other principles to the solution is fine, but one needs
to keep the solution out of constructors.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman

Pathfinder Solutions  -- We Make UML Work
http://www.veryComputer.com/
(888)-OOA-PATH

 
 
 

Class Diagram Question

Post by Univers » Sat, 26 Jul 2003 06:04:53





>> class B
>> {
>> private:
>> A* mpA;
> Here you've implemented in class B a persistent reference to an instance of
> class A, implying an association.
>> Rose produced the following model.

>>    ___              mpA  ___
>>   | B |________________\| A |
>>   |___|                /|___|

>> However, Rose described the relations for Class B as follows.

>> Name                         Class          End Class
>> mpA : A in association         A                B
>> Dependency Class A             B                A

>> Wouldn't this indicate a need for two separate lines showing
>> the dependency and another showing association?
> If an association already exists between classes, modelers commonly do not
> show any dependency relationships that also exist.

Mostly whether or not mostly Association versus Physical Dependency
relationships and entities are depicted, in most of the sw industry, seems
to depend in largest part upon where the diagrammatic depiction will
be usedd.

In other words, it depends upon the *level of abstraction* and related
mostly to that, concommitant phases and stages of the software development
lifecycle (SDLC):
    ` ANALYSIS - use cases; analysis object models; overall, conceptual
                 object model solution design, etc.
    ` ARCHITECTURAL - overall system design
    ` PHYSICAL DESIGN - local and subsystem implementation design, etc.
    ` DEPLOYMENT - coding; hardware confguration; user training, etc.

It often works out that at higher levels of abstraction the use of
"non-specific"/"non-physical" relationships and entities are avoided in
favor of more *conceptually* or *logically* directed modelling elements.  

This kind of thing characterizes most any modelling paradigm.

With for example OO, "early on" in a project's software development
lifecycle (SDLC) activity typically is more focused on object
responsibility targetted decomposition via *analytical* investigation, and
discovery, "non-specific"/"non-physical" relationships and entities.  

As the SDLC moves on through to more work in the architectural and after
that, local and subsystem design, OO modelling diagrams tend to
"transform" non-specific, logical class Association and object Link
relationships and entities into more "concrete" and "specific" physical
ones like the direction of physical Derivation/Inheritance relationships.  

*Physical* in this case being 180 degrees opposite the *Logical* direction
of the relationship between a "Super" class and its "Child"
classes.  *Very* important to take note of this.

For detail with examples and coherent practical theory on this, see at
my web site both my published:

        "Broad New Vistas"                Method & Tools '96

        "OO Layered System and Subsytem   Object '95
                                          Wisdom of the Gurus '96

Elliott
--
OO software rests upon class abstractions expressed in class method
*behaviors*.  The sum of class method behaviors is the overall class
*role*.  Class role should have primary responsibility for managing class
data such that the impact of class data is driven by the operation of
class methods.
         ~*~   Get with OO fundamentals, get OO.  ~*~
-
      We Don't Need US Fat Cat's Geopolitical Hegemony!
           People of the World Demand US Stop Now!
-
               * http:\\www.radix.net/~universe *

 
 
 

Class Diagram Question

Post by Roger L. Cauvi » Sat, 26 Jul 2003 09:43:58



Quote:

> Stay away from doing anything sophisticated within the
> constructor as you are likely to get burned. Its very easy to
> make mistakes with complex constructors, it makes your
> code brittle, and you will invariably run into some
> constructor needs that cannot be performed within
> the object construction "rule" system.

http://lightning.prohosting.com/~rcauvin/ConstructionTechnique.htm

---
Roger L. Cauvin

 
 
 

Class Diagram Question

Post by Mikito Haraki » Sun, 27 Jul 2003 05:44:07





> > Stay away from doing anything sophisticated within the
> > constructor as you are likely to get burned. Its very easy to
> > make mistakes with complex constructors, it makes your
> > code brittle, and you will invariably run into some
> > constructor needs that cannot be performed within
> > the object construction "rule" system.

Yep. Constructors are ugly. When programming constructor I have to
distinguish between "fully created" object, and object in "partially
created" state, and this difference sometimes is just arbitrary.

Plus all this mess with initialization sequence -- what must be
initialized before what. In one example I easily refactored bloaty
constructor into lazy initialization.

 
 
 

Class Diagram Question

Post by Univer » Thu, 31 Jul 2003 01:08:41



wrote in


> >Responding to Turner...

> >> I'm trying to model the following.
> >> [C++ code elided]
> >Generally one does the model before the implementation.  B-)
> Sometimes, not generally.  

He's speaking about *mainstream* software development practices-not
xp/alliance and other such hacker ways.

Elliott