How frameworks can kill your projects and patterns to prevent you from getting killed – Sander Hoogendoorn
Sander talked about frameworks and the usual problems with them:
- How to choose the best framework from over 9’000?
- Some frameworks integrate only specific things (like logging or building a UI), others include everything and the kitchen sink. Which is better?
- How do you convince your management to buy a framework, train the developers, testers, support people for it?
- How do you get the other developers to agree to your choice?
After selecting a framework, the trouble starts:
- What do you do it an important feature is missing? Do you add it? How do you maintain it? Do you file a bug report? What if it’s being ignored?
- Half along the project, you find a framework that is better suited.
- How do you handle bugs in the framework?
- When do you upgrade after a new version comes out? What if the new version has dramatic changes that break a lot of your code?
- What if development of your favorite framework stops? Do you take over or walk away?
- If one framework isn’t enough, you’ll find that dependencies tend to kill you because all the problems above multiply.
- Sometimes, framework A has a hidden dependency on logging framework B but your company uses logging framework C.
The way to answer these questions:
- Know your architecture. What do you need where?
- Instead of using the framework directly, put in an abstraction layer that says what you want and does it using the features of the framework. If “something” happens, chances are you only have to change the abstraction layer.
- Use dependency injection to clean up your code from unwanted dependencies.
Posted by digulla
Jazoon 2011, Day 2 – Java Concurrent Animated – Victor Grazi
26. June, 2011Java Concurrent Animated – Victor Grazi
One picture says more than a thousand words. Now imagine what an animation can say. Victor did several for us to better understand the classes in java.util.concurrent. You can find the software on sourceforge: javaconcurrenta
Here is an example:
Very nice. I know a lot about threads and concurrency (the Amiga had preemptive multitasking back in 1986) but even I was surprised by the ReentrantReadWriteLock example: If you have a writer waiting for the lock and another reader comes along, should it get the lock immediately or should it wait for the writer to complete?
My first instinct was to get all the (quick) readers out of the way but chances are that, when all readers have been processed, another one might have come along, effectively starving the writer.
Links:
Share this: