Thoughts on creating a framework

I have been developing frameworks for different applications mostly games for over 10 years. Over this time I have made some really bad decisions and wrong turns, fortunately I have learned and gained some knowledge that always made my next framework a bit better.

Design patterns

One of my first lessons was that I don’t have to reinvent stuff over and over again. That there was people that actually have solved my problems before. So I started to learn design patterns. This really made a big difference. I had a problem that I outlined and then I looked for design patterns within my problem and if there was minor adjustments to my solution to make it in to a design pattern I made them. This actually helped me a lot later on in the project with problems I did not know about until later on.

Singletons, one of my biggest mistakes

I started to use singletons quite frequently and ended up with stiff frameworks that worked fine for a specific project but was often not that flexible to be able to be called a framework.

Later on I learned that a provider that gives me the same instance of that class that I earlier made as a singleton works fine. Some programmers like to put this provider within the same class and some don’t. I want to be able to change the implementation of this “singleton”-workaround so I don’t believe that the construction of a class like this should be within the class it self.

Performance

I started to make bigger and more complex frameworks and started to loose performance. Most of my framework is about graphic programming and are in need of good performance. It is a great difference between optimization and optimization. There are two major optimization types.

1. Heavy functions like sinus, co-sinus. This ones you can wait with to optimize just because they are often just function calls.

2. The other optimization are more in an architecturally way. For example if you have a lot of if-else/switches and logic with in a render loop. This ones are much more difficult to solve later on. This ones should be solved at the moment you notice them because this ones often affect other parts as well.

The second one I had to learn the hard way. I have made several frameworks thinking: “I can fix that later.” To remove this “known” performance issues it will be so much easier later on to optimize when using a profiler.

User friendly

In the beginning most of the framework was made for me to work with. But later when other people started to work with my frameworks I realized one of my biggest mistake ever. My frameworks was not so user friendly, not at all in fact some of them was so unfriendly that they was useless to any one other then me.

I found two ways of fixing the usability.

1. Actually make the API easier, this is the most obvious one. This one made me start making changes and adding functionality that made my frameworks start to grow and become big monsters. That I had problems maintaining.

I figured out that by keeping my frameworks small and compact with good APIs made them easier to maintain

2. A good API is necessary but not all we need. It should still be easy for users to work with so I started to make help classes. I made a help library that gave the user functions to create stuff with my framework in an easy way.

One example:
In the framework we have a class representing a mesh (a 3D representation of geometry) to render to the screen. Should the framework care about what that mesh looks like or represents? I don’t think so. So a classes called a box, plane, sphere or cone are not really usefully to the framework only to the user of the framework. So I moved the constructions on this classes to a help library. The user tells a factory to create a sphere with some settings and the factory creates an mesh.

So my thoughts are what?
– Your problem is probably already solved on someway and they have probably tested it more then you will be able to. Use that!

– Performance, there is something called premature optimization but there is also something called mature optimization that need to be fixed asap.

– User friendly, if you write a framework that other should use it is your responsibility to make it user friendly. If you get the developer to like your framework, then you are in a good position.

Don’t forget that if you are making a framework with no real project to test it on you are trying to solve problems that you make up as you go. Try to develop of a framework within a real live project, then you get real problems and will get a better framework.

5 Comments

  1. I guess it was one of the nicest business making some frameworks.

  2. Business Card / Hey very nice site!! Man .. Beautiful .. Amazing .. I will bookmark your blog and take the feeds alsoa1KI am happy to find so many usfuel information here in the post, we need work out more strategies in this regard, thanks for sharing. . . . . .

  3. Howdy, i read your blog occasionally and i own a smialir one and i was just curious if you get a lot of spam comments? If so how do you reduce it, any plugin or anything you can recommend? I get so much lately it’s driving me crazy so any support is very much appreciated.

Trackbacks for this post

  1. Thoughts on creating a framework — Jayway Team Blog | Programming Blog Imagik.org
  2. Revue de presse, semaine 35 - Espace de fouille

Leave a Reply