I have a situation similar to this:
classA.h:
class A{};
classB.h:
#include "classA.h"
class B{};
Is there a way (and should I do it?) to show that classB uses (includes) classA even though there is no heredity involved? ClassB doesn't even have classA as a member, but I feel like it would make sense to somehow show this in the class diagram.
You can do it two ways. The first is to simply enlarge B so it can hold A like this:
Note the fully qualified name for A.
Another way is to use an import relation:
Related
I have a function which takes a class and returns an instance of that class. I'm trying to figure out how to typehint that, with a twist. Typically I would use the typing module and do something like
T = TypeVar("T", bound="BaseClass")
def foo(specific_type: Type[T]) -> T:
...
However, in my case I don't exactly want to take a class inheriting from a specific base class. What I really want to do is take a class with a specific metaclass and return an instance of that class, but I can't figure out a way to typehint that without adding some sort of dummy BaseClass. Ideally I would want the inverse of Type, something like:
M = TypeVar("M", bound="MyMetaclass")
def foo(specific_type: M) -> Instance[M]: # <-- Instance generic is made up
...
This lets me specify that foo should take an instance of MyMetaclass (which a class with metaclass=MyMetaclass is) and return an instance of that instance (an object whose class has metaclass=MyMetclass).
Is there anything in Python that lets me type hint something similar to the above?
To be clear, there is actually a base class with metaclass=MyMetaclass which I expect specific_type should probably always inherit from. However, I cannot import it into the current context without creating circular dependencies; MyMetaclass is already imported into the current context. I can work around this (I'm not asking how to organize my project), but I specifically want to know if I can type hint an instance of a class with a known metaclass like this.
In case of utility module, I can have either class with static methods or just export methods. I think the first solution is better, though I saw a lot of implementations with second option. Are there any "nuances" here which I am not considering?
I would argue that a class with static methods is better for the following reasons:
If your class name is Utils, all imports will by default import it as Utils too. With exported functions however, they could be imported as Utils yet that would only be a convention , one that likely won't be the case in all the different places.
A class named Utils in a file named utils.js with all the utility methods neatly grouped together is aesthetically more pleasant than flat functions defined all over the place.
A class could have properties that are used among its methods, for this you'd need #babel/plugin-proposal-class-properties though. Again, much nicer than variables defined all over the place.
Exporting methods is safer because you don't give access to class properties. Note also that in javascrpt the concept of class does not have a lot of sense, it's been introduced to make feel more confortable developers with oo languages background. Try to work with Object prototyping instead.
A couple options I can think of, if the methods are intended to be a utility method on another class, you could use handbaked mixins: http://coffeescriptcookbook.com/chapters/classes_and_objects/mixins or rely on something similar in underscore/lowdash
If you want the encapsulation of methods and still have the ability to extend, you can do this:
class Foo
foo = -> alert 'foo'
#static: -> foo()
Foo.static() #=> 'foo'
Foo.foo #=> undefined
new Foo().foo #=> undefined
class Bar extends Foo
Bar.static() # => 'foo'
jsfiddle: http://jsfiddle.net/4ne7ccxk/
This image illustrate the UML I must follow in this project.
The problem is, I don't know what means the private parameter "ator" in the arrow. It should be declared in the class Ator or Personagem? I do know that Personagem is a subclass of Ator.
Because the arrow is unidirectional, you can be sure that -ator should be placed just next to the Ator class. This implies that a private attribute ator exists for class Personagem.
Then, from any method in the Personagem class, you can use some code like this.ator.getId()
I have a class diagram with numerous classes, some of them containing attributes of type string. I want all my strings to be of length at least 1.
The easy (yet ugly) solution is as follows:
context Class1
inv: self.attributeOfTypeString.size > 0
context Class2
inv: self.attributeOfTypeString.size > 0
...
Do you know a way to define an OCL constraints for all attributes matching a template? Something like:
global.select(attr | attr.TYPE = string) -> forall (str : string | str.size > 0)
Finally got an answer from somewhere else. I share it in case someone needs it someday.
There are three possible ways to solve the problem.
1°) The first one is to remember that multiple inheritance is allowed in UML. Therefore, we can make all classes with a string attribute inherit from a WithString class, and set the OCL constraint on this parent class. However this makes the diagrams kinda unreadable.
2°) Another possibility is to create a class String and to store an instance of this class instead of all string attributes. The problem with this encapsulation solution is the performance (use of a getter for all strings).
3°) Finally, the cleanest solution to my opinion is the following: we can declare the OCL constraint at the meta level. In the class diagram describing class diagrams, we can just state that all strings are non-empty.
I'm trying to figure out if this is possible.
I have a class, BaseGameEntity, from this I currently derive NormalDrop and OtherDrop each of which has an instance of a StateMachine< T > where T is NormalDrop and OtherDrop respectively.
From here relevant states can be called that apply to those kinds of drop.
What I want to do is put another layer in, the Drop class, which derives from BaseGameEntity which the other forms of drop then derive from.
Within Drop I want a StateMachine< T > where the "T" becomes NormalDrop or OtherDrop depending on what is using it as its base class.
Is this actually possible?
Yes, you can use the curiously recurring template pattern:
public class Drop<T> where T : Drop<T> { ... }
public class NormalDrop : Drop<NormalDrop> { ... }
public class OtherDrop : Drop<OtherDrop> { ... }
Then within the Drop base class T is always NormalDrop or OtherDrop.
This pattern generally isn't considered developer friendly as upon first glance it is confusing and there are probably better ways to structure code (though possibly not always). Eric Lippert wrote a very good blog post about this pattern and some of its shortcomings here.