Avalon：面向元件的程式設計（COP） (轉)[@more@]

“面向的設計”（component-oriented programming，COP）已經被鼓吹得足夠久了，這讓它多少有點像一個buzz。什麼是COP？如何實現一個COP的？avalon是一個不錯的參考。

What is COP?

Introduction

Component Oriented Programming, or COP for short, takes Oriented Programming one step further. Regular organizes data objects into entities that take care of themselves. There are many advantages to this approach. I'll assume that you, being a programmer, are familiar with those.

It also has a big limitation: that of object co-dependency. To remove that limitation, a more rigid a had to be formalized: the component. The key difference between a regular object and a component is that a component is completely replaceable.

COP is not just a Buzzword

There is a lot of buzz in the industry touting Component Based Design (CBD). You will find, that the definition of a component in Avalon is more formal than most companies' definition of a component. Any system developed with the principles of Avalon can claim CBD. In fact the Avalon formalizes CBD more rigidly than the marketing definition. Do not be fooled though, CBD and COP aren't necessarily the same thing. Component Based Design refers to how a system is designed and not how it is implemented. Component Oriented Programming, on the other hand, refers to how a system is implemented and not how it is designed. In practice, you can't implement COP without first designing with components in mind.

實現COP時，一個重要的設計是“控制反轉”（inversion of control，IOC）：“don't call us, we'll call you”的“好萊塢原則”使每個元件的實現能夠獨立。另外，avalon用一個極其貼切的比喻闡明瞭“介面-實現分離”的原則：元件好比演員，介面好比劇本；演員總是很多，各有性格，但都要按照劇本來表演；framework自然就是整幕大戲的導演——template method模式的人性化描述。

準確地說，“劇本”還不僅僅是介面（interface），還應該包括契約（contract）。在IOC的系統中，component無法對其他component作任何假設。實現COP時，design by contract也會是有用的。

COP in Avalon

Components in Avalon

At the core of the Avalon framework is the component. We define it as "a passive entity that performs a specific role". This is important to gr because it requires a specific way of thinking.

A passive

A passive entity must employ a passive API. A passive API is one that is acted upon, versus one that acts itself. See the .org/framework/guide-patterns-ioc.html">Inversion of Control pattern for an explanation.

A specific Role

The concept of roles comes from the theater. A play, musical, or movwill have a certain number of roles that actors play. Although there never seems to be a shortage of actors, there are a finite number of roles. I am not going to make reference to different types of roles at this point, but simply bring the concept to light. The function or action of a role is defined by its script.

We are introducing this concept now because you need to have it in mind when you are designing your system architecture. Think of the different roles in your system, and you will have your "cast" of components so to speak.

For each role, you need to specify its script, or interface to the rest of the system. To be honest the interface is not enough. There are specific contracts that you must define and keep in mind when you specify your interfaces. In other words, what users of the component must provide, and what the component produces. When the interfaces and contracts are defined, you can work on your implementation.

The Component

John Donne wrote, "No man is an island." to communicate that we are all interdependent. The same is true for the component. That is why there are different concerns regarding the component. In the section on roles we specified one of the concerns: the role. The concerns directly supported by the Avalon Framework are: configuration, external component use, management, and execution.

Note We used to have a marker interface Component. This has been deprecated because requiring all components extend this interface makes integrating Avalon with other component systems like .org/">CORBA very cumbersome.

As you might have guessed, each one of these concerns has a separate interface that describes that concern. We will delve deeper into the interfaces and the reasoning behind them in other sections. It is important to know the order of precedence for the concerns so that you know the overall contracts of how they are put together.

1. Configurable: marks an object that can be configured.
2. Serviceable: marks an object that uses components.
3. Initializable: marks an object that can be initialized.
4. Disposable: marks an object that can be disposed.
5. Stoppable: marks an object that can be started and stopped.

The contract surrounding this order means that the methods defined by each of those interfaces are called in a specific order by the object that created the component. Each interface represents a narrow view of the component or object being controlled.

Note Notice that each interface is separate from Component, so you can use them for simple objects.