Chapter 12

The chapter takes its name from the concept that electronic engineering has found success in abstracting details of the development process and then using that abstraction as a platform for developing even more complex systems.

The authors propose applying this concept to software.

They identify and contrast 3 different levels of abstraction: Classes, Libraries, and Frameworks.

"A class is the basic unit of program modularization and encapsulation in an object-oriented programming language. A class is therefore a language-based abstraction."

"Generally, a class is not an independent unit of deployment. "

"To enter into the world of independently deployable platform-based abstractions, we need a software component."

(The authors spend a great deal of time trying to define a component.)

The authors identify 7 properties of platfor based abstractions:
-Definition
-Discovery
-Composablility
-Adapatability
-Depoloyment
-Distribution
-Organization

(Though I agree these are all properties of abstractions, I couldn't find any argument in the text to support why these are the primary ones that need to be considered or how these were arrived at.  The author just state that these are common threads and we are expected to accpet that.)

They use these to analyze and contrast Classes, Libraries and Frameworks.

Classes:
-Great way to structure a program
-no way to seperate specification from implemenation
	-interfaces are a weak attempt to do this
-discovery is hard
-Composability is addressed thru inheritance and direct calls
-Adapatability is addressed thru inheritance and extention
-Deployment is by including libraries or DCOM/COBRA
-Organization: There is no implied architection in classes.

Frameworks:
"Class frameworks impose a well-defined organizing architecture for a collection of classes designed for custom extension and reuse."
Definition:
"A framework is defined as a number of concrete and abstract classes and a definition of the way instances of these classes interrelate"

"Frameworks often impose architectural structure on an application using them because of a characteristic known as inversion of control."

Discovery:  (Authors seems to skip this point)

"Patterns play an important role in developing frameworks."
(I think the point is frameworks are patterns taken to the next level.  This is they are patterns grouped together.)

"Frameworks typically emerge during the refactoring that occurs when software is consolidated. "

"The ability to anticipate and accommodate change is even more important in application frameworks than it is within individual applications."

"Frameworks should be constantly refactored as they change to support new requirements."
(I feel this is a dual edged sword becuase it introduces the problems and dangers of backwards compatability.  .NET 2005 is having trouble gaining acceptablity because of this and I feel the slow in demand for this reason.  To maintain backward compatability java is having trouble keeping up with .NETs new features.)

Composablility 
using the Template and Factory patterns.

Adaptablity:
using the Decorator and Visitor patters.

" frameworks are often developed after the fact, mining the reusable abstractions from existing applications that are discovered to be archetypical of the domain.
"

Two techniques:
-Build lots of similar projects and identify reusable parts.
-Have multiple teams build similar projects and identify commonalities.