Component Oriented Design Style

Jing-Ying Chen Department of Computer Science

National Chiao Tung University, Hsinchu, Taiwan jyc@cs.nctu.edu.tw

Abstract

In the battle against software development complexity, numerous development methods and techniques have been proposed over the years. Still, mastering software development skills in general and state-of-the-art techniques in particular remains a painstaking process for many, if not most, software developers. To help software developers make proper design decisions and understand rationales behind complex software designs, we propose a conceptual framework in which software designs at various abstraction levels can be represented in a canonical, component-oriented style. Based on the framework, we present a set of reuse-oriented design rules and use them to reason about the driving forces behind various design patterns. 1. Introduction

In the continuing battle against software development complexity, numerous software engineering methods and techniques have been proposed over the years. Different approaches focus on different stages of the development process from different perspectives. General paradigms such as object and component technologies or techniques such as design patterns and aspect-oriented programming are just some of the most widely recognized examples.

However, the prominence of these various software engineering techniques also creates an additional dimension of software development complexity, namely, the burden for software developers to master these techniques. For instance, the object-oriented paradigm provides extremely powerful abstraction mechanisms such that, for a given problem, the ways solutions can be expressed are potentially unlimited. It becomes the developer’s job to exploit what object-oriented paradigm can offer, and reflect them in actual design and implementation.

Not surprisingly, new approaches are initiated just to help software developers handle these powerful tools. For example, design patterns [1] are one such attempt which, by documenting recurrent, proven object-oriented designs, helps novice developers gain insight into existing object-oriented designs quickly without spending too much trial-and-error effort. For experienced developers, design patterns also make it easy to convey the intent of a given design succinctly. However, the more design patterns are published, the more effort needed to digest them in order to answer fundamental questions such as which, when, how, and why a design pattern is more suitable for a given problem.

Fortunately, experienced developers often can stand firmly against these successive waves of innovations if armed with solid software engineering disciplines. Fundamental principles such as information hiding and divide and conquer help developers appreciate new concepts and techniques quickly, and adopt them effectively. However, understanding general software engineering principles and applying them in practice still takes time and effort. This is somewhat inevitable due to the substantial gap between high-level principles and extremely powerful, but nevertheless low-level abstraction mechanisms provided by programming languages. Furthermore, principles of different flavors also emerge and overlap with each other. Seeing the intent and driving forces behind different principles may not be straightforward.

In this paper we propose a simple conceptual framework in which complex software designs can be represented and analyzed in a systematic manner. The motivation is that, by simplifying design representation and by making design evaluation explicit, design decisions can be made more clearly and objectively. To achieve the goal, we propose a generic component model that is capable of capturing software designs at various abstraction levels. In this paper we refer design to artifacts such as documents or program fragments that reveal the structure of software systems, partly or wholly. For example, a design can be a high-level

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

architecture, an object-oriented design model, a design pattern, or the internal organization within a Java class.

With the component model at hand, we present a set of component- and reuse-oriented design rules, and use them to rephrase software engineering principles in a cohesive and systematic way. Based on this conceptual framework, we show how to derive and combine design patterns naturally in a holistic, reuse-oriented manner.

The rest of the paper is organized as follows: in section 2 we describe the generic component model for design representation; in section 3 we present several component- and reuse-oriented design guidelines interleaved with some examples and discussions; in section 4 we interpret some of the design patterns using the model and rules presented previously. In section 5 we discuss some issues and related work, and conclude the paper in section 6. 2. A generic component model for design representation

The starting point of our approach is that a good software design is well-structured, that is, it is decomposed in a way that exhibits good software engineering properties such as modularity, reusability, and understandability. A good decomposition results in smaller parts each can be analyzed and understood easily using as little information from the other parts as possible; such decomposition also makes the design more reusable and evolvable, in part or in whole. Since the same decomposition principle holds for different levels of abstractions, we propose a generic component model to capture the principle.

To put it abstractly, as shown in Figure 1, a component is a software entity that provides information or services through its interface. Components can be concrete implementations such as Java packages, classes, methods, or running systems such as Web servers. Therefore, the types of interfaces also vary according to the types of components.

A component may contain other subcomponents recursively; the component itself is placed within a suitable context, i.e. the connecting substance around the component, its colleagues, and its containing component. Accordingly, the internals of a component is divided into two parts: the subcomponents being assembled and the context around them. Ideally, a component does not obtain external knowledge or request outside services without going through its context.

Figure 1. A generic component model

We refer component polymorphism to the ability of

a component to exhibit different behaviors under different contexts. Accordingly, the interface of a component is divided conceptually into domain, which corresponds to the primary functionality of the component, and polymorphism interface (or polymorphism for short), through which the component can be customized (the shaded area in Figure 1). Consider a Java method as an example. It is natural to think of its signature as the interface. The method is polymorphic if, for example, its control flow depends on some instance variables mutable by other entities. In this case the variables become the polymorphism of the method. If such control information is passed through some of the method’s parameters instead, these parameters become the polymorphism. Other polymorphism examples include the use of environment variables or preference files by an application.

Components also collaborate with each other through the context they share. We use collaboration interface to indicate the part of the polymorphism interface for such purpose. Component collaboration is also a general concept that appears in dramatically different forms. For example, collaboration can be achieved through coordinated use of instance variables among class methods, shared variables among multiple threads, or a shared database among distributed systems. Although collaboration is often realized through object composition, it is also possible to model inheritance as a kind of collaboration between a base class and its descendents, and the collaboration scheme can be quite sophisticated – as exemplified by many design patterns.

Finally, component composition corresponds to the construction and management of a suitable context binding the polymorphism interfaces of the subcomponents of a component, so that not only each subcomponent receives a proper context it expects, but also the resulting ensemble provides services that

context / managers

Polymorphism

subcomponents / workers

Dom

ain

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

matches the interface declared by the containing component. Composition can be as simple as creating a wrapper around a subcomponent, or can be so complicated that it requires a coalition of managers to complete the job. In object-oriented systems, it is not uncommon to see dedicated classes or frameworks designed just for coordination and management purposes. 3. A component-oriented design style

In this section we present several design rules using the component model just described. Because these rules favor componentization and reuse, we refer component-oriented design style to these rules to indicate that they reflect our preferred way of structuring a complex system. Certainly, different sets of rules are possible with different design objectives, project requirements, and personal tastes. 3.1 Component-oriented design organization. Structure software designs in terms of the component model described in Section 2.

Given an entity in a design, it should be straightforward to identify its role, that is, whether it belongs to the domain, the polymorphism, the collaboration interface, or the actual context of the component. Preferably, each entity should be devoted to one role. In particular, entities involved in component composition should only concentrate on creating a proper working environment for the managed components; they do not involve in actual service providing tasks in an essential way. In contrast, managed components should concentrate on processing requests and providing services without knowing or taking part in the high-level managerial tasks. Such a worker-manager separation principle is in fact the core of our model. 3.2 Maximal reusability. Design components with maximal applicability and usability.

A component is more applicable than another if the former can be used under “more contexts” than the latter. On the other hand, a component is more usable if the effort needed to fit the component into a design is less. Usability also reflects the effort needed for developers to understand a component in order to make proper use of it. We use the term reusability to summarize these two often conflicting driving forces during analysis and design. Note that the reusability of a component also depends on the reusability of its parts. In other words, for two components with equivalent

interfaces, the one with more reusable internals is considered more reusable.

In many cases there are simple rules to judge the reusability of components in alternate designs. For example, a Java interface is more applicable than a Java class that implements it, but less usable. One way to look at it is that whenever the class is used in a design, one can always replace the class with the interface and another implementation. Similarly, a component that uses an interface is considered more applicable than another equivalent one using the class instead. From this perspective, designs that follow the information hiding principle or the Liskov principle [2] will be more reusable than others which do not. 3.3 Self-containedness. Make a component focus on a single domain that matches exactly what the component does; make the component know and use exactly what it needs through polymorphism.

This rule is derived from the maximal reusability principle but in a more atomistic, component-oriented tone. If the domain is incomplete for the problem a component intends to solve, the usability is hurt because the missing part takes time to fill in. If the domain supports multiple purposes, breaking it up into many single-purpose domains increases applicability. On the other hand, when inspecting a client that uses a multi-purpose component, it would not be easy to see immediately whether the client only needs part of the services offered by the component. If so, changing the client to use just the part it needs increases the client’s applicability.

One intention of the self-containedness principle is to achieve separation of concerns – one can inspect the component without spending too much effort on tracing its correlations with other components. This principle manifests itself in many forms that are widely acknowledged. For example, the interface segregation principle [3] addresses issues related to fat components, which have also driven recent research in aspect-oriented programming [4] and multidimensional separation of concerns [5, 6]. It is worth noting that many practices may go against the self-containedness principle. Simple examples include designating a central place collecting all constants used throughout a system. Layered architecture, as appreciated by many, may not contribute to the overall reusability, if components are designed against the layer beneath them naively (for example, by using the Façade pattern [1]). Instead, the overall design may be more reusable if each layer is divided into multiple components properly and used selectively by the components in the layer above.

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

For a valuable component that has undergone substantial engineering effort, one can consider increasing its reusability further by introducing a dedicated domain and polymorphism for the component. An immediate example is the Java Swing component JTree and its suite of polymorphism interfaces such as TreeModel, TreeCellRenderer, etc. In contrast to a compact design that is geared toward a specific problem, this strategy may incur costs in terms of performance and usability, in exchange for overall reusability. 3.4 Simple collaboration. Favor simple collaboration.

When decomposing a component into smaller ones, it is desirable that the design results in simple collaboration among components. Complicated collaboration hurts not only the usability of the components involved but also their applicability, which is the reason many people prefer not to use (deep) inheritance when object composition – a simpler form of collaboration – suffices, even though it may require additional coding.

The complexity of a collaboration relation is not determined just by which language construct is used, but also by the effort required to understand and use it. For example, collaboration via global variables is bad, since the components need to be studied are potentially unlimited. As a rule of thumb, we favor memoryless over stateful collaboration, where the latter implies that both parties need to maintain some shared state correctly. In addition, we favor one-way over bidirectional collaboration. One-way collaboration implies that the component receiving requests can carry out required computation without asking additional information from the requestor. Object composition without passing object references around for callbacks is considered one-way. In case inheritance is used to realize some collaboration scheme between a base class and its subclasses, deep inheritance may result in complicated collaboration that involves a chain of bidirectional, parent-child conversations. 4. Design patterns rephrased

Many design patterns describe different ways of decomposing a large problem into smaller ones using different collaboration schemes supported by programming languages. In this section we analyze the underlying driving forces for some of the design patterns cataloged in [1] using the design style developed so far. Although some design patters are

ingenious use of object-oriented constructs, most of them are consequences of general software engineering principles [7]. [3] also discusses several design patterns and their connections with software engineering principles. In fact, these principles are also the themes running throughout the description of the design patterns in [1]. For clarity, we assume the usability of alternate designs in what follows is roughly equivalent so that their reusability is reflected mostly by their applicability. 4.2 Domain factoring

Many design patterns adopt a “domain factoring” strategy by dividing a domain into two or more to increase reusability. To illustrate this strategy, consider the same example in [1] when designing a portable GUI application for multiple window systems. For simplicity, assume the core of the GUI application essentially manipulate objects in the Widget domain (which includes an abstract Widget class and subclasses such as Window and Scrollbar that are not shown here). Ideally, we would like client C to be exposed to the Widget domain only, as shown in Figure 2 below:

Figure 2. An ideal Widget domain

However, the Widget domain is not complete because it does not include vocabulary for widget creation (e.g. the new operator requires concrete classes in Java). Therefore, as indicated by the dashed line in Figure 2, client C still needs to know concrete widgets. To remove unwanted dependency, the AF pattern introduces a separate abstract interface that is responsible for creating concrete widgets, as shown in Figure 3. This separation also makes the Widget domain reusable across different factories, therefore contributes to the reusability of the overall design.

Figure 3. Widget with factory polymorphism

However, in the design above, client C still needs to know a concrete Factory class, even though such knowledge is expressed in just one line of code. When C itself is also a potentially reusable component, the

Widget

Factory

MSWidget

MSFactoryC

Widget MSWidgetC

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

binding can be delegated to its context through polymorphism, resulting in a design shown in Figure 4.

Figure 4. Polymorphic client with respect to

the Widget factory

Many domain factoring patterns differ only by the types and purposes of the primary domains and the polymorphism they want to achieve. For example, the Template Method pattern is usually applied to algorithms; in this case the algorithmic aspect is arguably the domain, hence it follows to generalize and factor out primitive steps as polymorphism. In comparison, when applying the Strategy pattern, the polymorphism being factored out is usually computationally involved. (In [1] "algorithms" are used to suggest this tendency).

Another observation about domain factoring patterns is that some patterns have more or less clear distinction between their domains and polymorphisms, while other patterns such as Bridge, Observer, and Visitor do not. This happens when two factored domains need to collaborate with each other closely (Visitor), or when both domains are equally weighted in functionality and are relatively self-contained (Bridge).

Dependency between two factored domains in a pattern also affects its reusability. For example, in some cases one can manage to implement the AF, Prototype, Strategy, Template Method, Command, and Builder patterns so that one domain is not aware of the other. This may not be the case for the Memento and Iterator patterns, as well as the Bridge, Visitor, and Observer patterns. When bidirectional collaboration between two mutually dependent domains is unavoidable, communication complexity between them should still be minimized. 4.2 Domain unification

The domain unification strategy increases design reusability by combining different domains; among which the Adapter pattern is probably the most widely used. To assess the merit of the Adapter pattern, Figure 5 illustrates two equivalent designs in which clients C and D use the Base domain and the Foreign domain, where Foreign represents a preexisting component that provides useful services for the

problem addressed by C and D. Compared to D, C is more reusable because it can be used in more circumstances than D.

Figure 5. The Adapter pattern

4.3 Context manipulation and management

Some patterns are conceived for composition purposes; namely, they prescribe different ways to construct contexts that coordinate components differently. The Mediator pattern is one of the obvious examples; it provides a central context that is shared among multiple colleagues, where the context may contain complex coordination logic. Figure 6 depicts two possible applications of the Mediator pattern. In Figure 6(a), A and B know and access the mediator directly, while in Figure 6(b) they are configured by the mediator via polymorphism pA and pB, respectively. In general, the former design spreads collaboration logic among A, B, and Mediator, and has less overall reusability when compared to the latter.

Figure 6. The Mediator pattern

In the Singleton pattern, the singleton object often

serves as (part of) the application-wise context that is accessible from other objects. The Chain of Responsibility pattern concerns the construction of a structural context connecting a set of components such that each component can handle requests itself or relay the requests to other components in a way depending on the structure. The construction of the context is associated with the polymorphism of the composite component and is transparent to clients that access the domain.

Binding of polymorphism and actual context may be static or dynamic. In the former case, the polymorphism may be fixed during design time or system initialization. In the latter case, the context may be altered frequently during run time in a way tightly

C

Adapter

Foreign

Derived

Base

D

class- or inst.- basedWidget

Factory

MSWidget

MSFactory

C

Factory

B A

Mediator

B A

Mediator

pB pA

(a) (b)

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

correlated with the processing logic of the component. Both the State and Flyweight patterns employ dynamic contexts. Specifically, the State pattern in [1] explicitly indicates the use of context to encapsulate states and separate them from client’s program logic. In the Flyweight pattern, the context is continuously updated when the component traverses through some structured data contents. 4.4 A classification of design patterns

As mentioned, the growing number of published patterns can cause headache for software developers, threatening to compromise the benefits design patterns may bring. To cope with this problem, various analyses and classification schemes, in addition to the original classification in [1] (i.e. creational, structural, and behavioral), have been proposed over the years. It appears that our framework can serve as an appealing basis for pattern classification and selection naturally. Table 1 summarizes the classification of patterns in [1] using our model. Note that, as with other classification schemes, the lines between different classes are not definite in actual designs.

Existing pattern catalogs emphasize on various purposes, problem domains, and structural properties of design patterns and their inter-relations. For example, [8] proposes a scheme based on solution techniques. As an example, patterns under the decoupling category are used to solve problems in a divide-and-conquer manner, and are nevertheless similar to the domain factoring patterns discussed here. [9] classifies patterns based on the relations among them; a pattern is related to another if it uses, is used by, or is similar to the other pattern. [10] further refines the relations into three primary relations: use, refine, and conflict, among other secondary relations (variant, combine, similarity, etc.) [11] presents a system of patterns at a broader scale that includes architectures, design patterns, and idioms, and each category is further classified according to functionality (purpose) and structural principles (means).

These classification approaches pay less attention on the underlying factors that drive the creation of various design patterns. Consequently, evaluating, selecting, tailoring, or even creating design patterns for a particular problem are largely left to software developers. In contrast, we attempt to create a conceptual framework in which developers can create good designs with simple rules of thumb, without knowing the fact that their designs are actually applications of some existing design patterns.

Table 1. Component-oriented classification of design patterns in [1]

Domain Unification

Adapter, Proxy, Façade, Composite, Decorator Primary / secondary

One-way Bi-directional

AF, Strategy, Command, Prototype, Builder, Template Method, Factory Method, Iterator, Memento

Domain Factoring

Equally weighted

Bi-directional

Bridge, Observer, Visitor

Static Singleton, Mediator, Chain of Responsibility

Context

Dynamic State, Flyweight

5. Discussions and related work

While fundamental concepts presented in this paper such as components, reusability, principles, and patterns are not new, our attempt to reconcile them into a simple yet pragmatic conceptual framework is unique. Although our design style in some sense constrains the design space for developers when compared to more liberal object-oriented designs, we believe the gains in design readability and maintainability can be substantial. Compared to project- and problem-oriented design approaches that are more common today, our style focuses more on the reusability of the overall system design as well as the individual components.

To compare our work with component-based development in general, existing component models and technologies often stress on abstractions and mechanisms for component specification and assembly. In contrast, we attempt to captures the essence of component reuse across different levels of abstractions. We are more interested in how to apply the component principle using any programming languages, and believe that relying only on the principles of design by contracts and black-box reuse is not sufficient.

There are extensive research efforts directly targeting the complexity and implications of various kinds of component correlation. For example, [12] discusses the problem of extraneous embedded knowledge – a component knowing information not conceptually required for what it does – and proposes using implicit context to hide the information while communicating with the component. In [13] language constructs are proposed for specifying collaboration

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007

interfaces that support bidirectional communication among components. A component can declare both its provided and expected services in its interface, much like the domain and polymorphism in our model, except that the paper emphasizes more on complex forms of collaboration. In [14], various forms of (primitive) object-oriented composition are analyzed and classified (e.g. overriding, transparent redirection, acquisition, subtyping, and polymorphism). The paper proposes language support for expressing these different types of composition linguistically. Like our approach, these different approaches see the importance of managing the potentially complex inter-component relations. While they propose language constructs to address this issue, our approach remains at a conceptual level with an aim at providing software developers an immediately useful tool which not only can help them make good design decisions, but also help them sieve through mounting documents and research reports about new technologies. 6. Conclusion

We have developed a generic component model that is capable of representing software entities of various types at different abstraction levels in a uniform way. We believe that the basic concepts introduced here, namely domain, polymorphism, collaboration, context, and composition, provide a useful meta-model for describing software designs. Using the model, we have also presented the maximal reusability principle as a tradeoff between component applicability and usability. By using the principle and other principles derived from it, we were able to comprehend fundamental principles as well as modern techniques such as design patterns more easily. In particular, we showed how to derive several design patterns naturally from reusability point of view, and also gave a simple classification scheme for design patterns. While this paper may appear trivial to some readers, most can agree the indispensable effort they had to spend on figuring out various emerging technologies, acronyms, their relations with each other, and more importantly how to make effective use of them in practice. Although the model and design style proposed in this paper are abstract, they can serve as a basis for the development of more advanced CASE tools. For example, (semi)automatic design annotation using the

component model can help software developers quickly grasp the structure of a complex software system as well as the rationales behind its design. Moreover, as a design evaluation platform, our framework can be extended to support automatic design refactoring [15], with an emphasis on components and reuse. 7. References [1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. [2] B. Liskov, “Data abstraction and hierarchy”, SIGPLAN Notices, 1988, pp. 23-25. [3] R.C. Martin, “Design Principles and Design Patterns”, http://www.objectmentor.com, 2000. [4] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V. Lopes, J.-M. Loingtier, and J. Irwin, “Aspect-oriented programming”, ECOOP - Object-Oriented Programming 11th European Conference, 1997, pp. 220-242. [5] P. Tarr and S.M. Sutton, “N Degrees of Separation: Multi-Dimensional Separation of Concerns”, ICSE 1999, pp. 107-119. [6] H. Ossher and P. Tarr, “Using Multidimensional Separation of Concerns to (Re)shape Evolving Software”, Communication of the ACM, 44(10), pp. 43-50. [7] B. Meyer, Object-Oriented Software Construction, Prentice Hall, 1988. [8] W. F. Tichy, “A catalogue of general-purpose software design patterns”, In Technology of Object-Oriented Languages and Systems (TOOLS-23), 1997, pp. 330-339. [9] W. Zimmer, “Relationships between Design Patterns”, Pattern Languages of Program Design, (Coplien, J.O., Schmidt, D.C. Eds), Addison-Wesley, 1995, pp. 345-364. [10] J. Noble, “Classifying relationships between object-oriented design patterns”, in Proceedings 1998 Australian Software Engineering Conference, pp. 98-107. [11] F. Buschmann and R. Meunier, “A system of patterns”, Pattern Language for Program Design, Addison-Wesley, 1995, pp. 325-343. [12] R.J. Walker and G.C. Murphy, “Implicit Context: Easing Software Evolution and Reuse”, SIGSOFT 2000 (FSE 8), pp. 69-78. [13] M. Mezini and K. Ostermann, “Integrating Independent Components with On-Demand Remodularization”, Proceedings of OOPSLA, 2002, pp. 52-67. [14] K. Ostermann and M. Mezini, “Object-Oriented Composition Untangled”, Proceedings of OOPSLA, 2001, pp. 283-299. [15] M. Fowler, “Refactoring: Improving the Design of Existing Code”, Addison-Wesley, 2003.

31st Annual International Computer Software and Applications Conference(COMPSAC 2007)0-7695-2870-8/07 $25.00 © 2007