Is it realistic to expect to be able to define an application entirely in terms of components? And why would you want to do it in the first place? Can't we just write an application the ``old-fashioned way"? That is, import the exact components we want, and use them wherever and whenever we want, instead of creating bindings to link them to a master ``application" component?
Well, you could, but one of PEAK's goals is to improve reusability. Consider this: all cars have engines, but different models of car have different goals or requirements for their engines. If we are creating a ``Car" application, wouldn't it be nice if we could switch out the ``engine" component when we get a new project, without having to maintain multiple versions of the code? Perhaps for this project we need the ``car" to be compact, or perhaps we need a bigger engine for a station wagon this time.
How can we achieve such reusability? It actually requires only a simple coding convention: never write code in a function or method that directly references another class. Instead, define all collaborations with other classes by way of instance attributes. This means that collaborating component classes can be easily substituted in a derived class, substituting a new ``engine" class, for example.
While you can apply this technique of ``hiding collaborators" in any object-oriented language, PEAK takes the approach to a new level. Because PEAK attribute bindings can be used to programmatically define connections in context, components can actually seek out their collaborators dynamically at runtime, via configuration files or other sources. This can be as simple and ubiquitous as looking up what database to connect to, or as complex as specifying strategy components to select algorithms that are optimal for a specific deployment environment.
We're back to the ``ilities" again: reusability, composability, extensibility, and flexibility, in this case. (Maybe portability, too.) We even get a bit of understandability and maintainability: when we isolate collaborations in attribute bindings, it becomes a lot easier to implement the Law of Demeter and write ``adaptive programs".
See Also:
http://www.ccs.neu.edu/home/lieber/LoD.html has lots of links about the Law of Demeter, and you can also see http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/object-formulation.html for its ``object-oriented" version, if you'd like to know more about this software quality technique. PEAK takes this ``Law" very seriously, insisting that code which references even a collaborator class must do so via an instance attribute or other ``neighbor" as defined by the Law.
You don't have to know or follow the Law of Demeter to use PEAK. (Your programs just won't be as flexible.) But all of our example programs will obey the Law, so you'll have a chance to see how - and how easy it is - to follow it.