MSDN Magazine - August 2008 - (Page 40)

CRC Cards Responsibility-Driven Design is closely linked to a lightweight modeling technique known as CRC cards (Class or Candidate/Responsibility/Collaborators). These are actual cards used for exploratory design. To draw up a CRC card, simply take a 3” x 5” note card and write the proposed name of a class across the top of the lined side of the card. On the unlined side of the card, write a sentence or two that serves as a purpose statement for the class. The purpose statement should reflect the Object Role Stereotypes of the class. Divide the lined side of the note card into two columns. in the left column, list the responsibilities of the class (something along the lines of “knows the invoice header information” or “decides whether to send an e-mail message” or “sends an e-mail message”). Again, each of these responsibilities should fit in with the object role stereotypes of the class. in the right-hand column, list other classes that must be interacted with in order to fulfill the duties in the left-hand column. CRC cards seem to have been passed over in popularity by Uml modeling, but the technique is very effective, much simpler, and all you need is a stack of 3” x 5” note cards. See c2.com/doc/ oopsla89/paper.html for more information on CRC cards. RDD identifies the six common stereotypes listed in Figure 1. Before I go on to describe these six in detail, I should point out that you can blend stereotypes within a single class. For example, a single class will frequently be both an information holder and a structurer. You might also find some value in defining your own stereotypes within a project. (See the “CRC Cards” sidebar for another idea for modeling elements of your application.) Information Holder Last year I worked on an energy trading system. In that system users might enter a trade to purchase 1,000 barrels of gasoline. In Figure 2 Handling Units of Measure and Quantity // UnitOfMeasure is a strongly typed enumeration that "knows" about, // and can answer questions about a logical Unit of Measure public class UnitOfMeasure { public static readonly UnitOfMeasure MT = new UnitOfMeasure(2500); public static readonly UnitOfMeasure LB = new UnitOfMeasure(1); // In a real system you'd have to do the conversion by using // the density from the real commodity in the barrel public static readonly UnitOfMeasure BBL = new UnitOfMeasure(100); private readonly double _weightInPounds; protected UnitOfMeasure(double weightInPounds) { _weightInPounds = weightInPounds; } // To make the system easier to extend, let's make sure that the // responsibility for converting quantities between various units of // measure in the UnitOfMeasure class public double ConvertIntoThisUOM(Quantity quantity) { return quantity.Amount*quantity.Uom._weightInPounds/_weightInPounds; } order to make that trade, we had to check the on-hand inventory, which was frequently tracked in metric tons, and compare the desired quantity with the on-hand quantity. Several other times we had to compare two quantities that were in different units of measure. Let’s say that you were building a simplistic energy trading system from scratch. One of the most obvious responsibilities in the system is to represent a quantity of something being traded. Another is to make all of those “less than” or “greater than” determinations. As you probably already know, in order to compare two quantities in the energy system, you have to know the numeric amount and unit of measure of both quantities (you’ll probably also need to know the density of the commodity being traded, but I’m skipping over that). One approach would be to create an Information Holder to “know” facts about unit of measure and quantity conversions. The desired behavior might lead you to two different classes like the ones shown in Figure 2. The Quantity class is an example of the Money pattern (also known as a Whole Value). Quantity is an information holder. Any time the rest of the application has a question about difference or sum of two quantities, the application just has to ask a Quantity object. Quantity doesn’t know where its data comes from or how it’s going to be consumed. Because of its simplicity, the Quantity isn’t all that useful on its own, but that very same simplicity makes it easy to reuse in different ways. Two of the other domain concepts in an energy trading system are trades and allocations (see Figure 3), both of which contain a surprising number of quantities. The Trade class is strictly responsible for providing data and making determinations about an energy trade. The Trade uses the information in the Allocation class, and both the Trade and Allocation classes use the Quantity class to make decisions. The entity and value objects in a rich domain model are a common example of information holders. An information holder may collaborate with service providers like data access classes or private readonly double _amount; private readonly UnitOfMeasure _uom; public Quantity(double amount, UnitOfMeasure uom) { _amount = amount; _uom = uom; } public double Amount { get { return _amount; } } public UnitOfMeasure Uom { get { return _uom; } } public bool IsLessThan(Quantity other) { double otherAmount = _uom.ConvertIntoThisUOM(other); return _amount < otherAmount; } // Also implement // bool IsGreaterThan, Equals, Subtract, Add, etc. } public class Quantity { } 40 msdn magazine Patterns in Practice http://c2.com/doc/oopsla89/paper.html http://c2.com/doc/oopsla89/paper.html

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.