Chapter 6. Programming Languages and Patterns
If we want a language which is deep and powerful, we can only have it under conditions where thousands of people are using the same language, exploring it, making it deeper all the time. And this can only happen when the languages are shared.
—Alexander, 79
Patterns are programming-language independent (as opposed to idioms that are programming-language specific). In a way, patterns form a language that are a step above the programming language in order to communicate other concepts such as design. This said, it is important to recognize that the specific programming language does play a significant part in the evolution of a software system. This is becoming true as programming languages today are more than simply language syntax and semantics. We must now consider the utilities, the libraries, and the general environment they provide—especially when we consider recent languages like Java or C#. These languages not only provide the traditional programming language syntax but are also built on a virtual machine and come complete with a rich set of libraries or packages to make development and reuse easier.
While any design pattern (by definition) can be implemented in any language, certain patterns are easier to implement in some languages than in others. For example, if the pattern builds on the use of multiple threads of control, it is a bit harder to convey this within the boundaries of C++ or Visual Basic than in Java. That said, by extending C++ with a thread library (such as Pthreads) or using low-level windows calls in Visual Basic, we can still accomplish these things—but not quite as easily.
In order to consider a design choice properly, we must include the programming language and development environments in the context we use to evaluate the design alternatives. Although it does not normally occur for a variety of organizational and training issues (as well as marketing issues), where possible the programming language selection should be done as part of design iterations. Understand, though, that it may enable certain design solutions to be implemented far more easily.
While systems developed using multiple languages should be considered, this may also create training and maintenance issues. For example, it is very common to see a system seamlessly using Visual Basic for the front-end presentation layer but utilizing C++ for the business layer and Transact-SQL (or PL-SQL) for the database layer. This important separation of tiers is actually enhanced by the separation of languages, but in these cases developers tend to focus on a single tier so that the training issues (and general confusion) are reduced. As virtual machines (such as Microsoft's .NET framework) evolve, this focus may be less of an issue in the future.
SOAPBOXThe original COBOL did not provide support for structured programming as a language construct, yet people managed to design and implement as structured programming became the rage. C does not provide language constructs to make object-oriented design easy, yet several object-oriented designs that were implemented in C that I have been fortunate enough to work with utilized the features it did provide to create an extremely efficient and elegant implementation. As design techniques evolve, language constructs and libraries to support different paradigms will also evolve. This does not imply that there will ever be a language rich enough to encompass all of the patterns or general approaches we require in design. Instead, it is my hope that as our vocabulary improves, the ease in which we can express complex designs will also improve. |
Let's look at a specific example. Often in software we need to handle multiple objects that are dependent on the state of another object. For example, in an accounting system you may provide multiple views of the data, perhaps even multiple spreadsheet views as well as multiple graphical views. Whenever you change the data in one spreadsheet, the user would reasonably expect the other views to change (automatically, without selecting a refresh option). Patterns, though, transcend a specific domain. For example, in an embedded system you may have a similar problem of having multiple objects (such as monitors) watching a piece of hardware (through its software encapsulation/device driver) that have to react quickly when an interrupt, such as low power, occurs. A pattern can describe this situation and address how to proceed in a readily transferable manner. For example, this monitoring approach is described as the Observer Pattern [Gam, 95], discussed earlier in Chapter 2 (“Observer Pattern” on page 8).
Let's look at a simple model of this pattern. Consider an account (serving as a subject) that allows multiple observers. See Figure 6.1.
Figure 6.1. Account example
First let's look at implementing this solution in Visual Basic, a language not well known for its ability to handle object-oriented paradigms. As you can see, Visual Basic is more than capable of supporting the following pattern: