Today on Twitter, Robert Penner posted a couple of really interesting links…
http://theshyam.com/2009/08/is-inheritance-overrated-needed-even/
and
http://code.google.com/p/noop/wiki/ProposalForComposition
This got me in a researchy mood about inheritance vs. composition, and I dug up this great series of interviews with Erich Gamma (one of the original Design Patterns Gang of Four):
http://www.artima.com/lejava/articles/gammadp.html
http://www.artima.com/lejava/articles/reuse.html
http://www.artima.com/lejava/articles/designprinciples.html
Actually, the last one had the info I was more looking for, but the first two are chock full of interesting data and viewpoints. This post is about some of the data in the second article on flexibility and reuse. Gamma talks about three levels of code reuse:
1. Reuse of “classes: class libraries, containers, maybe some class “teams” like container/iterator.”
2. Design patterns.
3. Frameworks.
He goes into a lot of the pitfalls of frameworks. A lot of this really rung true to me.
A key challenge in framework development is how to preserve stability over time. The more miles a framework gets the better you understand how you should have built it in the first place. Therefore you would like to tweak and improve it. However, since your framework is heavily used you are highly constrained in what you can change.
And near the end of the article he talks about “frameworkitis”:
Frameworks abstract and provide higher level default functionality. To do so the framework needs to be in control. This loss of control can lead to what is sometimes called frameworkitis.
…
Frameworkitis is the disease that a framework wants to do too much for you or it does it in a way that you don’t want but you can’t change it. It’s fun to get all this functionality for free, but it hurts when the free functionality gets in the way. But you are now tied into the framework. To get the desired behavior you start to fight against the framework. And at this point you often start to lose, because it’s difficult to bend the framework in a direction it didn’t anticipate.
That really hit home. This is one of the big reasons I don’t dive into Flex more. Yes, you get a whole lot of functionality for free, but who has not fought against the Flex Framework?
I’ve also felt this quite a bit in the cocos2d framework for iPhone. Don’t get me wrong, it’s fantastic in terms of the free functionality you get, and I can’t think of a better way to get started in 2d iPhone game building, but eventually you do wind up trying to bend it to do something it didn’t anticipate. I spent half a day yesterday doing just that.
And although I’m not working with it personally, I think that some of the projects my company is working on are running into the same general thing with Unity3D.
Recently I’ve been doing and researching a lot about game development on both the iPhone and in Flash. So I’ve looked into some of the game frameworks that have sprung up for Flash, like flixel and the PushButton Engine. I looked more into flixel then PBE, but I can’t claim to know much about either one. But what turned me off about both of them was that very same fear of eventually getting a case of frameworkitis. If you look at the features of both, they contain a laundry list of items such as tile maps, physics, particles, rendering engines, pathfinding, AI, collision engines, sound and asset management, on and on.
While I’m sure this will get you up and running quick, I feel like before long, you’re going to be fighting against it in some way or other. PBE markets itself by saying you can build “modular pieces of gameplay instead of monolithic applications” and integrate your own libraries easily, so that may not be that bad. But Gamma also says, in the same article:
Because the bigger the framework becomes, the greater the chances that it will want to do too much, the bigger the learning curves become, and the more difficult it becomes to maintain it.
My feeling is that these frameworks just try to do too much.
I’ve been slowly working on making my own game framework – abstracting out pieces of commonly used functionality, making them reusable, and packaging them together. One strong feeling I’ve had about it though, was that I wanted it to be lightweight, and every piece be optional. After reading this article, I discovered that what I really wanted to build was a game toolkit. A toolkit would just be a set of building blocks that you can use as you see fit. Gamma has this to say:
Toolkits do not attempt to take control for you and they therefore do not suffer from frameworkitis.
…
With toolkits you create and call toolkit objects and register listeners to react to events. You’re in control. Frameworks try to be in control and tell you when to do what. A toolkit gives you the building blocks but leaves it up to you to be in control.
…
Also, if we do frameworks, we try to make them small frameworks. We prefer many small frameworks over one heavyweight framework.
…
If you really want to take the risk of doing frameworks, you want to have small and focused frameworks that you can also probably make optional. If you really want to, you can use the framework, but you can also use the toolkit. That’s a good position that avoids this frameworkitis problem, where you get really frustrated because you have to use the framework. Ideally I’d like to have a toolbox of smaller frameworks where I can pick and choose, so that I can pay the framework costs as I go.
This all made a whole lot of sense to me and gave me a lot more direction on where I want to go with my frame… er… toolkit. 🙂
Anyway, even if that all doesn’t interest you, read the three articles above. Fantastic insights to be had.
Very good points! I also tend to prefer thinking in terms of toolkit than framework.
Making something successful depends on its context. An excellent framework will be a major disaster in some projects. You can create the right context for a toolkit and apply it in a certain way, whereas in a framework this its applicability is inherintly dictated.
Thanks Keith!
I believe everybody should write their own framework and keep it for themselves! Would that be desirable?
An interesting distinction (and a great point about API design).
Sometimes you do want to give control up to a framework.
Often, though, that’s a terrible idea. 😛 I actually mean it when I describe PBE as modular. Some pieces do build on each other. But look at the Box2D integration (for example). It’s really just plugging in naturally to the system. Each piece is really orthogonal. You can take it or leave it. Use our time management or not. Use our serializer or not. Use our spatial system or not.
Compared to Flixel which is simpler but much more of a traditional framework which dictates how everything should work.
Of course, the curse of any middleware provider/framework developer is that the userbase will demand that the middleware expand to fill all roles. Most users hate it when you tell them to fill in the blanks. I think you’ll find that even your own toolkit will eventually dictate how everything works if you let it!
Would you describe the windows SDK as a framework or a toolkit? What about Apple’s WebKit?
GOF has some good thoughts but sometimes I think they encourage semantic hairsplitting.
Yes, good analysis!
To be fair, in my entire programming career, I have only met one framework that didn’t make me feel trapped: the Visual Component Library (VCL) that come with Delphi. By just looking at the code you can appreciate the sheer elegance of its design and even if it was in control of your application it was designed with expandability in mind as well as providing access to lower level API when necessary. It never felt underpowered and the thousands of components created to expand it, witness the “intelligence†underneath; nobody ever felt it was the case to create a new framework.
Lack of forward thinking is the major problem of far too many frameworks I see today. On the other hand, I see us programmers getting lazier more and more and I frequently come across applications that include “glib.h†with its ton of code, when the application just need a doubly linked list of pointers. True, it is not necessary to reinvent the wheel every time, but at least knowing that you only need 6 bolts to fix it rather than a 1,000, can avoid costly trips to the hardware shop!
Very good post.
Ben, as I said, I hardly looked into PBE. My gut reaction was that because it DOES EVERYTHING that it would wind up dictating how you do everything. But I see that the description on the site, and the description you give here really does stress the modularity.
It’s a good point about the user base demanding everything and not wanting to fill in the blanks. Makes me think of GoASAP, which forces users to fill in the blanks, as opposed to other tween engines that do everything for you. Go gives you a lot more flexibility, but hasn’t really caught on.
And yes, that even if you call it a toolkit, as it expands to fill all the blanks, I think there winds up inevitable points of dependency, where you need to use tool X if you are using tool Y, and tool X requires you to use tools A, B, and C. Eventually, a toolkit that tries to cover all bases winds up becoming a framework with its resulting inflexibility.
And at any rate, I am not trying to come across as a framework hater. There are plenty or projects that I wouldn’t consider doing without Flex. I actually really enjoyed working with Cairngorm on a couple of projects I did this year. Tons of praise for cocos2d. It’s just a matter of knowing those limitations and intelligently choosing what framework you are going to use, if any.
I guess this is also a message to other developers out there creating frameworks. Seems like everyone wants to create a framework these days. Just consider making a toolkit instead! 🙂
“This is one of the big reasons I don’t dive into Flex more. Yes, you get a whole lot of functionality for free, but who has not fought against the Flex Framework?”
Having spent 3+ years developing applications in Flex, yes sometimes I’ve fought against some quirkiness but I don’t really think of Flex as a framework, more a component set or toolbox. I don’t feel like it dictates how an application should be built from an MVCS point of view. Which is not the case when you talk about an application framework such as PureMVC. That dictates how an application should be built. Also you can easily choose not to use certain things such as states and transitions. I’ve easily adapted other animation engines in place of the transitions that normally go hand in hand with states so I don’t feel like it gets in my way.
Turning around the argument for why you didn’t get into Flex, how many of us have fought against the Flash “framework”. You were fighting the 3D matrix stuff last week weren’t you? 🙂 At least with Flex, I have the source code and can find out what’s going on behind the scenes. Sometimes when I’m using the flash.display.* package I wish I could see what the source code was doing. Do you consider Flash a framework? I think the term gets used loosely. I agree with your main point but I guess I found your comment regarding Flex interesting. Personally I think Gamma’s points apply more to application frameworks like PureMVC, Cairngorm, etc. Those definitely have a strict way of doing things which can quickly get in your way when you want to break their “rules”.
Or maybe Flex is a framework but fortunately I’ve been able to extend and substitute parts of it.
So Keith is PureMVC a small Framework or not? i use it and feel that it help of lessening frameworkitis opposed to Carnigrom. From a AS3 development perspective.
What you say?
tambi, I’ve not used PureMVC, but from my understanding of it, yeah, it’s a framework.
And I feel the need again to say that I’m not trying to make “framework” a dirty word. 🙂
Phil, good point on the fact that a framework helps a large team coordinate. Sometimes flexibility can be problematic. 🙂
My co-workers and I have had the toolkit vs. framework discussion as well. Most of the time we’ll lean toward our in-house toolkit for smaller projects but when we need to dive into a large-scale app, a framework like PureMVC has proven invaluable. Due to the size and scope (as well as insane deadlines) we usually have to throw more than a few developers in the trenches. Having a framework that dictates how things should be done provides some sanity when we’re constantly shifting back and forth in a sea of code.
Granted, the learning curve can be fierce but we’re all writing similar code and always know where to find something. As the team grows so does the value of using the framework.
Tim, Flex is a framework in every sense of the word. Look at the minimal code you need to write to stick a label on stage. You have to make an application class that extend’s Flex’s Application class, which in turn pulls in about 150 kb of other classes, including style managers, cursor managers, skinning support, collections, effects, layout, logging, and messaging. If it were a toolkit, I could theoretically just add a label and get only the label class, a few inherited classes, and maybe some styling stuff.
But again, I’m not bashing Flex, and just because I’m saying Flex is a framework doesn’t make it bad. There are all kinds of projects where its benefits FAR outweigh any inflexibility that comes with it. If you’re building a large application, you’re going to need all that extra stuff, and be glad you have it. My understanding is that one of the goals is to eventually make Flex more modular, which would move it more into the toolkit realm. I’d like to see that.
So how much code is pulled in is what defines a framework? If a set of components is written and you instantiate one of them and it pulls in lots of extra cruft, is that component set a framework? I think my my point was that you don’t have to use everything in Flex so sometimes I think of it as a toolkit. You can write your own popup manager, your own transition manager, etc. Yes, it’s not modular and pulls in lots of extra stuff you don’t need. I’m not pushing it either, I just thought it was an interesting topic. The entire framework vs toolkit is grey when it comes to some projects.
I meant to say “my main point”. I’m typing is stuttering today 🙂
I’m going to stop typing now…
No, the point is not how much code is pulled in. The point is that to even use a label you have to create a class that extends a framework class. And in fact, that class is not even your document class, but gets instantiated by the SystemManager after it creates the preloader. It’s not just pulling in stuff, you are actually instantiating a whole framework of classes and your app becomes a Flex Framework app.
Another way to look at it is in terms of dependencies. In the 3rd article, Gamma talks about how easy it is to add dependencies to a project, but it’s not always easy to remove them. If I add a single Flex label to my project, my project is almost irreversibly dependent on the Flex Framework. However, if I use a Minimal Component Label and later decide to switch to a CS4 Label, it’s relatively trivial to change them. The dependency is minor. I think that’s a better way to think about the differences between frameworks and toolkits.
I love Artima. A great site that was a lot more active in the early Java days.
While some of this discussion is specific to frameworks, it feels like some of it is just about abstractions in general: http://www.joelonsoftware.com/articles/LeakyAbstractions.html
the problem with the toolkit approach is you want some things not to be optional. For example you may want to clean up even handlers, or dispose objects in certain ways, or always have a list of visible/total objects, etc etc. If people optionally go outside the framework to create these things, you are never sure of your world. Its like static typing with optional dynamic variables.
I usually go with a strict framework for low level stuff, and then plugable things for the extras (preloaders, tween libs, components etc).
Having worked for a year in Eclipse IDE code, I don’t think I would ever look to Erich Gamma for advice on software design. I understand that may be the way some people think, but it is very totally moronic in a lot of places (for me at least, but others too).
A framework is good if it can be used along side other frameworks… the arrogance of most frameworks is they assume that they are the only one. One aspect of 3D engines an tween engines is they are less likely to assume this and are therefore very popular. For instance I like ASAP Library for its tween functionality, syntax sucks and I am yet to look at other aspects, but it is a good framework because someone showed me a good part and I can use just that part.
As a long time composite exponent I must go back and read the Penner links.. he is a legend after all.
“A framework is good if it can be used along side other frameworks..”
I don’t know, I think that is like saying planets should be able to live on other planets I think… at one point the framework is there to restrict you in a way that is useful. Having two kind of defeats the purpose.
I think tween engines are more ‘toolkits’ though, so maybe it is just our definitions being crossed : )
To summary my understanding and preference for composition over inheritance, and as you know I am not a high level coder, and post ideas so they can be corrected… Tink is of the view that anything visual should inherit from a visual object, hopefully that quote is correct.. but my take is that you should inherit if an item is similar… for instance as2 early papervision had many levels of inheritance.. but the current version has less, its just too hard to make optimal code with really tight inheritance structures, and I am not even talking about one time everyday non optimal code. For instance if I have created a basic video player and I just want to add volume control then inheritance makes a lot of sense, or to extend a generic XML parser for specific application… but I sometimes wonder if when creating a “Rabbit’ is it as valid to extend MovieClip, I am exposing a multitude of control that may not be relevant to a Rabbit class, and control I may not want a user to abuse without some thought, often I want just enough control to put the rabbit on screen but expecting a developer to search through 7 layers of classes just to get him to hop seems absurd, but composition explicitly defines the methods and properties of a class in a much cleaner way, I can pass a movieclip of a rabbit to my Rabbit class.
The current application domain used in AS3, for me actually favours composition, normally code is not heavy in comparison to designers graphics, so it makes a lot of sense to have a code preloader and a graphics loaded movie sharing an application domain… now flash classes are outside application domains.. so to put any inheritance into a symbol in the graphics loaded movie will mean any code changes will required “cross” compiling.. my word for compiling both the code movie and graphics movie ( cross compiling.. – having to recompile multiple movies due to a change in just one). So for very little additional effort it makes more sense to composite sprites and movieclips to reduce compile. Further the haXe compiler is faster so coding in haXe with runtime loaded flash swf full of graghics works best – but maybe I am biased! 🙂
Been trying h a X e g u i recently and I must say that there is some stunning code in there, but currently I find myself working against it, purely because I want to use flash skins and _up label assumed states and not the runtime code states it assumes and the lineTo runtime scripts, and I dont have enough time to work all its ins and outs… so I am wondering for my limited use should I abandon Frameworkitis, but with modern timescales there is not time not to use some frameworks or probably better toolkits.
So frameworks toolkits are needed but they are best, when they do not assume they are the only trick in town.
Robin
Frameworks/toolkits should stay out the way!! sometimes that is best achieved by assuming that you are not the whole answer! Case in point Gaia – Lee got working as HxGaia.. but because it assumes too much.. that it should be in the flash document class… then it is tricky to get compile with haXe. While a good framework can be the only/main framework… if it presumes less it is often more suited, to work with and extend.
For future quotes!!
“The best frameworks/tookits are not arrogant and become the primary framework in a project through trusted use and not through assumption, in fact it is better to be the only tool that is used through a selection of project than one that hampers a selection of projects.”
Cheers
;j
I always write a framework per project, it is usually tweaked from another project so it isn’t a big deal. It exactly suits current needs, because where it doesn’t I change it. Using something like an off the shelf MVC framework is probably ok (if that is what you want), but you will always fight against things if they aren’t custom for a project. Not saying that is bad, it may still be worth it, but it is inevitable.
Adding elements outside of your element managers usually leads to tears in my experience — not sure how you can avoid that with two frameworks.
Robin,
“Using something like an off the shelf MVC framework is probably ok (if that is what you want), but you will always fight against things if they aren’t custom for a project.”
That’s pretty much exactly what I was saying. Or trying to say. Of course, having your own framework and tweaking it per project gets around a lot of that. Of course there are pros and cons with that method too.
Anyway, I do what I can to avoid using words like “right” and “wrong” in anything development related. Everything has its pros and cons and it’s a matter of weighing those to come up with a decent solution for your project. The only “wrong” thing is not to think about it at all.
I suffered from intensive Frameworkitis with the Mate framework … made me sore for days.
Very interesting article.
I think things depends on the nature of the project really. For most flash websites or simple games you don’t need a big framework, this will just be over-engineered counter productive.
For software development with a big team and long terms projects you probably needs a set of rules everyone comply to, else it will be total chaos, but also to be reasonable with it, else it will be a dictatorship and also counter-productive!
We just want exactly what we need, when we need it! It is all about keeping balance between too few and too much.
In my mind the more code is written the more difficult it will be to conceptualize it as a whole and manage it. After all programming and OOP is just the way we convert our ideas into the machine. So it is important to keep things simple. Which means we don’t lose control. And it makes things much simpler for to have a set of small components we can rely on. So Thumbs up to the toolkit!
A fellow developer of mine once said: “I like PureMVC so much, because anything is possible”. This hits the nail on the head (as we say in the Netherlands…). PureMVC just provides the services concerned with the MVC design pattern, nothing else. You can use the provided functionality, but since it’s completely programmed to interfaces, you don’t have to. Consequently, we never ran into frameworkitis. The value of a framework is mostly proven when working with a team of developers on the same project. More over, if you agree on certain conventions in coding a project, every developer can step in and be working right away on the project instead of reading code for hours. In some cases we work with 5 or 6 developers on a project and to be frank, without using a framework, this could quickly and easily turn into a nightmare. And what about efficiency. Using a framework combined with coding conventions, a project can be done in less time. And what about maintaining a project. The planning department or project management should be able to let any developer on the team do the work, not just the original developers. All things considering, a framework (any framework the team is comfortable with btw) is a must in my opinion. Just make sure the framework does what it should do: provide the basic structure. Add libraries, toolkits and the likes for project specific functionality. And standardize the way you setup a project. Everyone involved will have less work and it will cause less errors. Most of the times this works for a large percentage of the projects a company does. Ok, and make sure at least one developer on the team is a OO ninja.
Sorry for the bumpage, but just want to say that I agree with everything you say here Keith. I hate to rely on 3rd party frameworks because you are carrying around a lot of baggage that can slow you down as much as it speeds you up. Also, you never really feel like you fully “own” the project or know exactly what it is doing. If, for example, I wanted to port one of my Flash games to another platform (say Microsoft XNA) it is as simple as porting a simplified version of MovieClip (with x, y, rotation, scale, perhaps a simple form of gotoAndPlay) and then the rest of my classes can be ported practically line-by-line to c#. Now imagine I’d used PushButtonEngine. I would have no hope of porting there whole framework, so I would essentially be starting from scratch.
Hi Keith,
I was looking recently for info in Flash Game’s patterns, and google didn’t took me to your blog, but I knew I’ll find useful information here.
I would like to know what is your pattern of choice (for example for the Gravity Pods 2). I was wondering whether an mvc pattern is suitable for a game (for example your Gravity Pods 2, or any other game like in fact…).
As i’ve seen in the pure MVC site this game has been done with pureMvc: http://www.generationgreen.co.uk/Games/eco-rangers/
I am just trying to figure out what base structure/pattern to use (not any framework/toolkit itself – i agree with ian, and I also like to control my own creation without relaying much in 3th party frameworks-) . I would love to have information about how you structure your games or what do you recommend as you have a remarkable experience in this field.
Thank you very much,
MartÃn.
i have a question there:
is flash itself a framework, or a toolkit?
dont get me wrong, but i think mostly the point is not about the framework itself being in control. this is one thing you have – for example naming spring in java. it is highly optional, but in a way it isnt, because you can not easily switch it out by something else, unless it adheres to a similar coding concept. it is only in “control”.
i mainly suggest that, because you see flex as a framework in the problem of it being in control, which is right. when it comes to “doing too much”, i think adobe did a good job of supplying you a great toolkit. the framework itself does not do too much anymore since the birth of flex 4. what you now get are a lot of toolkits, you may want to use, but you dont have to use neccessarily. i tried myself for the past months on making actually graphically intense sites using flex instead of only writing applications, to prove it to myself being true. for the time being: it is.
when it comes to iphone and yourself mentioning a framework on top, you might forget that already everything you use on the iphone IS a framework in the worst sense here. my own company right now mainly does iOS jobs, so i can see it for myself what that means. in what point you are right there: it does not always make sense to build a framework on top of another framework to make it even more easy. this is a frameworkitis i am much more afraid of.
in the sense of own code i completely agree with you on building toolkits. that has been tried by a lot of people, but mainly it does fail, because people seem to be caught by the simplicity goal, which does not give you a tool, but more an abstraction.
this abstraction first seems like a good thing but it has some serious problems:
– building an abstraction basically means building a programming language again. it is a meta programming language
– building a meta programming language means it is a good idea to learn from the basics of programming language design. this means flexibility and simple operators. (something that got very fluent in flex 4 for example, not perfect, but very good)
– abstractions need to be debugged on the abstraction level (mostly there is no real support for that)
– as the abstraction is a meta language, you also might want editor support and nice things you have in todays languages there like refactoring, maybe inheritance, code hinting and what else you want to think of.
– the abstraction needs to be simple
– there is nothing, not even any toolkit, that will ever live to solve every problem out there – not even close. but programming languages can do that. even in that – as you may know – some do better, some do worse in specific situations. does it ring a bell? i have not yet seen a perfect one and i am very sure, that this is not a possibility.
i focused here on some imho key parts of the whole in which flex does a very good job. simple frameworks you do find there outside do not solve many of these problems. when it comes to games, flex is probably one of the worst choices to make, cause it was made with doing mainly interfaces in mind. flex is basically a big FORM in a nice looking way, but isnt that something most webapps are anyway?
anyway, i love to see more people realizing the point you realized here. i would very much appreciate “not another stupid framework”
cheers, Sandro