Framework

Framework is one of the approach for reuse. Unlike inheritance, "clone and own", framework itself is a standalone integration.


Differences from Libraries

Unlike Library, framework is a skeleton code that is reusable yet customizable into an application. Framework controls the program structure and program flows, which is different from library that provides the functions to perform those actions.

A notable difference is framework callback into client code just like the Hollowood Principle: "Don't call us. We call you". As for library, it is the direct opposite: the client calls the library functions inside client code.

When to Use (Problems)

  • When the problem wants to provide a quick and standardized way to design an application system.
  • When the problem wants to reuse a system design in a holistic manner.
  • When there is a common pattern across all client's application codes.
  • When the problem requires one to facilitate a default application design.

Range of Deployment (Solution)

Can be huge: to the point where end-to-end hardware to software solution framework is possible. Example: Android devices to Android Studios.

There are generally 2 types of frameworks:

White-box Framework

  • Internal codes are accessible and extendable via sub-classing (inheritence) and overriding methods (polymorphism).
  • Usually uses template design pattern.
  • Design steps are:
    • identify and abstract common codes and variable codes
    • provides method calls to variable codes
  • Sub-class has main method but give controls to framework

Black-box Framework

  • Extension via interface only. Internal codes are not accessible and usually being supplied in a compiled "plugin" or "package".
    • However, plugin is still reusable
  • Usually uses strategy or observer patterns for plugin integration.
  • Design steps are:
    • Identify common codes and variable codes
    • Provides method calls to variable codes
    • Decide whether there may be more plugins
  • Has plugin loading, refresh, reload status mechanisms, then gives controls to framework.



Whether to use either white-box or black-box frameworks, there are a few things to considers as well.

Design Considerations

  1. It is very little opportunity to change once designed.
  2. Identify hot-spots vs. cold-sports to separate the common parts from the variable parts.
  3. Possible constraints:
    1. Too few extension points - limited or niche class of users
    2. Too many extension points - hard to learn, slow
    3. Too generic - little reuse value
  4. Is the framework runnable independently or requires extension to run?
    1. e.g. Ecilpse is independent framework.
    2. e.g. MapReduce requires extension to run.
  5. What is the style of loading variable parts?
    1. Who write main before passing to framework for running? Client or Framework?
    2. How should the passing performed? source code / command line / magic location?
    3. Does one need GUI plugin management?
  6. What is the learning curve metric and facilities?
    1. Documentation? Tutorials? Communities? Mailing List? Forums?


Design Rule

  1. Write in a way that the user passes the variable parts into the framework (framework calls client's functionalities).
  2. Plugin and extensions SHOULD NOT require modification onto any framework's source code .
  3. Always maximizes reuse and minimize use.
    1. Large rich components are very useful but rarely fit a specific need
    2. Small or extremely generic components often fit a specific need but provides little benefit.


Design Process

  1. Understand users/customers in your domain - What they might need? What extension/plugin are likely?
  2. Collect example applications before starting a framework/components - for identifying common and variable parts.
  3. Make conscious decision what to support - called scoping.
  4. Make your own design policy - e.g. interfaces are internal at first; public interfaces when there are at least 2 distinctive customers


Expected Outcomes (Consequences)

  • A standardized, default application structure for application development.
  • Once a framework is designed, it is hard to change.