Granularity

Granularity
This is the fifth of my Engineering Notebook columns for The C++ Report. The articles that appear in this column focus on the use of C++ and OOD, and address issues of software engineering. I strive for articles that are pragmatic and directly useful to the software engineer in the trenches. In these articles I make use of the new Unified Modeling Language (UML Version 0.9) fordocumenting object oriented designs. The sidebar provides a very brief lexicon of this notation. Sidebar UML 0.9 Lexicon
Directional Association

A2 P1

dependency

Aggregation By Reference

X

Base Class
Aggregation By Value

Inheritance

Bi-directional Association

P2

Derived

A1

Introduction
This article marks an important transition in this column. The first four articleswhich appeared in the January, March, May, and August issues of this magazine, described principles that govern the micro-structure of object-oriented software applications. This article is the first of several that will describe principles that govern the macro structure of large object-oriented applications. I emphasize the word large, because these principles are

1

Introduction

2

mostappropriate for applications that exceed 50,000 lines of C++ and require a team of engineers to write. This is a timely topic. John Lakos has recently published a book: and several articles in the C++ Report that deal with the development of large C++ systems. This article discusses granularity. This is a topic that is addressed by all of the major methodologists in slightly different ways,using very different vocabularies. We will examine these differences in an attempt to understand the common thread that binds them all together. Such a thread does exist, and it will lead us through some of the most important principles of software engineering.

Reprise
But before we begin to unravel the thread of granularity, a brief reprise of what has gone before in this column is in order. 1.The Open Closed Principle. (OPC) January, 1996. This article discussed the notion that a software module that is designed to be reusable, maintainable and robust must be extensible without requiring change. Such modules can be created in C++ by using abstract classes. The algorithms embedded in those classes make use of pure virtual functions and can therefore be extended by deriving concreteclasses that implement those pure virtual function in different ways. The net result is a set of functions written in abstract classes that can be reused in different detailed contexts and are not affected by changes to those contexts. 2. The Liskov Substitution Principle. (LSP) March, 1996. Sometimes known as “Design by Contract”. This principle describes a system of constraints for the use of publicinheritance in C++. The principle says that any function which uses a base class must not be confused when a derived class is substituted for the base class. This article showed how difficult this principle is to conform to, and described some of the subtle traps that the software designer can get into that affect reusability and maintainability. The Dependency Inversion Principle. (DIP) May,1996. This principle describes the overall structure of a well designed object-oriented application. The principle states that the modules that implement high level policy should not depend upon the modules that implement low level details. Rather both high level policy and low level details should depend upon abstractions. When this principle is adhered to, both the high level policy modules, and thelow level detail modules will be reusable and maintainable. The Interface Segregation Principle. (ISP) Aug, 1996. This principle deals with the disadvantages of “fat” interfaces. Classes that have “fat” interfaces are classes whose interfaces are not cohesive. In other words, the interfaces of the class can be broken up into groups of member functions. Each group serves a different set

3....