I'm using Acceleo-MTL to generate Java classes. How do I get all my abstract methods from my abstract superclass?
To get simple operations and interfaces, I use this:
[comment]Operators[/comment]
[for (o : Operation | class.getOperations())]
[o.generateOperation()/]
[/for]
[comment]Interface Methods[/comment]
[for (interf : Interface | class.getImplementedInterfaces())]
[for (o : Operation | interf.ownedOperation)]
[o.generateInterace()/]
[/for]
[/for]
Does there exist a getter Method for Abstract methods like you have getImplementedInterfaces() for Interfaces?
This all depends on your metamodel and how to navigate it. IIRC, Class.getImplementedInterfaces() is something that comes from UML, so I'll assume that's what you're using.
Furthermore, what you seem to be trying to do is "retrieve all operations for a given classifier, including inherited ones". There should never be any reason to navigate upon the super-classes and interfaces hierarchy yourself for such needs. In UML, this is done through Classifier.getAllOperations(), which means that you can do everything through :
[for (o : Operation | class.getAllOperations())]
[o.generateOperation()/]
[/for]
If you absolutely need to iterate over the interfaces and super-class(es) yourself, remember that you need to recursively navigate the whole hierarchy : the super-classes and interfaces of your class, the super-classes and interfaces of the super classes of your class, the super-classes ... until the root(s) of the inheritance tree. You'll also have to handle UML's multiple inheritance capabilities and thus solve the potential ambiguities it brings. For that, you'll need to familiarize yourself with the UML model. For instance, retrieving the super-classes is done through Class.getSuperClasses(). Determining if one of these super-classes is abstract is done through Class.isAbstract()... and so on.
A side note that could help you : you can import the UML metamodel in your workspace to have a quick overview of its concepts and how to navigate through it. For this :
Use File > Import...
In the pop-up, navigate to Plug-in Development > Plug-ins and fragments and hit Next
Nothing to change on this page, hit Next a second time
In the filter area, enter org.eclipse.uml2.uml
Double-click org.eclipse.uml2.uml in the left panel so that it appears in the right one.
Hit Finish
You now have a new project in your workspace, named org.eclipse.uml2.uml. You can open the org.eclipse.uml2.uml\model\uml.ecore file to see the UML metamodel.
Related
First, context:
We're developing some applications using QP Framework from quantum leaps.
QP is basically an event manager for state machines.
Our approach:
Since we're using QP, our modules interact with events and signals (classes/structs and enums) except some very specific modules that interact by methods.
Problem:
For those last modules, interfaces are easy, just a collection of all the public methods in said module, however, how about the others? Can we say an interface is a composition of other classes and enumerations?
Since the modules interact by sending/receiving events, both should know what kind of data packets (events) can travel through that interface.
Can we represent an interface like this? or should an interface only be a collection of methods?
edit 1:
Replying to the comments below, I don't want to say the interface had nested classes, but that the interface would define said classes so they could be used as events, but from your answers, seems using signals would be a better approach. (The ADC:: prefix and the name of the interface are not the same, just some bad naming choices, as the package name was ADC and so was the interface)
edit 2:
From the comments and answers below, I had no knowledge of the signal stereotype, so updating the question, I think it would become something like this?
This solves the classes and signals problem, however, the enum remain...
My intention was to say the interface would define this keywords, i.e. the module that implements the interface, should define this enum and their values.
Is this the correct approach?
The interface in your diagram is perfectly legit. UML interfaces do not have the constraints of Java interfaces: they can have operations, attributes, and all kind of associations (btw, the aggregation does formally not add any semantics to associations, and you could safely consider to remove the white diamonds), including composition (black diamond).
However it might not represent what you are looking for: interfaces express a contract. It means that the classes implementing it must provide those attributes and associations, and not that the classes will get all these features by a kind of “inheritance”.
Moreover, I’m not sure if you try to express some complex interface, or just found no better way to represent event consumption/generation. In the latter cse it would be an overcomplex and misleading approach.
For event based design, you may be interested in using signals. Signals are like classes, but there are UML elements to express the ability to process a family of events, and/or to generate events. It moreover facilitates the link between sequence diagrams and class diagrams, as a message can correspond directly to an event instance.
The model per se is legit. However, it's likely not what you intended. The shared aggregation has no defined meaning. See p. 110 of UML 2.5
shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
So unless you define the meaning of them the model has no defined meaning.
If you intend to inherit operations/attributes you would draw an open triangle arrow towards other classes. Enumerations should simply be an attribute (simple association with role).
P.S. As per Geert's comment I notice the nesting too. So you obviously over-define this by adding the (meaningless) shared aggregation. You could represent the nested classes by showing them inside the enlarged «interface». Or you use (as suggested by Geert) the nesting relation (personally I use that rarely, but it's an alternative).
I'm new to Go, and I'd like to know if there's a way in Goland or w/ a CLI tool to list all the types that implement a given interface.
I found a tool called guru that can list all interfaces implemented by a given type, but I haven't been able to make it work in CLI.
You can use Navigate | Declaration or Navigate | Implementation(s) on any type/interface and you'll see a list of interfaces implemented by a type or of types implementing an interface.
You can also use the green buttons on the IDE left side next to their type definitions to perform the same actions.
In Visual Studio, I've created a UML class diagram with a class that realises an interface containing an attribute and an operation as thus:
The operation is automatically replicated to the class, but not the attribute. The MSDN guidelines indicate this behaviour:
When you create a realization connector, the operations of the interface are automatically replicated in the realizing class. If you add new operations to an interface, they are replicated in its realizing classes.
However, this seems counterintuitive to their statement just beforehand, namely:
Realization means that a class implements the attributes and operations specified by the interface.
I'm sure there must be a good technical reason for this (some OO concept like polymorphism or abstraction), but I can't think why it discerns between attributes and operations in this way.
Can anyone give me some insight into this, and perhaps what I should do to get round it (do I add the attributes to the class manually in UML?), as it's resulting in generated code that doesn't compile?
While I don't know for sure, I'd imagine it is because in C# interfaces cannot contain fields, only methods. Having attributes on an Interface therefore doesn't make sense.
Interfaces can contain properties, but these just get compiled to PropType get_PropName() and void set_PropName(PropType value). (Fun fact, trying to declare those methods yourself will generate a compiler error.)
Unfortunately, there is not a nice "out of the box" way of defining properties in UML class diagrams, as they are a language specific feature. I think you have to define a custom stereotype and the templates to generate the code accordingly - faff.
I'm working on a large Asp.Net MVC3 application (>50 views) and we are currently planning on using Unity for our dependency injection framework. For ease of maintenance, I would like to be able to query the assembly to find all of the base types, then register them with Unity.
Based on sample code from the Unity MVC3 Project for registering all controllers, I tried the following code -
var orchestratorTypes = (from t in Assembly.GetCallingAssembly().GetTypes()
where typeof(IOrchesratorBase).IsAssignableFrom(t) &&
!t.IsAbstract
select t).ToList();
orchestratorTypes.ForEach(t => container.RegisterType(t);
When I run the application I get the following error message
The current type, WwpMvcHelpers.BaseClasses.IOrchesratorBase, is an interface and cannot be constructed. Are you missing a type mapping?
If I register the class using individually, as below -
container.RegisterType<IOrchesratorBase, HomeOrchestrator>();
Everything works correctly. Is there a way to do this so that I don't have to register each type individually?
EDIT
Per request, my inheritance hierarchy is
HomeOrcestrator <- IOrchesratorBaseList<LocalModel>
<- OrchesratorBase<LocalModel> <- IOrchesratorBase
The usage in the controller is
public class HomeController : ControllerListBase <HomeOrchestrator, LocalModel>
{
public HomeController() {}
public HomeController(IOrchesratorBase homeOrchestrator) {
this.Orchestrator = (HomeOrchestrator) homeOrchestrator;
}
The LINQ to get the types appears to work. I don't think that's your problem.
You'll get a similar error if you just write
container.RegisterType(typeof(HomeOrchestrator));
and call container.Resolve<IOrchesratorBase>().
In other words, RegisterType(t) is not the same as RegisterType<I, T>().
The real question is, what are you resolving and how do you want it resolved? Your query is finding implementors of IOrchesratorBase. Are your injection constructor parameters of that type? If so, what's Unity supposed to do when 20 types implement that interface?
Can you provide more information on your class/interface hierarchy, constructor parameters, and what you expect/want to happen?
(I'd refactor to change IOrchesratorBase to IOrchestratorBase, BTW.) :)
Edit
Based on the edited question, the problem is that, in order to resolve a HomeController, Unity is looking for a type registration for IOrchesratorBase. It determines the interface type by the parameter types of the constructor with the most parameters.
If you write container.RegisterType<IOrchesratorBase, HomeOrchestrator>() the answer is obvious - Unity will construct an instance of HomeOrchestrator and inject it.
Now, is there more than one type that implements IOrchesratorBase? If so, and you register both of them (explicitly), Unity will use whichever one you register last. That may not be what you want.
If you have multiple controllers, each taking a different interface type in their constructors (with only one implementation per interface), you'll need to figure out what each interface type is and re-run your LINQ registration for each one. That could be done via reflection - find the orchestrators or the controllers.
If you have multiple controllers, each taking the same interface type in their constructors and you want different implementations for each, you've got a problem. You'd have to register named types and determine the names somehow, or something similar.
Unity isn't magic. It can't figure out your intentions.
Addendum
Unity can operate in a convention-over-configuration mode; see Using Unity With Minimal Configuration.
I have two classes that each need an instance of each other to function. Ordinarily if an object needs another object to run, I like to pass it in the constructor. But I can't do that in this case, because one object has to be instantiated before the other, and so therefore the second object does not exist to be passed to the first object's constructor.
I can resolve this by passing the first object to the second object's constructor, then calling a setter on the first object to pass the second object to it, but that seems a little clunky, and I'm wondering if there's a better way:
backend = new Backend();
panel = new Panel(backend);
backend.setPanel();
I've never put any study into MVC; I suppose I'm dealing with a model here (the Backend), and a view or a controller (the Panel). Any insights here I can gain from MVC?
It's time to take a look at MVC. :-) When you have a model-view-controller situation, the consensus is that the model shouldn't be aware of the view-controller (MVC often plays out as M-VC), but the view is invariably aware of the model.
If the model needs to tell the view something, it does so by notifying its listeners, of which it may have multiples. Your view should be one of them.
In a circular construction scenario I'd use a factory class/factory method. I would normally make the construction logic private to the factory (using friend construct, package level protection or similar), to en sure that no-one could construct instances without using the factory.
The use of setter/constructor is really a part of the contract between the two classes and the factory, so I'd just use whichever's convenient.
As has been pointed out, you really should try to find a non-circular solution.
First of all, contrary to what others has said here, there's no inherent problem with circular references. For example, an Order object would be expected to have a reference to the Customer object of the person who placed the Order. Similarly, it would be natural for the Customer object to have a list of Orders he has placed.
In a refernce-based language (like Java or C#) there's no problem, at all. In a value-based language (like C++), you have to take care in designing them.
That said, you design of:
backend = new Backend();
panel = new Panel(backend);
backend.setPanel(panel);
It pretty much the only way to do it.
It's better to avoid circular references. I would personally try to rethink my objects.
panel = new Panel(backend);
You do this in this routine something like
Public Sub Panel(ByVal BackEnd as BackEnd)
Me.MyBackEnd = BackEnd
BackEnd.MyPanel = Me
End Sub
You don't need BackEnd.SetPanel
It is better to use Proxies. A proxy links one object to another through raising a Event. The parent hands the child a proxy. When the child needs the parent it calls a GetRef method on the proxy. The proxy then raises a event which the parent uses to return itself to the proxy which then hands it to the child.
The use of the Event/Delegate mechanism avoids any circular reference problems.
So you have (assuming that the backend is the 'parent' here)
Public Sub Panel(ByVal BackEnd as BackEnd)
Me.MyBackEnd = BackEnd.Proxy
BackEnd.MyPanel = Me
End Sub
Public Property MyBackEnd() as BackEnd
Set (ByVal Value as BackEnd)
priBackEndProxy = BackEnd.Proxy
End Set
Get
Return priBackEndProxy.GetRef
End Get
End Property
Here is a fuller discussion on the problem of circular references. Although it is focused on fixing it in Visual Basic 6.0.
Dynamic Memory Allocation
Also another solution is aggregating Panel and BackEnd into another object. This is common if both elements are UI Controls and need to behave in a coordinated manner.
Finally as far as MVC goes I recommend using a a Model View Presenter approach instead.
Basically you have your Form Implement a IPanelForm interface. It registers itself with a class called Panel which does all the UI logic. BackEnd should have events that Panel can hook into for when the model changes. Panel handles the event and updates the form through the IPanelForm interface.
User clicks a button
The form passes to Panel that the user clicked a button
Panel handles the button and retrieves the data from the backend
Panel formats the data.
Panel uses IPanelForm Interface to show the data on the Form.
I've been delaying implementing the lessons learned here, giving me plenty of time to think about the exact right way to do it. As other people said, having a clear separation where the backend objects have listeners for when their properties change is definitely the way to go. Not only will it resolve the specific issue I was asking about in this question, it is going to make a lot of other bad design smells in this code look better. There are actually a lot of different Backend classes (going by the generic class names I used in my example), each with their own corresponding Panel class. And there's even a couple of places where some things can be moved around to separate other pairs of classes into Backend/Panel pairs following the same pattern and reducing a lot of passing junk around as parameters.
The rest of this answer is going to get language specific, as I am using Java.
I've not worried a whole lot about "JavaBeans," but I have found that following basic JavaBean conventions has been very helpful for me in the past: basically, using standard getters and setters for properties. Turns out there's a JavaBean convention I was unaware of which is really going to help here: bound properties. Bound properties are properties available through standard getters and setters which fire PropertyChangeEvents when they change. [I don't know for sure, but the JavaBeans standard may specify that all properties are supposed to be "bound properties." Not relevant to me, at this point. Be aware also that "standard" getters and setters can be very non-standard through the use of BeanInfo classes to define a JavaBean's exact interface, but I never use that, either.] (The main other JavaBean convention that I choose to follow or not as appropriate in each situation is a no-argument constructor; I'm already following it in this project because each of these Backend objects has to be serializable.)
I've found this blog entry, which was very helpful in cluing me into the bound properties/PropertyChangeEvents issue and helping me construct a plan for how I'm going to rework this code.
Right now all of my backend objects inherit from a common class called Model, which provides a couple of things every backend in this system needs including serialization support. I'm going to create an additional class JavaBean as a superclass of Model which will provide the PropertyChangeEvent support that I need, inherited by every Model. I'll update the setters in each Model to fire a PropertyChangeEvent when called. I may also have JavaBean inherited by a couple of classes which aren't technically Models in the same sense as these but which could also benefit from having other classes registered as listeners for them. The JavaBean class may not fully implement the JavaBean spec; as I've said, there are several details I don't care about. But it's good enough for this project. It sounds like I could get all this by inheriting from java.awt.Component, but these aren't components in any sense that I can justify, so I don't want to do that. (I also don't know what overhead it might entail.)
Once every Model is a JavaBean, complete with PropertyChangeEvent support, I'll do a lot of code cleanup: Models that are currently keeping references to Panels will be updated and the Panels will register themselves as listeners. So much cleaner! The Model won't have to know (and shouldn't have known in the first place) what methods the Panel should call on itself when the property updates.