Re: Using class <<stereotype>> as soft typed realization



Responding to Karl.wettin...

In a class diagram, I have a whole bunch of classes that implements
some interface. The dotted lines are everywhere and makes it hard to
read. Lollipops reduce the length of lines, and it sure increase the
number of elements in the diagram.

If the different classes share the same interface, they must share the
same responsibilities. If they have shared responsibilities they must be
siblings in a generalization to avoid Normal Form violations. Then the
interface applies to just one superclass in the generalization tree.


Not sure what you say here. If what I have is:

+- - -|>[A]<|- - -+
[X]- - -|- - -|>[B]<|- - -|- - -[Y]
[C]<|- - -+

Do you suggest that I refactor that to:

+- - -|>[A]<|- - -+
[X]----|>[/AB/]- -|- - -|>[B]<|- - -|- - -[/ABC/]<|-----[Y]
[C]<|- - -+

?

In essence, non abstract classes should not contain interfaces?

Not exactly. I was thinking about a different problem where

[SUV]
+ VBN
....

[Sedan]
+ VBN
....

as standalone classes is illegal if VBN is a standard Vehicle Identification Number. That's because it provides the same identity semantics in two different class relations and its uniqueness spans the classes. IOW, it violates 3rd Normal Form of the relational data model. (I used identity because the problem is more obvious; it also applies to non-identity attributes shared by different classes.) The only way both classes can remain distinct and share exactly the same attribute is through generalization:

[Vehicle]
+ VBN
...
A
|
+-------+-------+
| |
[SUV] [Sedan]

Now the interface to a class defines access to the class responsibilities. So the interface that provides access to the VBN only needs to be associated with the superclass:

[Vehicle] <--------------- (iVehicle)
+ VBN + getVBN
... ...
A
|
...

However, it turns out this doesn't matter because...


What it sounds like you might be describing is arbitrary composition, as in:

class HondaAccord : serializable, displayable, persistable


Actually, it is the UML class model I have modelled.

[Class] visible, scoped
[Attribute] multiple, visible, scoped
[AssociationEnd] multiple, visible, scoped
[Qualification] multiple
[Method] multiple, visible, scoped
[Parameter] multiple


In essence I reflect my Java classes in an UML class model mirror
using @annotations to map java fields as attributes and associations.
This mirror is used by a nuber of things, primary my persistency
layer.

It is for my java source code generator I "need" the interfaces.
renderVisibility(Visible) renderScope(Scoped) and so on. That could of
course be replaced by renderVisibility(Visibility) and
renderScope(Scope). Perhaps it is me who is a polymorphism junkie.

This isn't the problem I assumed it was. (I made that assumption because you said that the same interface was being used for different classes.) That is, attributes like Attribute.multiple and Method.multiple are not the same attributes being shared across classes. The data domains are the same but the semantics of the attribute is tied to the class. The situation is similar to HondaAccord.color and MaytagRefrigerator.color even if the only colors available for both are {Red, Black, and Purple}. That's because in the problem space the semantics is really "color of" and "multiple of"; a domain expert would not be confused at all about the color of a Honda Accord being a different and unrelated /property/ than the color of a Maytag Refrigerator.

So, given one can rationalize standalone classes having the same attribute name with the same data domains in the problem context, we are back to your original interface question. Now, though, I see a different problem. In this situation the same Interface should not be used to access different classes. IOW, [Class] and [Method] above can't share the same interface. That's /because/ the properties being accessed aren't the same.

In a language like Java the interface not only limits access to properties, it also defines what the properties the object must have. That means that if an interface identifies a property and is applied to two different classes, the attribute is, by definition, exactly the same property in both classes. That would be an instant Normal Form violation outside of a generalization.

A language like Java allows this because it also supports inheritance via interfaces. Thus one mechanism for creating a generalization is explicitly designating a class to provide an implementation of the superclass interface; the class immediately becomes a subclass. The key is that all subclasses provide different /implementations/ of the _same shared property_. The property itself is a superclass property with a single definition of what it is. But if there is no generalization, we are back to the Normal Form violation I described in the opening of this message because two standalone classes cannot have exactly the same property while the shared interface says it is exactly the same property.

Bottom line: outside of generalization we have:

Object : Interface :: 1 : *





{...}

If so, my push back would be: Don't Do That. OO development is not
functional programming development. There are no Displayable Honda
Accords in the customer problem space.


I agree, but don't think it applies to this. Or does it?

It doesn't apply; there's no arbitrary composition in play.


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

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.