MSDN Magazine - August 2008 - (Page 39)

JeRemy milleR Patterns In PractIce Object Role Stereotypes Object-oriented systems are composed of many objects, each one fulfilling some set of responsibilities. Objects often need to collaborate with other objects in order to fulfill these responsibilities. You can better understand the responsibilities of objects and the collaborations between them by applying a concept known as object role stereotypes. This article will discuss the most common object role stereotypes by applying them to real-world examples and well-known design patterns. Figure 1 RDD Stereotypes Stereotype Information Holder Structurer Controller Coordinator Service Provider Interfacer Description Knows things and provides information. May make calculations from the data that it holds. Knows the relationships between other objects. Controls and directs the actions of other objects. Decides what other objects should do. Reacts to events and relays the events to other objects. Does a service for other objects upon request. Objects that provide a means to communicate with other parts of the system, external systems or infrastructure, or end users. What’s the Problem? Neolithic programmers lived in a state of simplicity. Programs were composed of a singular straight, unbroken line of instructions to the computer. Even today, many of us initially learn to program by writing standalone functions: public static class Program { public static void Main(string[] args) { Console.WriteLine("Look at me World! I'm coding!"); // And about 30-50 other lines of code } } The single method style of program construction is the easiest form of programming to learn, but it breaks down quickly as the program becomes larger. Early programmers and computer scientists soon realized that they needed some way of managing complexity as software projects increased in scope and ambition. While it certainly didn’t have the same impact on mankind as the discovery of fire, the ability to decompose a single program into multiple subroutines, classes, or services gave programmers some fantastic advantages over the monolithic block of code: divide and conquer. You can turn a single big problem into a series of easily achievable tasks. The human mind simply can’t juggle so many different variables at one time. Decomposing a system allows you to deal only with one issue at a time, whether that be data validation, retrieval, or display. Ideally, the system becomes much easier to understand but there‘s plenty of potential for getting things wrong as you split up the system between developers, teams, or even different systems. Adding to this potential for trouble is the fact that a divide-and-conquer strategy enables you to more easily deliver the system’s functionality in increments, which means that your code will likely have to work seamlessly with code delivered in a previous release. Send your questions and comments to mmpatt@microsoft.com. As I discussed in the June issue of MSDN® Magazine, the Open Closed Principle can make code much easier and less risky to extend over time by dividing the responsibilities of the system into separate modules (see msdn.microsoft.com/magazine/cc546578). Those are significant benefits, but they come with a cost. You need to distribute the responsibilities of the system in a beneficial way. Fortunately there’s an entire software design method built around heuristic tools for determining and distributing the responsibilities of a system. Responsibility-Driven Design Responsibility-Driven Design (RDD) is an informal design method developed in the Smalltalk community in the late 1980s and early 1990s. Rebecca Wirfs-Brock, who conceived the theory, sums it up like this: “Objects are not just simple bundles of logic and data. They are responsible members of an object community.” As its name implies, RDD starts by breaking down a system or an individual feature into the various actions and activities that the system must perform, then proceeds to assign these responsibilities to objects within the system. Object responsibilities are described as either knowing, doing, or deciding. Once you have a list of responsibilities, you need to consider what the objects are going to be and how the responsibilities are going to be distributed between the objects. Objects within a system take on a role consisting of closely related responsibilities. You can employ object role stereotypes to help define the role of a single object in the system and to serve as a guide for assigning responsibilities to the various objects in the system. August 2008 39 http://msdn.microsoft.com/magazine/cc546578

Table of Contents Feed for the Digital Edition of MSDN Magazine - August 2008

MSDN Magazine - August 2008 Toolbox CLR Inside Out Basic Instincts Cutting Edge Patterns in Practice Data 2.0 - Expose And Consume Data In A Web Services World Biztalk EDI - Build A Robust EDI Solution With BizTalk Server Silverlight - Create Animations With XAML And Expression Blend Write On! - Create Web Apps You Can Draw On With Silverlight 2 Wicked Code - Craft Custom Controls For Silverlight 2 Team System Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - August 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.