1. Convention over Configuration
, but not necessarily without configuration. Convention over Configuration is a simplification mechanism for software which uses standards and conventions to do something out of the box, but still allowing customization. This makes it simpler to get things up and running quickly.
2. Works out of the box
A Framework should always attempt to be "in a runnable state" from the get-go. Not too much configuration, if any. No extensions required. All is there, and all will work, until you decide to intervene. However, a Framework is not an Application and there should always be that distinction.
3. Fine grained objects
Splitting, refining and making objects smaller until it makes no sense any more to do so. This provides smaller units of extensibility or at least that could be.
4. Hotspots and Frozenspots
Hotspots are the basic units of extension. It is the extension points, albeit methods, interfaces or other, we use all kinds of means to providing extension and modification of conventional behaviour.
Frozenspots can be thought of as the fixed, core of the Framework. These parts are either fixed structurally or fixed because of a Domain requirement.
5. Coalescent Patterns
Since even the GoF state the 'c'omposite is not to be confused with 'C'omposite, I prefer to use the term Coalescent Patterns. Coalescing patterns is what we do no matter the application or framework we build. However, it is even more important to choose the correct Design Patterns in a Framework. Refactoring a Framework after it is being used is generally not that uninteresting nor is it trivial.
6. One Voice
Too many cooks do spoil a design. Consistency and simplicity is vital in a Framework. Many people can spot flaws, but only one should finalize the decision. Those decisions should be technology and not business based. This is where you will find some of the tension in a Framework project. However it is known that compromise of two great ideas, mostly leads to one very mediocre one.
7. Prototyping Applications
Have a few applications that are being built on the Framework, by people 'outside of the development team' is invaluable. Listen especially to the questions they get wrong, or section in the Framework they seem to misinterpret. These are the muddy areas, that need work. But also creating prototype applications by 'members of the team' will also be valuable in understanding nuances.
8. HarvestedFramework
In short, you build "Applications", while trying to keep things generic and common, which you refactor and refine into what is the Framework part. In my opinion this is better than FoundationFramework.
9. FoundationFramework
Build a Framework by building requirements from inspecting other applications, and then common requirements are implemented as a Framework before any Application actually uses it.
10. Three Examples
This is basically the same or a merging of HarvestedFramework and PrototypingApplications. As it suggests you should build the three applications yourself.
11. WhiteBox Framework
Use FactoryMethod and TemplateMethod. Use Inheritance, by supplying overridable methods.
12. BlackBox Framework
Rely more on Interfaces and object composition.
13. Framework Utilities
A Framework should also contain utilities, code generation, cookbooks, recipes, and reference documentation. I large Framework 'must' have code generation to support the complexity and increase levels of reuse.
14. Systematic Generalization
The idea that working from the top down is better. It is similar to HarvestFramework where you generalize and extract out from an Application.
15. Low Surface to Volume Ratio
Control and do more with less. A simple interface controlling a large set of useful functions is more adoptable than complex controls that do less.
16. Style of Use
In the book, Kent describes three main styles of use: instantiation, configuration and implementation. This is uncannily similar to my , but from a slightly different angle.
17. Flexible Foundations
Allow flexible foundations that allows what would traditionally be immutable to be mutable. Allow and facilitate architectural changes by "selectively exposing the internal architecture".
阅读(656) | 评论(0) | 转发(0) |
