Curse of inheritance in mvcExpress


release candidate for mvcExpress version 2 released!

I want to use this opportunity to talk about one thing that I am not happy regarding mvcExpress framework, I call it – curse of inheritance!

It is very hard to write this post, as it’s hard to criticize your own creation, but I think it is fair to share both good’s and bad’s to let you know there you are getting yourself into.

In short – extensibility mvcExpress currently is implemented by extending base classes. If you want to add a new feature to framework you will need to extend base classes, this leads to trees of inheritance. Inheritance have some negative effectsyou will have some inconveniences, code duplication and in general writing custom mvcExpress extensions is possible, but not as easy as I would like it to be.

If you just want to use already written extensions – your are in luck! It is very easy to switch extensions(in most cases – just changing class you are extending), and if something goes wrong – framework has some dedicated code to figure out what went wrong. (For instance it will tell you if you are using class that is not supported by current module.)

I have no doubt that composition would support extension creation better, but I want to give my reasoning why in my opinion inheritance might actually work for mvcExpress. (…and I don’t want to follow path  some other flash mvc framework, as I don’t like there it ended)

Seeing problems with inheritance in action, I had to remind myself of my vision for mvcExpress framework. Then I started it over 1 year ago I had 3 things in mind: speed, simplicity, and security. (Extendability was not there..) mvcExpress v1 looked very good, fast, minimalistic and just working for what it was created for. But then I started extending it I saw the problems – it was very hard to extend it. (without hacking it).

I decided to fix it in version 2, but very quickly discovered that I have to change essential things that made it so quick and easy. I decided not to do it, I decided to keep the speed and ease of use, and make some sacrifices that will result in writing extensions only possible,  not necessarily easy thing to do, but, also at same time – keep it easy to use.

Here is example of inheritance tree for two available extensions :


It looks complicated but it really isn’t. Usually you start mvc application by extending ModuleCore. Then you use MediatorProxyCommand classes to construct your application. Lets say you decide to add modular programming features – you just extend ModuleScoped instead of ModuleCore, and you done! You can start using MediatorScoped, ProxyScoped, CommandScoped in places there you need those features. (you don’t need to change your old code that will not use scoping features, they will work fine). This gives possibility to add/remove features just by changing class you are extending, and keep your code base as light as possible.

Sadly this will also lead to same confusion regarding what classes you can use, but framework will help you there! If you by mistake use class that is not supported by current module, MediatorLive for example, framework will throw an error. The only thing you need to do to fix it – is change class you are extending your module from to ModuleScopedLive. This will give you freedom to use: Mediator,  MediatorScoped, MediatorScopedLive, and MediatorLive depending on features you need.

It is also very easy to remove extension – just change class you are extending, fix errors that will pop up because of missing features, and you done.


If you want to create fast and reliable applications quickly by using already created extensions – mvcExpress is the best fit for you!
If you want to have ability to write extensions, mvcExpress might be not the best framework for you. (unless you don’t afraid to get your hands dirty.)

Thanks for your time.

Feel free to comments if you find an error , and in general, let me know what you think about mvcExpress extensions!

18 thoughts on “Curse of inheritance in mvcExpress”

      1. Naebalovo it`s like simple and fast. Like a dat`yoba bb. Greate job with framework, still working with 1.4.2 and trying move to v.2.

    1. What kind of starling support you have in mind?

      mvcExpress is view implementation agnostic. That means that you can use it with whatever you like… flash display list, mobile apps, starling, Away 3d… you name it. (I did/tried all of those.)

      1. Thanks, man. Awesame job done.
        I watch over you closely for last year. Now we are going to give this framework a try.

        PS: don’t ever try to speak with 2 morons. Better del both comments.

        As for inheritance hell. well why are you bothering about extending the framework when the inheritance became real challenge at earlier stages. I always wanted to use multiple iheritance to control behaviour of the object, but onl yone parent forces us to incapsulate all possible controllers into the object. So I have only one grief – you got the only iheritance slot existed for defining the MVC role of the object.
        At this case parsley looks more suitable. Bit for sure, we are going to look into mvcexpress because of speed/

        1. Hi,

          can you explain in more detail what you mean by “inheritance slot for defining MVC role” ? maybe with example, and why it’s important.
          Maybe it is missing feature of mvcExpress, or maybe extension can be created for it.

    1. I is temporal hack? Or something that application design requires?

      Can you specify what exactly you want to do? get mediator object in command?

      I can provide you with extension to do it. (highly unrecommended extension..)

  1. For me dirty mediator is Mediator, that mediated by another Mediator(it is injected in another mediator, map and mediate are called for dirty), but dirty not registred in MVCExpress framework (no map or mediate for it), but important thins he can do – is send message. So, this is some hack, to not create some VC to mediated and send flash Events, that listens some Mediator, and just send directly MVC message from it. What you think about class, that some VC can be extended from, and be able just send MVC message?

    1. Mediator that is mediated by another Mediator? you lost me there…

      I never encountered need for such class in my practice(actually it is first time I hear about it.)

      View class that could send messages directly… ok I can understand that. (to save some performance and not have need for event.)

      Let me research/think about it.

    2. hm… very rough hack would be creating a public variable for function, in the view, then just set it from mediator.

      In view object:

      public var sendMessage:Function;

      in mediator:

      view.sendMessage = sendMessage;

      … if I understood correctly, this will give you hack you want to use.(without code hinting).

      Maybe you can use it until I research the problem.

    3. Hi,

      can you point me there mediating mediators are used, or dirtyMediation? maybe open source library? or example? I fail to find info about it.

      Regarding wish to send messages from view class:

      it is very easy to create little extension to do it, but I want to ask you: do you really need it.

      in most cases – complex view can have its components externalized if you want convenience. So if you have a button inside of view object – just make it public, and add event handler from mediator.

      If you have custom event – consider using signalsExpress, they are dead simple, and 4 times faster then standard signals.

      If you still want to just have ability to fire message from view – please create a ticket in github, with explanation what exactly and why you need it.

      I can create extension for you very fast. (You will not even have to use special function to mediate dirty views, extension can sort it out for you.)

  2. it s funny reading through all comments, I wish there were more practical tutorials & samples to help people got a better understand of mvc mindset.

    I have been using pureMVC before and currently v1.4, but now it come to 2.0 rc3, i found that I lost Commands for a while since I injected proxies into mediators almost all the time.

    1. Hi,
      yes.. creating learning material is in my todo list for a wile now, and it kind of waits for the right time. You can find some info in

      Injecting proxies into mediators is a weak practice… but its not the problem if you use it for read only data time to time… having application logic in mediators instead of commands is very bed practice – application becomes much harder to maintain and scale.

      I want to finish V2 and then think about training material again. In any case – if you have questions feel free to ask!

      Have fun with mvcExpress!

Leave a Reply to Deril Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>