Somebody Elses Framework

A framework is somebody else's framework if one or more of the following is true:

1. You don't have sympathy to somebody who designed and/or coded the framework.

2. Somebody didn't listen to your advice about it.

3. Somebody didn't bother to document the framework, and when asked, he/she/they say "look at that code for an example of the usage"

4. Somebody make unexpected changes that totally killed your application code, in the middle of the project.

5. You try to make the framework fail by overusing features intentionally.

These points seemingly address some of the underlying concerns that have relegated frameworks to the boondocks of software engineering. The ExtremeProgramming and DesignPattern guys bootstrapped their ideas on frameworks, but don't talk about them much anymore. But they really work if issues like the above can be addressed and/or overcome.

If a programmer doesn't have sympathy (or respect) for the framework builder, then they have eliminated themselves from the pool of possible users from the start. Maybe later they will have these qualities. Or maybe they have them today for another framework. Adjust accordingly.

Advice should be offered to framework builders after acquiring some experience with (and appreciation for) the framework. And even then one should accept the fact that the framework builder might not see things your way. They might have a different perspective stemming from a different background, or simply have a lack of resources to do what you request. If it is the former, think about a LayeredApplicationFramework, and how you can make your mark by deriving as you please. If it is the latter (and the project is open source), feel free to join in.

It is easy to say "there are no examples for what I need to do". But by their nature frameworks are open-ended beasts, where it is impossible to describe every possible unimagined use. Perhaps flat libraries can be documented to the satisfaction of the end-user programmer. But frameworks require you to understand and appreciate the source material. Even though documentation can always be better, there really is no substitute for studying the source. If someone doesn't have to study the source, they probably aren't using a framework.

It is not good for the framework builder to introduce backward-incompatible changes after other programmers have begun to build on top. But don't be confused by the fictitious FragileBinaryInterfaceProblem, where it is rumoured that augmenting base classes with new methods and new member variables somehow breaks old code (regardless of the care taken in making sure new additions preserve old functionality). This is simply not the case if you have access to all the source, and can recompile as needed. A programmer only has to fear this if they are stuck using binary copies of some important components that attach themselves to the framework. But binaries and frameworks don't mix -- even MicroSoft delivers all the source to MFC.

Finally, if someone is to the point of hoping the framework will fail, they might as well quit using it immediately. They don't really have to go through the exercise of proving they will have problems. They should only use the framework if they are interested in resolving the problems they are sure to encounter. Frameworks aren't easy. They're just powerful in the hands of those who appreciate them.

ScottJohnston

Building a new frameworx, and getting all the credit for it, is seen as more fun than having to learn about and use somebody else's framework. A multitude of other reasons not to use SomebodyElsesFramework follows by way of concious and subconcious rationalization... --FalkBruegmann (HaHaOnlySerious)

I saw a framework builder get mad when his framework was refactored to remove features that nobody ended up using. See HandsOffMyFramework?.

Was this a closely held framework with a closed set of users, or an open-source framework with an unknown set of users? I can see why removing features would be frustrating to the original developer if unknown users relied on them. But in the open-source world it should have been ok if the trimmer framework was clearly labelled as a fork.

Why do framework writers in C or C++ always seem to use their own "types"? Is there some law against using "int" instead of "tInt" or "INT" or "FwInteger?" or whatever? Why, why, why? Why are framework writers totalitarian?

The common reason for "redefining" basic types is to provide portability. If the framework writer wants to assume that an "integer" is 32 bits wide, for example, then defining and using an "INT32" type makes it easy to use the framework with compilers where an 'int' is 16 bits wide or 64 bits wide. There are similar reasons for every framework writer creating their own string-like class, base exception class, container templates, etc. We can blame compiler vendors for not adhering to standards that everyone can use.

I frequently find this technique of defining int32 and friends does nothing to help portability, but it does act as a marker that the code is not portable. It is a way of saying "I've only tested this code with 32 bit ints". If you attempt to use the framework on a platform with different sized variables, you get frustrated by the mismatch between the client code and the framework. A better approach is to design a framework that doesn't care what size its ints are.

(I don't understand the above paragraph - surely, if you're passing a non-32bit integer into a function which expects a 32bit integer, you're abusing the API? Try porting the framework to the platform first...)

If it is in C++, it means that somewhere in a header file there is a typedef xxx int32 that you are expected to modify for your compiler. The code probably predates stdint.h

[CategoryFramework]