Get an overview of the broader universe of design patterns in this conclusion to Jeff Friesen's Design patterns, the big picture series. Find out how interaction designers, software architects, and agile development teams use design patterns to improve software development processes and products. Then get tips for using communication and presentation patterns to further your own career in software development.
Whenever an activity occurs in repetition, such as programming, patterns emerge and can be documented. The benefits of documenting and using software design patterns are well established, as are some common pitfalls. In this final article in the Design patterns, the big picture series, we'll move beyond the software design patterns that Java developers know so well to look at four other types of patterns that also are relevant to software development. Read on to find out how design patterns are used to improve application usability, enterprise architecture, software development processes, workplace communication, and technical presentations.
More software design patterns
The two previous articles in this series addressed software design patterns that apply to object-oriented development. See Part 1 for an overview of design patterns including their history and classification. See Part 2 for a fresh look at the Gang of Four patterns. Additional software design pattern categories include data access patterns , concurrency patterns, enterprise patterns, and real-time patterns. Patterns have even been noted in the usage of the relatively new JavaFX .
Interaction design patterns
Christopher Alexander's A Pattern Language: Towns, Buildings, Construction could be considered the "big bang" that illuminated a universe of design patterns. If software design patterns comprise one of this universe's galaxies, interaction design patterns comprise another one.
An interaction design pattern is a design pattern that describes a solution to a common usability or accessibility problem in a specific context such as software development. Interaction design patterns are used in interaction design, where products are designed for human use. For example, consider how human beings might interact with a holographic display. Would we control the device through physical controls or via a virtual (shimmering) control panel?
Software developers typically engage in interaction design when we consider the usability of a user interface (UI), such as Microsoft's Metro UI for Windows 8. As you might recall, Metro was designed to be user-friendly on tablets, but proved less accommodating for desktops. The controversy surrounding Metro proves that interaction design is a challenging and important field.
Interaction design history
Interaction design pre-dates the digital era; for example, consider America's automotive industry in the early 1900s. The fact that an American automobile's steering wheel is on the left side of the vehicle, and not the right, is an example of interaction design. In the digital realm, Xerox's Palo Alto Research Center (PARC) invented the GUI and mouse, which have been enabling users to interact with their computers since the 1970s. (Both components were popularized by Apple via its early Macintosh computers.)
In the mid-1980s, human-computer interaction pioneers Bill Moggridge and Bill Verplank coined the term interaction design. Ten years later, other designers rediscovered this term and started to use it.
In 1999, Web consultant Jenifer Tidwell presented the first substantial set of interaction design patterns via her Common Ground collection. Since then, she has written Designing Interfaces, which presents new and revised patterns.
More interaction design pattern libraries have since emerged. The Yahoo! Design Pattern Library currently offers 59 user interface patterns. Android Patterns is a pattern repository for designing Android mobile apps.
Interaction design patterns in the real (and virtual) world
Tidwell presents an extensive catalog of interaction design patterns on her website. Most of her patterns are documented in terms of examples, context, problem, forces (tradeoffs being considered), solution, and (often) a resulting context. The Narrative pattern presented in Figure 1 is a good example (courtesy of Jenifer Tidwell).
Patterns can be combined to solve particular design problems. Figure 2 shows an example where several interaction design patterns are combined in a traditional telephone interface, as shown in Figure 2 (courtesy of Jenifer Tidwell).
Martijn van Welie has collected many examples of interaction design patterns used by web designers. You are likely familiar with the Breadcrumbs pattern, which helps website visitors know where they are in a site hierarchy, and also makes it easier for them to navigate back to higher levels.
The breadcrumb bar in the above design is typical. It presents a path that shows the location of the current page in the total page hierarchy. Each hierarchy level is labeled and behaves as a link to that level. The current page is marked in some way to give feedback about where the user is currently located and should not be presented as a link. Note that in Figure 3 the
> symbol is used to separate breadcrumbs.
Microsoft's Windows 7 Explorer program presents another example of the Breadcrumbs pattern. While navigating the filesystem, the breadcrumbs control located at the top of the window presents the path to the current folder. Each folder in this chain is presented as a button that you can click in order to examine the folder's contents. You can also click on any of the parent folder buttons, as shown in Figure 4.
Architectural patterns have much in common with software design patterns but are broader in scope. Whereas software design patterns address issues at the source code level, architectural patterns address them at the higher level of software architecture. Issues addressed by architectural patterns include hardware performance limitations, high availability and scalability, and business risk minimization. Architectural patterns come in many flavors and are often best learned by studying an implementation example. The patterns below are further discussed in the linked JavaWorld articles and case studies:
- An ETL (extract, transform, load) architecture focuses on the extraction of data from outside sources, the transformation of this data to fit operational needs, and the loading of the transformed data into a data warehouse or other destination. Also see "ETL - Extract, Transform, Load" for a use case and a demonstration.
- An event-driven architecture promotes the production, detection, consumption of, and reaction to events (significant changes in state). For example, a vehicle's state changes from "for sale" to "sold" when it is purchased.
- A layered architecture structures an application so that it can be decomposed into groups of subtasks. Each group of subtasks exists at a specific level of abstraction. The traditional three-tier client/server model is an example of this architectural pattern. Also see Design Pattern: Layers.
- Multi-tier architecture is a client-server architectural pattern in which presentation, application processing, and data management functionality are separated into logical layers or tiers.
- Naked objects is a pattern that requires all business logic to be encapsulated by domain objects (that is, business objects); that the user interface be a direct representation of these domain objects, with all user actions focused on creating or retrieving domain objects and/or invoking methods on those objects; and that the user interface be automatically generated from the definition of the domain objects.
- A pipe and filter pattern transforms data from one format into another by passing it through a series of filters (transformation processes) that are connected via pipes (data conduits). The ETL pattern typically leverages the pipe and filter architecture pattern to transform extracted data into a format that's capable of being stored in a data warehouse.
- Service-oriented architecture (SOA) provides a set of principles and methodologies for designing and developing software in the form of interoperable services, such as Web services. Various design patterns have been documented for solving problems related to SOA. For example, Version Identification addresses the problem in which a published service contract has changed and clients of this contract are unaware of the change, which results in clients missing an opportunity to utilize the change or being negatively impacted by the change.
Model-view-controller is an architectural pattern that most Java developers are familiar with, for instance from using Struts or Spring. In MVC a model stores application data and business rules, the controller mediates input and converts it to commands for the model or view, and the view is any output representation of the model's data, such as a chart or a diagram.
There is some confusion as to whether MVC is a software design pattern or an architectural pattern. In "
" blogger Kamal Wickramanayake makes the case for MVC being both a software design pattern and an architectural pattern.
See Resources for more implementation examples for the above architectural patterns.
Architectural pattern or style?
The term architectural style is often used as a synonym for architectural pattern. Furthermore, architectural style examples are presented that seem to be the same as architectural pattern examples; for example, pipes and filters. However, these terms are somewhat different, as explained in the Stackoverflow topic "What's the difference between Architectural Patterns and Architectural Styles?"
An organizational pattern documents the structure of relationships within a professional organization. Such patterns are discovered, documented, and used in order to help organizations achieve their goals. Although they're generally applicable throughout an organization, organizational patterns typically provide guidance for managing software development processes.
Organizational patterns apply to the structure of organizations rather than to the structure of source code and software architecture. Organizations have human-like characteristics (being comprised of humans); as such they can learn, and they can also be dysfunctional. By studying organizational behavior, lessons can be learned and documented as patterns that are shared with other organizations.
Organizational patterns aren't created or invented, but are discovered through empirical observation. This was demonstrated by early research at Bell Laboratories, in which patterns were discovered by analyzing social networks. This research used empirical role-playing techniques to gather information about the structure of relationships in the subject organization. These structures were analyzed for recurring patterns across organization and their contribution to achieving organizational goals. Successful structures were written up in pattern form to describe their tradeoffs and detailed design decisions (forces), the context in which they would apply, along with a generic description of the solution.
Organizational patterns provide an incremental path to improving an organization. The pattern style of building the organization works as follows:
- Find the weakest part of the organization.
- Find a pattern that is likely to strengthen the weakest part.
- Apply the pattern.
- Measure the results.
- If the pattern improved the situation, go back to Step 1 and find the next area for improvement. Otherwise, undo the pattern and try an alternative pattern.
Agile development as an organizational pattern
Organizational patterns are closely associated with the agile approach to software development. This approach focuses on iterative and incremental development where requirements and solutions evolve through collaboration between self-organizing and cross-functional teams. Agile is often contrasted with the more traditional waterfall method of software development.
Agile consultant James Coplien pioneered work on organizational design patterns and presented a paper on this topic at the Pattern Languages of Programs conference held in 1995. Together with Neil Harrison, Coplien subsequently collected organizational patterns and combined them into a collection of four pattern languages. This collection was then presented in Organizational Patterns of Agile Software Development, published in 2004.
In the book, Harrison and Coplien presented four inter-related pattern languages: Project Management, Piecemeal Growth, Organizational Style, and People and Code. Consider the following agile project management patterns:
- Community of Trust: When assembling any project team, it's essential that team members trust each other so that work can get done. Interpersonal relationships have a positive or negative impact on the team's effectiveness.
- Size the Schedule: A project must be understood and its size estimated before work begins. Developers become complacent when a project schedule is too long, and become overtaxed when the schedule is too short. Reward developers who meet the schedule.
Here are two Piecemeal Growth patterns:
- Size the Organization: Large projects are rarely delivered on time and within budget when their development teams are too large or too small. Start projects with a critical mass of about 10 people to avoid having to add more people late in the project.
- Phasing It In: Start a project by hiring people who possess a business's core competencies and then gradually add people as the project grows.
Coplien also discussed organizational patterns in a talk entitled "Organizational Patterns: A Key for Agile Software Development" (INCOSE Speaker Series, May 2007). Coplien pointed out that software managers face an overwhelming number of strategies and techniques for managing a software development project, that system theory has shown that processes emerge from organizational structures, and that organizational patterns combine this theory with time-tested management and organizational techniques.
Communication and presentation patterns
Communication and presentation are essential to the software development cycle. Software development team members need to communicate effectively with each other and also with a project's stakeholders. Giving effective presentations may be part of that process. Is it any surprise the patterns for successful communication and presentation have been documented?
People don't just communicate through speech, we also do it through body language and writing. Various patterns can be observed in these exchanges. Researching communication patterns, I found "What are the Pattern of communication?" which defines a communication pattern as a mode of communication used frequently in certain situations or with certain people. Are any of the following communication patterns familiar to you?
- Apologizing frequently
- Criticizing other people
- Lecturing (in a bad or good way)
- Peacemaking (it's okay, he didn't mean what he said)
- Praising (sincerely)
- Questioning (sincerely wanting to understand)
- Self-disclosing (explaining your thoughts)
- Supporting (you can do it)
The first six communication patterns reflect negative forms of communication. Apologizing frequently is an example of an anti-pattern because it may at first appear beneficial, but ultimately can get on the hearer's nerves, especially because the apology is often either meaningless (habitual) or intended to help the utterer and not the recipient feel better. A person who repeatedly apologizes could try to break their habit or seek professional help to change this pattern.
Lecturing can be applied in a negative or a positive manner. This pattern is destructive when used to punish the recipient without imparting anything helpful while serving only to benefit the lecturer. However, when used to impart information solely for the recipient's benefit (that is, constructive criticism), this pattern is constructive. The last six communication patterns listed are considered to be entirely positive forms of communication.
Effective communication is an essential part of achieving a successful project. It pays to learn positive communication patterns and employ them as often as possible.
Communication patterns and public speaking
The American Communication Association has created a free online guide to help students learn to be effective in public speaking. One part of this guide discusses communication patterns for public speaking. The discussion is divided into verbal and non-verbal categories, and focuses on communication in a cultural context. Patterns are categorized as low-context communication or high-context communication.
Communication often involves public speaking or presentation. You might be called to present a short talk on a new technology at a conference or in a company meeting. Presentation styles vary from unidirectional (talking only) to more bidirectional (talking and listening/responding to feedback). A presentation can be accompanied by a slideshow or other visual aids.
A presentation pattern is a design pattern for making presentations more effective. Three masterful presenters -- Neal Ford, Matthew McCullough, and Nathaniel Schutta -- demonstrate the value of presentation patterns in "Presentation Patterns: Demonstrations Versus Presentations" (InformIT, August 2012). One of these patterns, Shoeless is named for JavaWorld contributor Venkat Subramaniam, whose habit of presenting shoeless is almost as famous as his dynamic presentation style. The Shoeless pattern is described in Figure 5.
Being able to deliver effective presentations can greatly benefit your software development career, and learning various presentation patterns can help to boost their effectiveness. If you struggle with shyness, patterns can help in this area. Telling a joke at the beginning of a presentation is an example of a very successful presentation pattern that both humours the audience and relaxes the presenter.
This article concludes a three-part series investigating design patterns used in software development. You've learned about software design patterns, interaction design patterns, architectural patterns, organizational patterns, and communication and presentation patterns. The universe of design patterns undoubtedly includes many more design pattern categories.
Design pattern terminology isn't always precise. For example, perhaps the Gang of Four should have named their book Software Design Patterns. As I discussed in Part 2, design patterns can be misused, and anti-patterns can emerge. However, design patterns have proven to be helpful when used correctly. Familiarizing yourself with design patterns of different types can help you progress through your career in Java and beyond.
Learn more about this topic
- Read the earlier articles in this series: Part 1 is an overview of design patterns, including their history and classification; Part 2 is a fresh look at the Gang of Four patterns, especially Strategy and Visitor.
- "Using Patterns in Architecture to Reduce Risk" (Peter Jarman, IASA.org) is an excellent, in-depth survey of architectural patterns.
- See "Introduction to Software Engineering/Architecture/Design Patterns" for an overview of pattern types used in software architecture.
- See the SOA Patterns page for an extensive listing of SOA patterns. Also see "Lean SOA with Java EE 6" (Adam Bien, JavaWorld, April 2009).
- Architectural patterns are often combined. In "Event-driven services in SOA" (JavaWorld, January 2005) Jeff Hanson offers a guided tour of Mule's architecture, demonstrating how the ESB messaging framework combines event-driven and service-oriented architectures.
- "Distributed transactions in Spring, with and without XA" (Dave Syer, JavaWorld, January 2009) presents seven transaction-processing patterns for Spring applications.
- "The ESB Architectural Pattern" (IBM ISV and Developer Relations Group) and "Implementing the Enterprise Service Bus Pattern to Expose Database Backed Services" (Lucas Jellema, Oracle Technology Network, December 2011) describe the ESB. pattern in detail.
- See Organizational Patterns For Software Architecture for more organizational pattern examples.
- See "What Are the Five Organizational Patterns for Public Speaking?" ( Michael Brent, ehow.com) to learn more about patterns for public speaking.