What's is the difference between mixin and extend, when to use each one?
I wrote this article about Ember.Object which explains the differences in detail. Essentially, use extend to create a new class from a base class and use mixins to separate lateral concerns that you may want to include in any number of classes / objects. Mixins can be included in classes via extend or objects via create.
A mixin is a special kind of multiple inheritance. There are two main situations where mixins are used:
You want to provide a lot of optional features for a class.
You want to use one particular feature in a lot of different
classes.
Related
I'm working on a small Django project and I noticed there are different ways to write a view.
What's the difference between a view created with a class and a view created with a function?
When should I use which one?
Thanks!
It has all the same differences that are between Procedural Programming and Object Oriented Programming. It makes sense to write functions for extremely simple views, but not beyond that. There is nothing worse than stuffing 400 lines of code into one big function called view, which becomes a nightmare to read, refactor or test.
In addition to that, Django generic views exploit Template Method design pattern and provide a lot of already written common code for generic use cases, which can often be easily extended to one's needs.
The most important advantage of using a class based views is inheritance.
When working on a big projects, its highly possible to come across multiple views which have similar use, hence you can inherit a class based view to write a new more specific view which is custom to the required method, or you could just reuse the already defined view as is if it serves the purpose.
Generally the function based views are used when the class based views become too complex to implement.
If you are working on a small project you could just use function based views as it will appear to you that the class based views are little more painful to write (At least i felt like it).
The question applies to the class QGraphicsView of the qt library.
However, the problem is more general. So, if I am not missing any special mechanism in qt, it can probably be discussed without knowing qt.
I am subclassing QGraphicsView to add some features that I need.
E.g. I have a ScalableView, PannableView and LabeledView to add independent functionality.
The sublassing I use for now is linear in the following sense:
ScalableView is derived from QGraphics view.
PannableView is derived from ScalableView view.
LabeledView is derived from PannableView view.
Since those features are independent, there is a design flaw.
Applying the decorator pattern to come around this seems appropriate for me.
The problem there is, QGraphicsView is not an interface and there exists no interface class like QAbstractGraphicsView. So, for me it is not clear how that pattern could be implemented.
A different idea would be to use templates. So I could derive each of the views from a template T. Then, I could make insantiations like ScalableView<PannableView<LabeledView>>>.
Do you see any better solution to that? I would prefer a way to implement the decorator pattern in this situation, since I would like to avoid to many template classes that would increase compilation time.
A simple solution in Qt style would be to create a class that derives from QGraphicsView and simply has flags that control its behavior (whether it's scalable, pannable, labeled, etc.). The implementations of those behaviors would still be split into methods, so it's
not as monolithic as it seems.
The decorator pattern can be of course easily implemented by defining an intermediate (shim) interface. The QGraphicsView does not need to implement that interface - the interface is only for the decorators to use.
The problem with deep inheritance is that it's impossible to finely control the interaction of the behaviors. The only control you have is the order of event processing. This may happen to be sufficient, but it has me somewhat worried. The decorator pattern implemented without embellishment shares this issue.
Without knowing the full design, this may or may not work, but perhaps this will help.
One possible method would be to encapsulate the QGraphicsView and create delegate objects that provide the different functionality that you require. The delegates would then be responsible for providing the interface to the graphics view and forwarding messages.
This would mean creating a different delegate for the different types of functionality; a ScalableDelegate, a PannableDelegate and a LabeledDelegate.
As the delegates are separate objects and not inherited from the QGraphicsView, you can gain a lot of functionality from installing event filters on the graphics views.
Then, instead of objects interacting with your GraphicsView, they communicate via the relevant delegate.
If this is too restrictive,you may need to inherit from QGraphicsView to create a view with the functionality you need and then use the delegates to expose the required functionality as desired.
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 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.
I recently had a django question - and one of the answers left me stumped:
https://stackoverflow.com/a/10608687/1061426
I've read the django doco, but cannot quite work out how mixins are relevant to what was asked, or what the answer is referring to.
So, I searched for "django mixin tutorial" and stumbled across something called dajax and dajaxice. Ok, i am lying, i came across this blog:
http://www.pythondiary.com/blog/Apr.15,2012/stay-tuned-django-ajax-tutorial.html
My question is:
What are mixins? How do they relate to ajax calls? Are they used for things other than ajax? Why would i want to use dajax or dajaxice or some other django addin framework, rather than just plain django to work with ajax?
Also, there isn't a dajax tag, but there is a dajaxice tag for stackoverflow... does that mean that dajaxice is The Way To Go?
Cheers,
Mixins are a general Object Oriented Programming concept. They don't specifically have anything to do with Django or Dajax, etc. However, Django does, and Dajax probably as well, use mixins.
In general, a "mixin" is simply a class that is meant to literally be mixed in with another class. It typically doesn't do anything on its own, but rather, merely adds functionality to another class. Django's concept of "abstract" models are an example of a mixin. You never instantiate an abstract model. Instead, other models inherit from the abstract model, gaining all of its functionality, and it's those subclasses that actually are instantiated.
Django's class-based views (which is what the answer that brought you here is talking about) also use mixins. For example, most of the class-based views inherit from TemplateResponseMixin. This class is not a view itself, and you would never use it for anything but for a class-based view to inherit from. It's merely an encapsulation of all the functionality that renders a template into a response, so this functionally can be "mixed in" to all the various views without violating DRY (Don't Repeat Yourself).
No, mixins don't have anything in particular to do with Ajax.
A mixin is just a class that can be used as part of the multiple inheritance for another class. Django uses these extensively in its class-based views - some classes provide (for example) the basic functionality for displaying forms, or lists of models, and you are meant to mix those in with your own classes: create your own code that implements your own extensions to that functionality, while inheriting from one or more mixins.
I've never used Dajax, but I suppose it also uses mixins to provide the basic implementation of the Ajax handling within your views.