How do you represent a super() call in a sequence diagram? I create a class "Bar", which is a subclass of "Foo". While creating this class Bar, the default constructor of Foo gets called to. How do you draw that in a sequence diagram?
A super call represents a call to some method of the superclass, so if class A extends from class B then:
class A extends B{
public A (){
super();
}
}
And
class B {
public B (){
...
}
}
You have to think of this classes in runtime, so for example you have an object a from class A called a, this object is represented by both classes since class A extends class B.
In this case I would do a diagram with the constructor of the super class B, so I can link this diagram to the diagram in which I represent the constructor of the class A.
Since the call to the super class constructor refers to the same object a not another object the message arrow should be a self message in which it calls to the constructor of the super class B.
Additionally to make things more clear I would add the code of the super call.
Something more graphical should be this.
And for class B
PD. I Use Enterprise Architect software to do the diagrams.
Related
In an AST transformation, I am trying to detect whether a class Foo has nested classes and, if so, whether they are static or inner classes:
#MyTransform
class Foo {
static class A {}
class B {}
}
When I examine fooCn.innerClasses, both Foo$A and Foo$B are listed. ClassNode includes a method called isStaticClass, but by the Javadoc, this only tells me whether a nested class is declared within a static method (as a local class), not whether it is a "static class" by the JLS definition. Both a.staticClass and b.staticClass return false, and both a and b return Foo for outerClass.
How can I inspect the class nodes for Foo$A and Foo$B and determine that Foo$A is a static nested class?
The ClassNode representing each class has a property modifiers containing the modifier flags for the class; bit 4 (value 8) is defined as the STATIC modifier. The utility method java.lang.reflect.Modifier.isStatic(classNode.modifiers) will indicate whether the class is static nested or inner.
I have a superclass called A and a subclass called B that inherits from A. The superclass's constructor looks like this:
A(String name, char displayChar, int hitPoints, Behaviour behaviour)
{
this.name = name;
this.displayChar = displayChar;
this.hitPoints = hitPoints
addBehaviour(behaviour);
}
A has attributes of name, displayChar, hitPoints, behaviour and has a method that calls addBehaviour which adds the behaviour to the object.
The subclass, B's constructor looks like this:
B(String name) {super(name, char 'b', 10, new WalkBehaviour()); }
Now my question is, does subclass B have an attribute of WalkBehaviour?
How would the UML diagram look like for this scenario? I know B inherits from A and A has Behaviour but does B has WalkBehaviour in this case? Since B doesn't have an instance variable of type WalkBehaviour in its class but only passes WalkBehaviour through its superclass's constructor.
does subclass B have an attribute of WalkBehaviour?
No. There is none declared. The superclass will do something with that new object but obviously it's hidden in the mist of its implementation.
Inheritance is nothing that involves multiple object creation. Your B instance is just a single one which does have attributes and operations like its super class.
Thus, in a SD, you will see only one life line for B:
As you can see the B instance will just issue a self-call to the super class's constructor.
Note: as #AxelScheithauer pointed out in the comment the super class will invoke addBehavior which can (but must not) be shown in the SD:
I find in Kotlin: Object documentation an example:
open class A(x: Int) {
public open val y: Int = x
}
interface B {...}
val ab: A = object : A(1), B {
override val y = 15
}
So I implemented that example with more meaningful names and I have no clue what is the reason of the interface among the comma separated list of supertypes to the object?
interface Toy {
fun play () {
println("Play, play....")
}
}
open class Ball(public open val color: String = "red") {}
val ball: Ball = object : Ball(), Toy {
override val color : String = "blue"
override fun play() {
println("Bounce, bounce...")
}
}
fun main(args: Array<String>) {
println(ball.color)
// no ball.play() here then why the interface in the example ???
}
You're correct, the interface B (or in your example, Toy) will not be directly accessible through this reference if A (or Ball) doesn't implement it.
Inheriting from that interface is probably just added here so that this example intended to show how constructor parameters are passed to a superclass can also show off inheriting from multiple types very quickly. Or at least that's what I gather from the text accompanying it:
If a supertype has a constructor, appropriate constructor parameters must be passed to it. Many supertypes may be specified as a comma-separated list after the colon.
To get to the issue of not being able to use the created object as a B (or Toy) here: this doesn't make the language feature useless, since the created object can still be used through its multiple interfaces through casting. For example, in your example, you can do this:
(ball as Toy).play()
Or in the original example, you could make the type Any, and then cast to the different interfaces as needed.
You have created an instance of an anonymous class that inherits from class Ball and at the same time implements interface Toy.
But, both of these types are exclusive, ie. Ball is not a Toy (in your example), so you cannot call play() on a reference to Ball.
Sorry for the naming of the title because I don't know how to name this situation.
There are three classes A, B and C. Class A need the function of class C. Class B is an instance collection of class C. So the operation should be class A calls the static method of class B to get the instance of class C.
//in class A
Class C = B.getCInstance("[instance name]")
C.doSth();
Then what is the relationship between class A, B and C in UML? When I draw a UML class diagram, should I need to build all of the relationship between A, B and C? for example:
A class A uses a class B.
A class B has A class C.
A class A has A class C.
According the definition of the UML Usage dependency, I would say that class A uses both Class B and C and Class B uses Class C as depicted below
A Usage is a Dependency in which one NamedElement requires another NamedElement (or set of NamedElements) for its full
implementation or operation. The Usage does not specify how the client uses the supplier other than the fact that the supplier is used
by the definition or implementation of the client.
I have three Groovy classes: M, A, & B. B exists as a mixin of M and an extension of the abstract class A:
class M {
def foo = 11
def bar = 12
}
abstract class A {
abstract foo
}
#Mixin(M)
class B extends A {
}
def b = new B()
print "${b.foo}\n"
print "${b.bar}\n"
Attempting to run this causes Groovy to complain with:
Can't have an abstract method in a non-abstract class. The class 'B' must be declared abstract or the method 'void setFoo(java.lang.Object)' must be implemented.
However, the method is implemented by the mixin M.
Furthermore, if I change B to be:
#Mixin(M)
class B extends A {
def foo = 13
}
Then I get the printout:
11
12
And not:
13
12
Which is what I expect and seems to prove that M provides an acceptable implementation of the abstract methods of A.
So, why isn't groovy happy with using the mixin M to satisfy the abstract class A, what am I doing wrong?
You're doing nothing wrong. It's the problem of the compiler performing this check before actually applying the AST transformations. You better post this on their issue tracker at http://jira.codehaus.org/secure/BrowseProject.jspa?id=10242.
Since #Mixin transformation was actually created by the author of Groovy++ AFAIK, and since Groovy++ has much more extended support for categories, mixins and traits you could expect this to be a valid code there. You should try it.