What is a "white-box framework," as MartinLippert describes the JwamFramework on RefactoringWithaFramework?
See also BlackBoxFramework.
"White Box"? Are you saying that you can see the framework code, but are not allowed to change it? (See WhiteBoxTesting.) -- jtg
I am talking about framework code you can see (you have the source code or the JavaDoc, for example). The main point here is that white-box frameworks are mainly used by inheritance. White-box testing does not completely mean the same thing. White-box testing need to see the code, white-box frameworking need to know what to override.
--MartinLippertI haven't seen many frameworks that give you alternatives. Typically frameworks, like MicroSoft's MFC or ActiveTemplateLibrary (ATL) support "the one true way" of doing things, and no other. [See below for "framework" vs "white box" terminology.] Maybe the JwamFramework is unusual (and good?). -- jtg
I've been thinking about the terminology:
In my mind...
Framework = large, complex or tricky body of code that embodies valuable knowledge about how to write successful applications within a well-defined problem domain. With most "frameworks," the application programmer implements the framework's interfaces (and/or inherits from the framework's classes), and the framework calls application classes when it feels the time is right.
Library = valuable body of code that you call and use when you feel it is appropriate. Typically libraries don't impose too many rules on how you must develop your code. (But you'll probably have to be aware of their error handling policy.)
It sounds like what you're calling "white box" is what I'd call "framework."
And what you call "framework" is what I'd call "reusable code" -- which could be "framework" or "library."
The most important part of a framework is to abstract the common processes of how things work so that each
and every application doesn't need to reinvent the wheel. A good framework is minimal and it does only
its job and does not try to be everything to everyone. A good framework allows installable strategies.
You should be able to completely reimplement a framework without impacting existing code.
Yes, I agree completely. Thanks for this clarification. I've never thought of something else as being a framework. And this is exactly the base for my investigation. How does the usage of a framework affect application refactorings?
Being open to viewing the "guts" and the nesting of the framework/library are generally orthogonal traits. Frameworks tend to control the "main" routine while libraries let the developer do that. That's a matter of code organization, not access levels to the internals. Either can be "locked up" or open-source.