Component Oriented Software (Page 5)

<< Introduction & Message Forum

<< Page 4 (Object-Oriented Java)

Component-Oriented Software

The component-oriented thesis is best expressed as making the distinctions:

Modules vs. Types

and

Methods vs. Messages

Modules refer to the static architecture in a system, whilst Types refer to the dynamic data in a system. Modules are then supported in a framework (or matrix). The best analogy is between a product and the production line, where the framework is the factory.

When designing a system using an Object-Oriented language, the developer has to be disciplined not to merge the two aspects. This discipline is similar to that required when treating a functional language as Object-Oriented: such as C and C++.

You'd think the separation of architecture from data was easily achieved, but it's surprising how often you see the mistake made. Once you spot the mistake once, you'll see it repeated. For example the EJB Object has a remove method. The data has wrongly become part of the architecture.

The distinction in Component Oriented Software that's harder to make is the separation of Methods vs. Messages. Simply put, a method is an implementation whilst a message defines a set of interfaces. The thesis here is that modules conform to a message interface and can be implemented differently.

The idea that modules such as a UI or a persistence API can be generalized seems difficult to achieve, but Swing/Swinglets and JGenerator show that it is possible. The separation is more easily achieved by keeping a clear separation between data and architecture. The Model, View, Control design is a less abstract form of the Module, Type, Framework thesis.

>> Page 6 (Component-Oriented Java)

<< Back to Programming