[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Fwd: Looking over the code a little more...
From:       Darius Stachow <shiva () dialup ! nacamar ! de>
Date:       1999-11-23 16:24:58
[Download RAW message or body]



----------  Forwarded Message  ----------
Subject: Looking over the code a little more...
Date: Mon, 22 Nov 1999 22:22:40 -0800
From: Jake Fear <fear1@home.com>


Hi Darius, 
   I would have sent this to the kuml-devel mailing list, but I can't seem to
get subscribed.  Please feel free to forward to that list. 
I was looking over the way Classes are managed, and I see that the
DrawingClass actually emits the signal when the name of a class is changed.  I
think this would be better done by the Classes object itself. This would allow
any diagram that is using a particular Classes to update its graphic
representation with respect to a given class by "listening/attaching a slot" to
that Classes object (so an object or sequence diagram could update its
drawables when a user edits the properties of a given class regardless of
when/where it was created).

   To go along with this, it would be nice of there was a single place
responsible for creating classes, perhaps ClassesFactory or ClassFactory.  

class ClassFactory {
   public:
   Classes* createClass(QString className);
}

This factory would be responsible for making sure that the class name was not
empty, NULL or a duplicate name.  Then the factory could add the new class to
the repository (so it may be shared between diagrams) and return it to the
caller.  Editing the Classes properties could then be an option in any context
where it makes sense, and changes could be propegated (via Qt signals) to all
interested users of the class. An example would be 
1.) Right click on an instance in the sequence diagram
2.) Choose to edit the class, because you realized you needed to add a method
3.) Add the method and choose "Apply"
4.) Marvel at the great job kuml did of updating the DrawingItems in all of the
diagrams that use the given class ;-)......

Using the ClassFactory would be the only way to get an instance of a Classes
object (restrict Classes constructor access), so management of the
ClassRepository is very simple, the ClassFactory does most of the work.

This has the added advantage of "decoupling" the DrawingClass from the creation
of the Classes object, and the great disadvantage of requiring the changing of
much existing code (anywhere Classes are created).

Cheers,
Jake Fear
-------------------------------------------------------

Any comments ?


-- 
Open your mind ...
Darius Stachow

[prev in list] [next in list] [prev in thread] [next in thread]