I have an app with my own - user defined class and I also use Qt framework libraries to initiate objects of other classes that are built-in. So in my class let's call it 'myclass' I create instances of Qt built-in classes and work on them. THIS IS DONE ... Now, I need to create class diagram for that. I was wondering to which out of Association, Aggregation, Composition or Generalization this could this be classified as ?
Thanks
It is not generalization as you are not inheriting in here, so it cannot qualify as an "is-a" relationship.
As for association, composition or aggregation... here you can find a pretty good explanation which is which. It is not possible to tell the right one for you without knowing your use case better. However, reading the other link will help you to understand the differences and judge based on your scenario.
Difference between association, aggregation and composition
Hope that helps.
The important thing to keep in mind about UML is that there's often no actual right or wrong answer when deciding on what to use, but some tools are better than others. UML is simply a tool for communication and as long as the tool is used in a way that everyone understands what is being communicated, then it serves its purpose.
For a class diagram, at its most basic level, you could actually model everything with just Association and Generalisation, but then this would lack detail that others may want to see.
Generalisation has a one to one relationship with inheritance, so it's clear when to use that.
Association describes any class with a relationship or dependancy with another class; quite a generalisation there(!) which is why it could be used in replacement of Aggregation and Composition.
Aggregation is used when an object (B) makes up another object (A) and B can be shared amongst other objects. For example, a library consists of books, so a book could be modelled as an aggregate of the library because other classes, could also aggregate a book, such as the person borrowing it.
Use composition when an object (B) is used directly to make up an object (A). In this case, if you were modelling the human body and had classes of organs, you would model a heart class as a composition object of a body class.
The fact that you're using the Qt framework is irrelevant to what you use to model your classes and a diagram doesn't need to model everything, just what is necessary to communicate concepts to others.
If, for example you're using container classes such as QList and QMap, you probably don't even want those in the diagram, but if you were to use QTcpSocket and inherit from it, then it may be better to show that.
Just remember, it's all about what you're trying to communicate.
Related
Is it ppssible to implement a concatenative inheritance or at least mixins in C++?
It feels like it is impossible to do in C++, but I cannot prove it.
Thank you.
According to this article:
Concatenative inheritance is the process of combining the properties
of one or more source objects into a new destination object.
Are we speaking of class inheritance ?
This is the basic way public inheritance works in C++. Thanks to multiple inheritance, you can even combine several base classes.
There might be some constraints however (e.g. name conflicts between different sources have to be addressed, depending on use case you might need virtual functions, and there might be the need to create explicitly a combined constructors).
Or is inheritance from instantiated objects meant ?
If it's really about objects and not classes, the story is different. You cannot clone and combine object of random type with each other, since C++ is a strongly typed language.
But first, let's correct the misleading wording. It's not really about concatenative inheritance, since inheritance is for classes. It's rather "concatenative prototyping", since you create new objects by taking over values and behaviors of existing objects.
To realize some kind of "concatenative prototyping" in C++, you therefore need to design it, based on the principle of composition, using a set of well defined "concatenable" (i.e. composable) base classes. This can be achieved, using the prototype design pattern together with the entity-component-system architecture.
What's the purpose
You are currently looking for this kind of construct, probably because you used it heavily in a dynamically typed language.
So keep in mind the popular quote (Mark Twain ? Maslow ? ):
If you have a hammer in your hand, every problem looks like nails
So the question is what you are really looking for and what problem you intend to solve. IMHO, it cannot be excluded that other idioms could be more suitable in the C++ world to achieve the same objective.
I am using vibe.d to generate some REST interfaces from classes. However, vibe.d requires me to provide both interface and class implementing this interface. My application is small and contains only one implementation of this interface, and it is very annoying to edit both places when I want to make some changes.
So the question is: is there any mixin or template that can generate interface from given class definition? This should be quite possible to implement, but I was not able to find any examples. std.typecons has WhiteHole and BlackHole to autoimplement interfaces, but I want something opposite to them.
Thank you.
It is possible to write such mixin but that will create a circular dependency issue - being able to generate an interface but not to inherit class from it. One possible workaround is to use new std.typecons.wrap to do it in 3 steps:
define actual class
generate interface from it
create a wrapper class that maps actual one to interface via std.typecons.wrap
Actual implementation of such mixin is somewhat straightforward if you are familiar with D metaprogramming techniques. It boils down to iterating through all method of the class and appending bare method declaration to result string which can be later mixed in. Cloning funcion declaration can be done via this neat helper present in vibe.d internals : cloneFunction
Exact code is a bit too long for a StackOverflow reply but I will be happy to provide detailed explanations to any specific questions about it.
That said, I tend to agree that requiring both interface and class is unnecessary limitation and it should be possible to work with bare classes. Eventually I am going to implement it but it will require quite a lot of changes in module code and is somewhat low-priority comparing to some other present issues in my TODO list. Sorry for the inconvenience.
I have a question concerning good programming style. I have a group of methods that is handling the flow of my program. These functions uses objects from another class. Is it fine to make a class called something like Functions and list these functions I have there? Not a single instance would be created of this class. Should I rather not include these functions in a class at all? Basically they do stuff like opening the Main Menu and alike.
Not sure if this is a stupid question, I couldn't find any similar topics on this forum. I'm not asking how to do this, rather how to handle it regarding style.
Thanks a lot in advance.
This is exactly what namespaces are for. Don't try to wedge things into "the OOP way" when they don't fit. If your design says that you'll never create an object of a class type then it's not a class, just an agglomeration of functions.
While reading your question, I instantly thought about the Math class in Java (not sure what is the C++ equivalent). You probably know it, it is basically a collection of math operations. Math class
In my opinion, the kind of class you're talking about in your question must have a "collection of general functions" objective, similar to the Math class. Things like opening a menu should be a method of that menu or that menu's parent.
On the other hand, things like calculating some values using specific objects from your program or formatting elements following a customized pattern should be gathered in a "static" class in order to make that class an utilitary tool in your program.
Math operations are very general functions that can apply to any program. Try to transpose this concept within the context of your program! ;)
Put them in a class as static functions for now. You may realize later you'll have some commonality... perhaps state? Storing that in the class might make sense. And you'll want to check things there perhaps before calling your other objects... before you know it, you'll remove your static aspects and instantiate your own object. Perhaps even later consider multiple threads and several of these objects. You get the idea... leave yourself room for an object-oriented approach...
'm developing a 2D game and I want separate the game engine from the graphics.
I decided to use the model-view pattern in the following way: the game engine owns game's entities (EnemyModel, BulletModel, ExplosionModel) which implement interfaces (Enemy, Bullet, Explosion).
The View receives events when entities are created, getting the pointer to the interface: in this way the View can only use the interface methods (i.e. ask for informations to perform the drawing) and cannot change the object state. The View has its onw classes (EnemyView, BulletView, ExplosionView) which own pointers to the interfaces.
(There is also an event-base pattern involved so that the Model can notify the View about entity changes, since a pure query approach is impraticable but I wont' discuss it here).
*Model classes use a compile-time component approach: they use the boost::fusion library to store different state componets, like PositionComponent, HealthComponent and so on.
At present moment the View isn't aware of the component based design but only of the model-view part: to get the position of an enemy it calls the Enemy::get_xy() method. The EnemyModel, which implements the interface, forwards this call to the PositionComponent and returns the result.
Since the bullet has position too, I have to add the get_xy method to Bullet too. BulletModel uses then the same implementation as the EnemyModel class (i.e. it forwards the call).
This approch then leads to have a lot of duplicate code: interfaces have a lot of similar methods and *Model classes are full of forward-methods.
So I have basically two options:
1) Expose the compoment based design so that each component has an interface as well: the View can use this interface to directly query the component. It keeps the View and the Model separated, only at a component level instead of a entity level.
2) Abandon the model-view part and go for pure component based design: the View is just a component (the RenderableComponent part) which has basically full access to the game engine.
Based on your experience which approach would be best?
I'll give my two cents worth. From the problem you're describing, it seems to me that you need an abstract class that will do the operations that are common amongst all of your classes (like the get_xy, which should apply to bullet, enemy, explosion, etc.). This class is a game entity that does the basic grunt work. Inheriting classes can override it if they want.
This abstract class should be the core of all your interfaces (luckily you're in C++ where there is no physical difference between a class, and abstract class and an interface). Thus the Views will know about the specific interfaces, and still have the generic entity methods.
A rule of thumb I have for design - if more than one class has the same data members or methods, it should probably be a single class from which they inherit.
Anyway, exposing the internal structure of your Model classes is not a good idea. Say you'll want to replace boost with something else? You'd have to re-write the entire program, not just the relevant parts.
MVC isn't easy for games as when the game becomes larger (including menu, enemies, levels, GUI...) and transitions, it'll break.
Component or entity-system are pretty good for games.
As a simpler case for you, you may consider using a HMVC. You'll still have issues with transitions, but at least your code will be grouped together in a more clean manner. You probably want your tank's code (rendering and logic) to get close together.
There have been presentation architectures designed especially for agent-based systems, such as Presentation-Abstraction-Control. The hard part in designing such a system is that you ultimately end up hardwiring sequences of collaborations between the agents.
You can do this, but don't use OO inheritance to model the message passing hierarchy. You will regret it. If you think about it, you are really not interested in using the OO inheritance relationship, since the interfaces defined are really just a "Record of functions" that the object can respond to. In that case, you are better off formally modeling your communication protocol.
If you have questions, please ask -- this is not an obvious solution and easy to get wrong.
I wish to follow the Single Responsibility principle in C++. However, as I break up classes, it seems that in order for classes to "see" each other, I have the following choices:
Add many more accessors for each class
Make classes friends of each other
Improve the design (maybe the fact that I would have to do 1 or 2 indicates a flaw in my design)
The friend vs. accessors issue has probably been discussed before, but I did not know if one was more advantageous with regard to implementing Single Responsibility.
I've always thought that rule was BS. Most classes have several responsibilities, and no harm done. Consider a bank account class - it might have the responsibilities:
maintain client details
allow for debit & credit transactions
provide current balance
report dubious transactions to security
Of course, these responsibilities will probably be implemented using other classes that the account is composed of.
If you must expose private data from one class to another, than make the second class a friend. Creating an accessor for your private data defeats the purpose of making it private in the first place. The single responsibility principal has no bearing on this.
Edit
In response to Dima's comment below, perhaps I went a little too far in saying "the" purpose. There are, after all, more than one reason to make data members private. One reason, as Dima notes, is to protect the integrity of the object. Accessors do accomplish this.
But a second (and more important, in my opinion) reason is to hide the class's implementation details. Once you've added public accessors, you've lost control over how many other classes reference your class's implementation details. Over time, this can make it extremely difficult to modify your implementation because of the cascading effect on other classes.
Friend classes, while far from perfect, at least give you strict control over how many classes will be affected by your changes. Another benefit is that when you do make changes, you know exactly which classes might be affected. Thus, they're a better option when you must share your class's internals. But the best option of all (of course) is not to not expose implementation details at all.
Now that you have a group of classes that all need to work together, you should consider how they should work together. If it's via accessor functions or friends, then you're tightly coupling the classes. It would be difficult in the future to drop in a new class that does something different. It's also difficult to test the classes since they're all inter-dependent.
Consider creating an interface class(es) that defines how your classes should communicate. Unless there's some special privileges involved, this interface will also define how anyone else would communicate with them. This way, you break the classes' inter-dependency. Any future changes are localized to the class involved. Nobody else has to change (or maybe even recompile).
You also have option 4: add more classes to represent the different roles/interactions between the classes.
That at least falls more in line with the Law of Demeter.