Consider two EObjects, both created through some factory method
EObject parent = instantiateAParent();
EObject child = instantiateAChild();
I want child's parent to be parent. Is this possible to do this without relying on the exact type of child and parent? If yes, how?
Yes this is possible. What you want to do is the following:
Retrieve the type (in the Ecore sense) of the parent (parent.eClass())
Find all its EReferences with isContainment to true (eClass.getEAllContainments())
Among these containment references, you want to find at least one whose type is compatible with the type of child (eReference.getEReferenceType().isInstance(child))
Since you may have several containment references at this point, you may use any algorithm to select one (maybe asking the user, etc.)
Set the value of the reference you chose (parent.eSet(eReference, child)). Note that if the containment reference you chose is single-valued, this may have a significant impact on your model.
Related
I am designing a game engine in c++. I am currently working on categorizing the different entities in the game. My base class is SpriteObject that two classes MovableObject and FixedObject inherit from. Now if i for example create an instance of a MovableObject and want to add it to a Vector of Sprite and a Vector of MovableObject i just do:
Vector<Sprite*> sprites;
Vector<MovableObject*> movableObjects;
MovableObject* movingObject = new MovableObject();
sprites.push_back(movingObject);
movableObjects.push_back(movingObject);
But as the different categories and entities grow the code will get large (and it would get tiresome to add every entity to every vector that it belongs to). How do i automatically add an object to the vector that it belongs to when it is created?
EDIT 1: I think i just came up with a solution, what if i just make a global static class Entities that holds all the vector of entities in the scene. Every entity could have access to this class and when a entity is created it just adds a pointer version of itself to the corresponding vector(s) in that global class.
EDIT 2: But i forgot that my solution requires me to still manually add every entity to its matching vector. I just split the work among the different entities.
This is a nice problem.
I think that I would implement it like this: There will be an addToVector() method in Sprite class, and each derived class will override it to add itself to the corresponding vector.
I would suggest a different approach. But before I start I would like to note one thing with your current design.
I would hide the creation of those objects behind a facade. Call it a scene or whatever. Using new manually is bad from a couple of perspectives. First of all if you decide you want to change the scheme on how you allocate/construct your objects you have to change it everywhere in the code. If you have a lets say a factory like Scene you just change the implementation and the calls to scene->CreateObject<Sprite>() will remain the same everywhere else. This might get important once you start adding stuff like custom memory allocation schemes, object pools etc and at some point you will if you will start to grow your engine. Even if this is just an excercise and a for fun project we all want to do this like its actually done, right ;) ?
Now going back to the core - dont abuse inheritance.
MovableObject is not a Sprite. Static Object is not a sprite either. They are that, movable and static elements.
A sprite can be movable or static, so it has a behavior of a dynamic or static element.
Use composition instead. Make a Sprite accepting behavior, or better a list of behaviors. In fact the Sprite itself is just a behavior on a Game object too, it just controls the way it is presented to the user.
What if you had an object that can be attached multiple behaviors like the fact it is a dynamic one, it has a sprite presence on the scene and even more is a sound emitter!
If you add those behaviors to the object you have to create them first. They can, when constructed, decide to which list they should subscribe to.
This is all metaphors for actually a well known system, that is proven to work well and is actually used in most game engines nowadays. Its a Entity Component System.
You object with behaviors are Entities, Components are those Behaviors and each of them is controlled by one system that knows the component and knows how to update/handle them.
Objects in the scene are merely a set of components attached to them that act upon them.
Is there any way to convert a parent object to one of its child objects such that the object retains the same old information (including the old key). I have implemented concrete inheritance. Thanks.
Looking at the Qt doc, the correct way to handle with objects shared between pages is to use QWizardPage::registerField and QWizardPage::field.
I personally think is more simple, since we are under C++, to pass to the QWizardPage(s), in their constructors, a pointer to my shared object, since there's no risk on cuncurrent access on the shared resource. Every QWizardPage change the value of that object safely and it's shared between pages because the pointer location is the same.
What am I missing? Why the need of such methods?
They are different approaches:
With a shared pointer you need a member for each object you want to share, which means you need to change the interface of your classes.
With the field-API you don't change the interface, but it is then not defined in the interface what fields exist. This means you should document them separately. This seems to me is the better way when having a multitude of fields.
Also note the automatic validation by the wizard:
If an asterisk (*) is appended to the name when the property is registered, the field is a mandatory field. When a page has mandatory fields, the Next and/or Finish buttons are enabled only when all mandatory fields are filled.
To consider a field "filled", QWizard simply checks that the field's current value doesn't equal the original value (the value it had when initializePage() was called). For QLineEdit and QAbstractSpinBox subclasses, QWizard also checks that hasAcceptableInput() returns true, to honor any validator or mask.
As you see: it's mainly a convenience feature. And it might save you from recompiling lots of stuff when working with bigger projects.
As you see: it's mainly a convenience feature. And it might save you from recompiling lots of stuff when working with bigger projects.
I have an Action class from which I derive several subtypes. Now, I need to associate some of these subtypes with each other, in a one-to-many relationship. The idea is that some types of Action subtype will make other subtypes available/unavailable (i.e. I also need to create them on the fly). Since in a language like C++ you cannot store type variables the only thing that makes sense is an association of string typenames.
Has anyone met a similar situation? And if so, would you simply use a non-unique associative container like std::multimap and then manually hardcode a huge switch statement for the string-type association?
Example: An action of type Attackwill eventually make Retreat available to its actor, as well as others, like Charge etc. Each action constructor takes at least one Actor reference, but it may also take other, unknown at compile-time, parameters. This last bit makes it very difficult to model this as a decision/action tree... in other words, it seems like I have to build the decision tree during runtime.
I need suggestions on how to solve the type of problems described below. I'm fairly new at C++ and OO-design.
I've learnt:
Pointers shall be avoided when ever they can be replaced by references.
Objects shall have no knowledge of objects that they don't need to know about.
But when creating objects having references to other objects we must pass these references as input arguments to the constructor. Thus we need to know about objects we should not not know anything about.
But look at the following example:
Suppose I have a object "Menu" that needs to have it's own timer object "Timer". I'd like to implement this association as a reference.
The object MenuHandler aggregates a lot of Menu objects but shall not have any knowledge about Timer objects. But when the MenuHandler creates a Menu object it must pass a Timer reference argument to the constructor. Thus, ****MenuHandler** must know about **Timer****.
Any suggestions on how to treat these kind of problems?
I'd hesitate to bless your choice of words when it comes to the two numbered points. They're a sign you're on the right way learning C++, but they might be misleading to other novices. When I take a look at your concrete examples, this becomes more obvious.
A MenuHandler should not create menus. The content of menus is determined by by the application, so the application object (or the Controller part, if you've implemented Model-View-Controller) should create menus. The MenuHander merely takes ownership of menus created elsewhere.
Also, it may make sense to give each menu its own timer. That means the relation can be described as "Has a"; the menu has a timer. The relationship usually implmented by references can be described as "Knows a" (the inheritance relationship is usally called "Is a"). If each Menu object has a Timer, it can be a member, and initialized by the Menu constructor(s). The Timer object internally may obtain a reference to the system clock in its constructor, but that's not your concern.
Why not simply make the Timer object a member (by value) of the Menu class?
I find that I produce better (more maintainable, faster, etc) code and that I'm more productive using references in C++ than I would be solving the same problem with pointers... I think the traditional answer to your example would be to have a factory object that creates menus. In this way, the MenuHandler doesn't need to know about the Timer class.
The MenuHandler creates a Timer object, passes it into the Menu constructor, and forgets about it. That seems entirely reasonable.
If the MenuHandler unnecessarily kept a reference to the Timer, that would be against the advice point #2.
In a more general case where you need to provide a class to another class in order to do some kind of callback, you avoid mutual dependency (both know each other) by using an interface.
Class A derives from the interface. Class B accepts the interface as paramater in the constructor and calls the virtual function from that interface when needed.
Also check the observer design pattern.
For #1 Be very careful with the lifetime of your objects. References are no that suitable to handle dynamic graph of objets ( like your menu, menuhandler, timer, etc... ). What if you want to change the timer object later ?
It's not a good idea to have references as members in a class if the lifetime of referenced objects is not really known.
Avoiding pointer does not mean using references everywhere, you should have a look at smart pointers which will be more suitable for what you want to do.