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



.



Relevant Pages

  • Re: How can I make this design tidier?
    ... Interface "AnyElement" with about 80 properties. ... A generalization with 60 sibling subclasses is almost surely wrong because it is too big. ... If so, then they don't share that property with other superclass members in other subclasses, which defeats one goal of generalization. ...
    (comp.object)
  • Re: Question about polymorphism
    ... > Two sibling classes implement the same interface. ... > comes up and additional information needs to be passed to one of the ... ignored by the first class' method implementation. ... generalization - or, the other way around, the first class' method can be ...
    (comp.object)
  • Re: Encapsulation vs separation of concerns
    ... >>tree than B. The specification of A depends upon what B does. ... variables to make computational responsibilities clearer): ... > But if you have a separate persistence subsystem, ... One both sides of the interface there is a mapping of the X data packet. ...
    (comp.object)
  • Re: object system...
    ... In OOA/D accessing knowledge responsibilities is quite different than accessing behavior responsibilities. ... There's a reason why getters and setters exist. ... (due to a side effect of how the interface mechanism is implemented, the same interface will work on a class regardless of whether or not said class implements the interface as such); ... I think existing relationship navigation and interfaces work just fine in supporting peer-to-peer collaboration whether delegation is used or not. ...
    (comp.object)
  • Re: implementing roles in OOP......
    ... > "An application implements a system of responsibilities. ... > single purpose) within a given level of abstraction. ... Note that since an interface defines the messages an object will ... Car not ComponentList). ...
    (comp.object)