How can I see the parent classes from this doxygen documentation ?
I need to know which are the superclasses of a specific class (CPImage).
http://cappuccino.org/learn/documentation/class_c_p_image.html
But I'm only able to list che classes.. without knowing relationships between them.
thanks
They/he seem to "forgot" to generate a class diagram (what is possible with doxygen). I only found a diagram for the file reference.
Related
Looking at the inheritance diagram on the API, I noticed that MPxSelectionContext has this template class.
From what I read, If I were to have, multiple manipulators and wanted to use the same context, I could use a template class to reuse my code over different manipulators, is that use correct?
Are there other differences or advantages of using a template class?
Not all MPx classes have a template class equivalent, why is that?
Here's an API example.
Thanks for reading me.
Is there a must that in the UML class diagram, if two classes are not linked, then there cannot have a connection between those classes's lifeline? For example if I have a void function public void sample(actor a) since it's just a parameter so there is no link between two classes, but is it possible that in sequence diagram that that is a link between two to perform certain actions?
I think it can be and I actually found some images to prove it(not too sure if I have misunderstood the images) but my tutor says I'm wrong that there is no link between two lifelines if there is no link between two classes. So I'm not too sure about the answers.
Assuming that by "link" you actually mean "message" (solid arrow), you need an association. A message is equal to an invocation of a class' operation. To be able to do that, the caller must have a reference to the called class - an association.
No , is is not necessary to have association or any other relationship defined explicitly between classes which instances communicate in class diagrams. If you need to depict that instances of specific classes are connected in interaction (communicates) , you can use Collaboration element and connectors. Connector defines communication relationship, but does not define how it is physically implemented. In some cases it can by realized by link of course.
Message between lifelines implicitly defines communication relationship between lifeline's types.
PropertyVersionBase has been marked obsolete for a long while.
Currently, it's the only way to maintain a reference to either Template or DictionaryTemplate, or to either WellLogVersion or DictionaryWellLogVersion, etc.
The confusion with PropertyVersion[Base] is that it was also the base class for e.g. *WellLogVersion, which are fundamentally different from Template classes - a controversial design decision (IMHO) early on in Ocean.
I would appreciate some clarification:
Will this base class eventually be removed?
Will there be a base class for Template and DictionaryTemplate?
Will there be a base class for WellLogVersion and DictionaryWellLogVersion?
In general, where is these class hierarchies going in the future?
(I'd like to tag on a second question: could any base class also expose Droid, pretty please?)
PropertyVersionBase was marked obsolete in 2012.1, but DictionaryPropertyVersion was missed (it was only deprecated in 2012.2). So due to the Ocean stability promise we will keep both in 2013.1 and remove them in 2014.1.
There was no plan for base classes so far (Object is the common replacement base). But we may consider to add specific base classes for 2014.1. This would simplify some of our APIs too where the attached template can be dictionary or continuous template.
Thanks for the suggestion.
Best Regards,
Gaelle
MSDN documentation for classes contain many inherited properties and methods. I think this is clutter and greatly reduces the usability.
For example, take look here, at the BitmapSource class. You can't really see what's special about this class. Everying is inherited, inherited, inherited.
It think that if something is inherited then it should be doucmented at the BASE class. So if a Mamnal BreastFeeds and a Dog Barks, I would go to the documenation of Mammal for breast feeding (anyhow, to read about it :), and for that of Dog for barking. Of course, if something is over-ridden, it should also appear at the derived class's documentation such as in BitmapSource.Height.
So: Is there a way to view MSDN documentation hiding the inherited clutter? Some variation on the Url, a switch, offline help, a utility?
OK, found the solution: Visual Studio's Object Browser. SO much more understandable!
I'm having trouble finding the standard way a class diagram should be drawn for objective C applications. Mostly:
Do I incude field types or just the var name?
Do I include method return types and parameters?
Thank you!
Many of the Objective-C diagrams I have seen do not include types or parameters. Only the field and method names are placed in the diagram.
However, I would strongly encourage you to include all this information, regardless of what the norm may be. By doing so, the class diagram is not only useful for modelling, but also serves as documentation. It's not particularly difficult to add the type annotations, and the end result is a far more complete (and useful) picture of the class.
Document them the same way you would document a class in any other object oriented language. Class properties should include the field type, property name and multiplicity. Class methods should include return types and parameters.