| michael brennan |

New Blog

2011-04-01T13:48:00.000-05:00

My new blog is at http://thoughts.michaelbrennan.net

Why You Should Always Use the ‘var’ Keyword in C#

2010-06-30T15:23:00.000-05:00

Using the ‘var’ keyword in C# has always spurred a hot debate among developers. I believe ‘var’ should be used at all times. I believe this not because I choose to be “lazy,” as those who argue against it frequently claim. Of all the reasons I use ‘var’, laziness is not one of them.

I’ve argued for the constant use of ‘var’ countless times; this blog post is a collection of thoughts that I have compiled resulting from my arguments. Below are my reasons for using ‘var’ all of the time.

It decreases code-coupling

Coupling between code and its dependent code can be reduced by using ‘var’. I do not mean coupling from an architectural perspective nor at an IL-level (the type is inferred anyway), but simply at the code level.

Example:

Imagine there are 20 explicit type references spanning over twenty code files to an object that returned an another object of type IFoo. By explicit type references, I mean by prefacing each variable name with IFoo. What happens if IFoo changes to IBar, but the interface’s methods are kept the same?

Wouldn’t you have to change it in 20 distinct places? Doesn’t this increase coupling? If ‘var’ was used, would you have to change anything? Now, one could argue that it is trivial to change IFoo to IBar in a tool like ReSharper and have all of the references changed automatically. However, what if IFoo is outside of our control? It could live outside the solution or it could be a third-party library.

It is completely redundant with any expression involving the "new" operator

Especially with generics:

ICalculator<GBPCurrency, GBPTaxType> calculator = new GBPCalculator<GBPCurrency, GBPTaxType>

can be shorted to:

var calculator = new GBPCalculator<GBPCurrency, GBPTaxType>

Even if calculator is returned from a method (such as when implementing the repository pattern), if the method name is expressive enough it is obvious the object is a calculator. The name of the variable should be expressive enough for you to know what the object it represents is. This is important to realize: the variable expresses not what type it represents, but what the instance of that type actually is. An instance of a type is truly an object, and should be treated as such.

There is a distinction between an object and its type: an object exists at runtime, it has properties and behaviors; types simply describe what an object should be. Knowing what type an object should be simply adds more noise to the source code, distracting the coder from what an object really is.

An object may be brought into this world by following the rules governed by a type, but this is only secondary information. What the object actually is and how it behaves is more important than its type. When we use an object at runtime, we are dependent on its methods and properties, not its type. These methods and properties are an object’s behaviors, and it is behaviors we are dependent upon.

The argument for knowing a variable's type has been brought up in the past. The move from Hungarian notation in Microsoft-based C++ to non-Hungarian notation found in C# is a great example of this once hot topic. Most Microsoft-based C++ developers at the time felt putting type identifiers in front of variable names was helpful, yet Microsoft published coding standards for C# that conflicted with these feelings.

It was a major culture change and mind-shift to get developers to accept non-Hungarian notation. I was among those who thought that non-Hungarian variable naming was downright wicked heresy and anyone following such a practice must be lazy and did not care about their profession. If knowing a variable’s type is so important, shouldn’t we then preface variable names in Hungarian style to know more information about an object's type?

You shouldn't have to care what the type of an object is

You should only care what you are trying do with an object, not what type an object may come from. The methods you are attempting to call on an object are its object contract, not the type. If variable names, methods, and properties are named appropriately, then the type is simply redundant.

In the previous example, the word "calculator" was repeated three times. In that example, you only need to know that the instance of a type (the object) is a calculator, and it allows you to call a particular method or property.

The only reason a calculator object was created was so that other code could interact with its object contract. Other code needs the calculator’s methods and properties to get something done. This need has no dependency on any type, only on an object’s behaviors..

For example, as long as the object is a calculator, and the dependent code needs to call a method named “CalculateTax,” then the dependent code is coupled to an object with a method called “CalculateTax” and not a specific type. This allows for much more flexibility, because now the variable can reference any type as long as that type supports the “CalculateTax” method.

‘var’ is less noisy than explicitly referencing the type

As programming languages evolve, we spend less time telling the compiler and the computer what to do and more time expressing problems that exist in the specific domain we are working in.

For example, there are a number of things in C++ that are very technical with respect to the machine, but have nothing to do with the domain. If you are a customer of Quicken or Microsoft Money, all you really want to do is manage your finances better. These software packages allow you to do that.

The better a software package can do this for you, the more valuable it is to you. Therefore, from a development perspective value is defined by how well a software package solves a user's problem. When we set out to develop such software, the only code that is valuable is the code that contributes to solving a particular user’s problem. The rest of the code is unfortunately a necessary waste, but is required due to limitations of technology.

If we had infinite memory, we would not need to worry about deleting pointers in C++ or garbage collection in C#. However, memory is a limitation and therefore the technician in us has to find ways of coping with this limitation.

The inclusion of ‘var’ into the C# language was done for a reason and bookmarks another iteration of C# (particularly C# 3.0). It allows us to spend less time telling the compiler what to do and more time thinking about the problem we are trying to solve.

Often I hear dogma like "use var only when using anonymous types." Why then should you use an anonymous type? Under these conditions you usually do not have a choice, such as when assigning variables to the results of LINQ expressions. Why do you not have a choice when using LINQ expressions? It's because the expression is accomplishing something more functional and typing concerns are the least of your worries.

In the ideal C# world, we would not have to put any words in front of a variable name at all. In fact, prefacing a variable with anything just confuses the developer even further, and allows for poor variable names to become a standard whereby everyone is reliant upon explicit type references.

Arguments against using ‘var’

Some of the arguments I have heard against using ‘var’ and my responses to these are:

“It reduces clarity” – How? By removing the noise in front of a variable name, your brain has only one thing to focus on: the variable name. It increases clarity.
“It reduces readability and adds ambiguity” – This is similar to #1: readability can be increased by removing words in front of the variable and by choosing appropriate variable names and method names. Focusing on type distracts you from the real business problem you are trying to solve.
“It litters the codebase” – This is usually an argument for consistency. If your codebase uses explicit type references everywhere, then by all means do not use ‘var’. Consistency is far more important. Either change all explicit references in the codebase to ‘var’ or do not use ‘var’ at all. This is a more general argument that applies to many more issues, such as naming conventions, physical organization policies, etc.

As a final thought, why do we preface interface names with “I” but not class names with “C” as we did in the days when Microsoft-C++ was the popular kid in school?

Introducing Context Specification

2009-09-22T10:46:00.000-05:00

Introduction

Context Specification is a lot more than merely a new way to write tests. Although it was conceived around the same time as Behavior-Driven Development (BDD), and probably inspired by some of the BDD concepts, it is quite different.

The difference between Context Specification and BDD lies in semantics and purpose. Both are concerned about driving development through behaviors rather than implementation artifacts like classes or components.

BDD frameworks are typically purposed to acceptance testing. Recently, programmers encouraged customers to participate in requirements specification by writing the acceptance tests with tools like FIT. Acceptance testing frameworks are built with the assumption that business experts will be writing tests.

Acceptance testing frameworks often presume the user experience will be as rich as it is for the programmer. However, a programmer’s notion of readability and elegance is usually quote different than a non-programmer’s notion of readability and elegance. Often, programmers’ notions of readability and elegance will be different among themselves.

The Given/When/Then grammar is a good example of programmer’s presumption of a good user experience. We have to remember that when we create a tool to be used by non-programmers, we are designing user interaction and user experience. Programmers are historically the least effective people in creating a good user experience.

Given/When/Then grammar is good for capturing all of the details of a given scenario, but chooses to convey a lot of information in prose. Using prose for this purpose often leads to run-on sentences that defeat effective communication.

Specifications written with the Given/When/Then grammar are just as likely to be hard to read. The grammar can be an obstruction to learning, communication, and understanding.

Creating descriptions of specific uses of software is Context Specification’s primary concern. As with BDD and Test-Driven Development, the descriptions are specifications that end up driving development, and leave behind an automated test suite.

Who Writes Specifications? Who Writes Tests?

Programmer’s don’t like to write documentation, and business experts don’t like to write tests. Context Specification is about creating a specifications document with code. However, it doesn’t presume business experts will be writing the tests. Programmer’s write the test; that’s what they’re good at; business experts are good at being business experts.

Context Specification’s semantics focus on transforming traditional tests into specifications. These specifications serve as descriptions and documentation for how a system behaves under the various situations that the system is put into. Context Specification grammar is designed to make specifications easy to read and understand.

The goal is to create specifications that can be understood by anyone. If defining specifications for business experts, the business experts should be able to understand the specifications that you are writing. The implementation of the specifications in code should be easy to understand by programmers.

Context Awareness

Context is a word used to describe the situations and conditions a system is put into by a user. Context is often not fresh on the minds of programmers when writing tests because we’re often too caught up in thinking of the technical aspects of the problem.

Focusing on the programming language and the tools around them can distract programmers from context. Scott Bellware has spoken several times about this concept, and his work is my motivation for this article.

We need to do our best to be aware of context as we write tests, or specifications. We need to avoid thinking like programmers when writing and programming specifications. Context Specification can help us with this thinking.

The Context Specification Mindset

Scott Bellware describes the proper Context Specification mindset to have by stating, “Specify the experience, not the implementation.”

Instead of thinking about technical terms and programming ideas like classes, methods, and modules when writing test, consider the subject of the test in a particular context that has a related set of side-effects that you can observe. The observable side-effects are called specifications in Context Specification grammar.

The test suite isn’t really organized around specific abstractions in your system, unless the abstractions are organized around system behavior instead of data. Subjects and context can describe one class or several classes. Specifications reflect the observable effects of one method or several methods.

Subjects, contexts, and specifications show the true value of the code you are creating from the perspective of business objectives rather than implementation details. If you write specifications for subjects within a context, you end up writing code for what is truly important within your domain.

Example Context Specification Thought Process

There are a number of frameworks and methods to practice Context Specification with. In the .NET world, SpecUnit.NET, MSpec, Specter, or simply NUnit with some syntactic sugar can be used to write specifications.

While these are very functional frameworks, I believe the Ruby RSpec framework is the most elegant and easiest to use. Therefore, to make things simpler I will be writing all of my specifications using RSpec and all of my production code in Ruby.

(I intend to write an article on how to use IronRuby with RSpec to test .NET code; stay tuned)

Let’s use an iPod as an example since most people are familiar with how iPods function at a basic level. While we write specifications we will remain aware of the context by not performing a technical dissection of the problem.

Context Specification grammar requires a subject, context, and observable conditions. In this example, the subject is an iPod. One of the contexts could be, “when playing.”

What conditions can you observe when an iPod is playing? Without Context Specification, the answer depends on who is answering the question. If a programmer is answering the question, you will get a very technical answer. If a layman is answering the question, you will get a more general answer.

The laymen might say, “when an iPod is playing, it should display the track name, artist, and album name; it should also play the track.”

Conversely, a programmer might say, “when an iPod is playing, it should find the audio file in the audio file database, load it into the audio player, and send a signal to the audio player to start playing the audio track, update the LCD to re-draw the screen with the appropriate information,” and this can go further into more technical dissection. The programmer’s dialog is hyper-descriptive.

However, with Context Specification, the specifications should be defined in a way so that almost anyone can understand them. Because the layman understands the context in a more general circumstance, their specifications are more acceptable.

Typically, the best person to work with when defining specifications is the person who knows the specifics of how a system should behave, without necessarily knowing how the technical aspects should be woven together. A product owner is a good example of this.

Product owners know how their product helps their business, and how it may help their customers. However, they really don’t care about implementation details, such as the usage of a producer-consumer pattern to manage I/O requests, or adhering to SOLID principles.

Defining a Specification

Let’s start writing specifications for when an iPod is playing. One of the more obvious specifications, as stated from the laymen’s quote above, is “it should display the track name.”

Using RSpec, here is the code that defines this specification:

  1: require 'spec'
  2: 
  3: describe "iPod", "when playing" do
  4:   it "should display the track name"
  5: end

Now let’s look at the RSpec output from this specification:

*
Pending:
iPod when playing should display the track name (Not Yet Implemented)
./ipod_spec_definition.rb:4
Finished in 0.015 seconds
1 example, 0 failures, 1 pending

RSpec informs us that there is 1 example and 1 pending, because we haven’t written the implementation of the specification yet. Notice the readable output? RSpec can generate a nifty HTML document with all of the specifications for reference. This can be helpful to business experts for verifying the correctness of specifications.

It is important to note that the context is typically in the gerund form of a verb (“ing” form, e.g “when running,” “when drinking,” etc.) This eliminates accidental communication of timing or synchronization factors to the reader.

For example, the context “when beginning to run” is irrelevant because it is inclusive in the context “when running.” The same is true for “when finished running” because that statement occurs “when running” as well. Programmers might not immediately understand this logic, but from a communication mindset and for the purposes of documentation it conveys the appropriate intent.

Implementing a Specification

Let’s start implementing the first specification: “iPod when playing should display the track name.”

Following traditional TDD practice, the implementation starts by building a skeleton of the code required for the compiler and with a failing test:

  1: require 'spec'
  2: require 'not_a_mock'
  3: 
  4: class Ipod
  5:   def play
  6:   end
  7: 
  8:   def display_track_name
  9:   end
 10: end
 11: 
 12: describe Ipod, "when playing" do
 13:   before :each do
 14:     @ipod = Ipod.new
 15:     @ipod.track_methods
 16:     @ipod.play
 17:   end
 18: 
 19:   it "should display the track name" do
 20:     @ipod.should have_received(:display_track_name)
 21:   end
 22: end

The implementation of the first specification is performed by providing a body to the specification we are trying to implement, asserting that the iPod should received the display_track_name method.

Since the instance variable “ipod” does not exist, the “before” block is added to create a new instance of an “Ipod” class and assigns it to the instance variable needed. The “before” block is run before each specification is run.

Since all specifications will require an instance of an Ipod, this block makes writing future specifications convenient and further clarifies what subject the specifications are being written for (or more traditionally, the “system under test”).

In order for the Ruby compiler to accept this code, we have to provide a skeleton Ipod class and define the methods that are being called within the specification and the “before” block (“play” and “display_track_name”).

Note that I’ve elected to use a mocking framework called NotAMock. NotAMock is an extension to RSpec that records all calls on an object in question. I’ve further extended the framework so that you can call “track_methods” without specifying arguments to the method. Previously, you would have to specify each method you wanted to track. My change has been merged to the trunk and can be found here.

After running the new changes in the RSpec runner, the output is:

F
1)
'Ipod when playing should display the track name' FAILED
#<Ipod:0x2b90c24> didn't receive display_track_name
./ipod_spec_implementation_failing.rb:20:
Finished in 0.094 seconds
1 example, 1 failure

Notice the test failed with the message “#<Ipod:0x2b90c24> didn't receive display_track_name". RSpec is reporting that the “display_track_name” method on the instance of the Ipod class was never called.

Now it’s time to execute the next traditional step of TDD: make the test pass with the least amount of work. Adding a call to the display_track_name method inside the play method satisfies the RSpec test. Re-running the RSpec runner will show that the test indeed passes without error.

Now, obviously simply adding a call to the display_track_name method within the play method is an incorrect implementation. Therefore, we are lead to the final phase of traditional TDD: refactor:

  1: require 'spec'
  2: require 'not_a_mock'
  3: 
  4: class TrackRepository
  5:   def self.get_random_track_set
  6:     # query database to return random track set
  7:     [ "track1", "track2", "track3" ]
  8:   end
  9: end
 10: 
 11: class Lcd
 12:   def display_track_name(track_name)
 13:     # interface with hardware to display track name
 14:   end
 15: end
 16: 
 17: class Playset
 18:   attr_reader :current_track_name
 19: 
 20:   def self.create_random_playset
 21:     tracks = TrackRepository.get_random_track_set
 22:     playset = Playset.new(tracks)
 23:   end
 24: 
 25:   def initialize(tracks)
 26:     @tracks = tracks
 27:     @current_track_name = @tracks[0]
 28:   end
 29: end
 30: 
 31: class Ipod
 32:   def initialize
 33:     @lcd = Lcd.new
 34:     @current_play_set = Playset.create_random_playset
 35:   end
 36:   
 37:   def play
 38:     display_track_name(@current_play_set.current_track_name)
 39:   end
 40: 
 41:   def display_track_name(track_name)
 42:     @lcd.display_track_name(track_name)
 43:   end
 44: end
 45: 
 46: describe Ipod, "when playing" do
 47:   before :each do
 48:     @ipod = Ipod.new
 49:     @ipod.track_methods
 50:     @ipod.play
 51:   end
 52: 
 53:   it "should display the track name" do
 54:     @ipod.should have_received(:display_track_name)
 55:   end
 56: end

The “play” method now asks the “current_play_set” instance variable what the current track name is and provides it to the “display_track_name” method. This leads to creating the “current_play_set” instance variable, the “Playset” class, and a few other classes and methods.

After running the RSpec test runner again, the above code satisfies the test without issues. We know that we’ve safely refactored our code to a decent implementation without changing any behavior.

It’s important to realize that one specification could drive out several methods and several classes. It’s not necessary to pair subjects to classes, and specifications to methods. Notice the specification we implemented lead to the creation of 4 classes and several methods.

Once further specifications have been introduced at a more detailed level, it’s quite possible to switch contexts or subjects (or both) and further define specifications. However, this is not a license to start specifying technical terms in our native programming mindset.

Technical specifications should be reworded in less technical terms as much as possible. Nonetheless, it’s still possible to run into scenarios where technical speech is unavoidable such as in describing state machines.

Summary

Context Specification’s focus is not about providing a new tool to write tests in an innovative way. Programmers obsess over tools, and often the goal of Context Specification is eclipsed by programmer mentality to find new ways of doing things.

While it does provide a much different way of writing tests, it requires a change in traditional programmer thinking. A subject within a context must be thought of, and observable conditions form the specifications for that subject in its context.

This demands programmers sway their technical minds from more of a usability, high-level, business oriented mind while defining specifications, and back down to the essence of the technology they are using when writing the code that satisfies those specifications.

Providing documentation this way ensures that whomever can understand the subject and its context can understand the documentation and how that subject is used. This swaying prevents writing documentation that is too technical.

There are few instances when technical specifications need to be defined for a particular subject or context. However, one example where I’ve run into that particular situation involves a sub-system that performs connection caching. It is perfectly acceptable to write specifications for the caching operations under these circumstances because they define an inherent requirement.

Context Specification allows you to write documentation for subjects within specific contexts that are most important, and makes you more aware of what you are trying to test and write code for.

Domain awareness is strengthened by thinking more about a subject and context and less about object-oriented technical feats and the latest and greatest programming technology of the hour. The quality of a solution’s design and code is improved by getting closer to the true problems in the domain.

I hope you have fun writing specifications for your subjects and their contexts!

Special thanks to Scott Bellware for providing the inspiration of these article and for reviewing it.

An Interesting Article on DDD & Ruby

2009-06-08T11:04:00.001-05:00

Fábio Rehm and I have recently started talking about DDD and how to best implement some of the ideas in Ruby. He just posted a very interesting article on his attempt at implementing a basic customer/order DDD example in Ruby. Check it out: http://dddonruby.wordpress.com/2009/06/08/my-aproach-for-doing-ddd-on-ruby-introduction-and-part-i

Expressiveness in Modern Programming Languages

2009-06-06T20:58:00.001-05:00

The Technical Aptitude Required for Object-Oriented Programming

One of the primary purposes of an object-oriented programming language is to recreate representations of solutions to specific problems with code. These representations are transformations of solutions that were typically solved previously with human interactions.

Sometimes certain problems are solved only with the feat of modern computer software. In other facets, ingenuous minds forge an inventive technology in software not unlike the ways of the great mechanical inventors of our age.

Traditional object-oriented programming has been one of those great technical inventions. While simple guidelines allow most programmers to attempt object-oriented programming, only few understand the principles and practices to actually model real concepts correctly.

Frequently, programmers create objects that simply do not exist in the domain, or are bastardizations of the true domain concept. Unfortunately, in these scenarios success is short-lived. Maintainability quickly degrades, and often the code is completely thrown away.

Incorrect representations of the domain are similar to the adage of trying to fit a square peg into a round hole. Perhaps it’s possible to do this with creative technical feats. However, as more features are requested, as bugs are fixed, and the code evolves, misrepresentations are quickly revealed.

When this happens, feature requests and bug fixes take longer than expected, and a tremendous amount of pressure is put on the development team to meet deadlines. Managers and executives begin to wonder why it is taking so much time to complete what they think are smaller tasks.

All-nighters, pizza, and an insane amount of coffee support the developers through their death march. If you have been developing for a decent amount of time, I am sure you have told of such horror stories over lunch or over a good beer.

The Expressiveness of a Language Matters

How do we prevent this pain? There are several factors that contribute to these unfortunate events, however expressiveness within source code can be an important piece of the puzzle. The best developers are often the most expressive in the language he or she is operating in.

Instead of engineering solutions using technical wizardry and concepts that only programmers can understand, being expressive within the source code can keep business rules intact as development continues and solutions evolve.

Expressiveness is a quality that developers must constantly be working toward. Interestingly enough, the choice of a programming language can greatly assist in this struggle. The more expressive a language is, the easier it is for the programmer to think about the domain.

If non-programmer types and developers communicate with a ubiquitous language, this language can pervade into the source code. The pervasiveness of a domain’s language allows ideas to be more easily understood.

Contrasting Language Expressiveness

On May 30th, 2009, Scott Bellware gave a talk entitled, “A Handful of Things You Can Do in Ruby That Scares the Pants Off of C# Developers.” In this fascinating talk, Scott showed two functionally equivalent, plain classes: one defined in C#, the other defined in Ruby.

An interesting illustration emerged when Scott showed how the C# class’s definition comprised of a lot more statements to instruct the compiler on what to do and how to perform. These statements take the programmer’s mind away from the domain and bring him or her to thinking in a technical programming wonderland.

On the other hand, the Ruby class contained very little compiler instructions; the class was mostly comprised of domain expressions. This is a powerful illustration, so I’d like to show it as well as a means of illustrating expressiveness.

Let us define a simple class that records recommendations of businesses. Recommendations can be used for any business type, such as restaurants. A ‘recommender’ can recommend a business only once. The class will allow a means to determine how many recommendations all of the businesses have received.

The C++ Definition (brace yourself)

First, I will define the class using one of the most traditional object-oriented programming languages: C++. Let’s start as we always do with C++: with a header file definition:

   1: #pragma once

   2: #include <map>

   3: #include <vector>

   4: #include <string>

5:

   6: using namespace std;

7:

   8: namespace BusinessRecommendations

   9: {

  10:     class RecommendationTracker

  11:     {

  12:     public:

  13:         typedef vector<pair<string, unsigned int>> RecommendationTotalsList;

14:

  15:         void AddRecommendation(const char* recommender,

  16:                                const char* business);

  17:         void GetRecommendationTotals(RecommendationTotalsList& recommendations) const;

18:

  19:     private:

  20:         typedef map<string, vector<string>> RecommendationsMap;

21:

  22:         RecommendationsMap recommendations;

23:

  24:         bool HasRecommenderRecommendedBusiness(const char* recommender,

  25:                                                const char* business);

  26:         void RecordRecommendation(const char* business, const char* recommender);

  27:     };

  28: }

This will define the basic contract that consuming code will use to work with the RecommendationTracker class. Pay particular attention to the usage of pointers, references, “constness”, and other statements used to tell the compiler what to do.

Now that we’ve declared the contract, lets look at the overly verbose definition of the class:

   1: #include <algorithm>

   2: #include "RecommendationTracker.h"

3:

   4: using namespace std;

5:

   6: namespace BusinessRecommendations

   7: {

   8:     void RecommendationTracker::AddRecommendation(const char* recommender,

   9:                                                   const char* business)

  10:     {

  11:         if (HasRecommenderRecommendedBusiness(recommender, business))

  12:             throw exception("You may only recommend the same business once.");

13:

  14:         RecordRecommendation(business, recommender);

  15:     }

16:

  17:     void RecommendationTracker::GetRecommendationTotals(

  18:         RecommendationTotalsList& recommendationTotals) const

  19:     {

  20:         for (RecommendationsMap::const_iterator it =

  21:             recommendations.begin();

  22:             it != recommendations.end();

  23:             ++it)

  24:         {

  25:             recommendationTotals.push_back(make_pair(it->first,

  26:                 it->second.size()));

  27:         }

  28:     }

29:

  30:     bool RecommendationTracker::HasRecommenderRecommendedBusiness(

  31:         const char* recommender,

  32:         const char* business)

  33:     {

  34:         RecommendationsMap::const_iterator it =

  35:             recommendations.find(business);

  36:         if (it == recommendations.end())

  37:             return false;

38:

  39:         return find(it->second.begin(), it->second.end(), recommender) !=

  40:             it->second.end();

  41:     }

42:

  43:     void RecommendationTracker::RecordRecommendation(const char* business,

  44:                                                      const char* recommender)

  45:     {

  46:         recommendations[business].push_back(recommender);

  47:     }

  48:  }

Once again, we have several statements regarding constant state of pointers, language like “it->second.size()”, which refers to the size of a vector that is the value portion of a map. Look at how the class name is repeated before each function definition; this tells the compiler what scope we are in.

Although not appearing in this example, frequently C++ programmers have to tell the compiler whether they want to allocate objects’ memory on the stack or heap, and have to manage the lifetime of that memory.

All of these intrinsic C++ concepts force the programmer to be very technical. Much time is spent on considering the language itself rather than the domain.

The C# Definition (a little better)

Now lets port this same class to C#. C# is a bit more modern than C++, slightly more functional, and isn’t so concerned about telling the compiler what to do.

One slight problem: since there is no easy way to return a list of pairs as in the C++ definition, I’ve created a small helper class called “RecommendationTotal.” I could have returned a dictionary, but the usage of a dictionary in C# usually suggests something other than name/value pairs:

   1: namespace BusinessRecommendations

   2: {

   3:     public class RecommendationTotal

   4:     {

   5:         public RecommendationTotal(string business, uint numberOfRecommendations)

   6:         {

   7:             Business = business;

   8:             NumberOfRecommendations = numberOfRecommendations;

   9:         }

10:

  11:         public string Business

  12:         {

  13:             get;

  14:             private set;

  15:         }

16:

  17:         public uint NumberOfRecommendations

  18:         {

  19:             get;

  20:             private set;

  21:         }

  22:     }

  23: }

Some may argue that this adds readability to the code; for C#, it probably does. Now, the definition of the RecommendationTracker class is as follows:

   1: using System;

   2: using System.Collections.Generic;

3:

   4: namespace BusinessRecommendations

   5: {

   6:     public class RecommendationTracker

   7:     {

   8:         private readonly IDictionary<string, ICollection<string>>

   9:             recommendations = new Dictionary<string, ICollection<string>>();

10:

  11:         public void AddRecommendation(string recommender, string business)

  12:         {

  13:             if (HasRecommenderRecommendedBusiness(recommender, business))

  14:                 throw new Exception(

  15:                 "You may only recommend the same business once.");

16:

  17:             RecordRecommendation(business, recommender);

  18:         }

19:

  20:         public IEnumerable<RecommendationTotal> RecommendationTotals

  21:         {

  22:             get

  23:             {

  24:                 foreach (var business in recommendations.Keys)

  25:                 {

  26:                     yield return new RecommendationTotal(business,

  27:                         (uint) recommendations[business].Count);

  28:                 }

  29:             }

  30:         }

31:

  32:         private bool HasRecommenderRecommendedBusiness(

  33:             string recommender, string business)

  34:         {

  35:             return recommendations.ContainsKey(business) &&

  36:                 recommendations[business].Contains(recommender);

  37:         }

38:

  39:         private void RecordRecommendation(string business,

  40:                                           string recommender)

  41:         {

  42:             if (!recommendations.ContainsKey(business))

  43:             {

  44:                 recommendations[business] = new List<string>();

  45:             }

46:

  47:             recommendations[business].Add(recommender);

  48:         }

  49:     }

  50: }

It’s nice that the declaration and definition are now combined into one, and we don’t have to deal with header files anymore. However, there are still many references to compiler instructions.

Every method must tell the compiler whether it should make the method public or private. There are several references to types, such as “IEnumerable<RecommendationTotal>” and “IDictionary<string, ICollection<string>>.”

These compiler instructions and type declarations take our minds away from thinking about the business and have us spend more time on thinking about programming.

The Ruby Definition

Now let’s look at the same code in Ruby:

  1: class RecommendationTracker
  2:     def add_recommendation(recommender, business)
  3:       has_recommender_recommended_business?(recommender, business) do
  4:         raise StandardError, 'You may only recommend the same business once.'
  5:       end
  6: 
  7:       @recommendations[business] << recommender
  8:     end
  9: 
 10:     def recommendation_totals
 11:       recommendation_totals = Hash.new
 12: 
 13:       @recommendations.each_key do |business|
 14:         recommendation_totals[business] =  @recommendations[business].length
 15:       end
 16: 
 17:       recommendation_totals
 18:     end
 19: 
 20:   private
 21:     def initialize
 22:       @recommendations = Hash.new do |recommendations, business|
 23:         recommendations[business] = Array.new
 24:       end
 25:     end
 26: 
 27:     def has_recommender_recommended_business?(recommender, business)
 28:       return false if !@recommendations.has_key? business
 29:       return false if !@recommendations[business].include?(recommender)
 30: 
 31:       yield
 32:       true
 33:     end
 34: end

Notice how concise the Ruby definition is? Compiler instructions are kept to a minimum, and the statements seems to emphasize the logic of the domain more. Furthermore, all unnecessary references to types have been removed.

Simple one line boolean statements have been rearranged in a “action if condition” format instead of “if action then condition.” Methods have a question mark to add to readability. Overall, the code is simply a lot more expressive.

Summary

Contrast the Ruby definition to the original C++ definition. We’ve come a long way haven’t we? What’s frightening is to think that Ruby was created in 1992! For some reason, it’s only recent that it has been receiving a lot of attention (probably due to Rails and the direction of software toward web platforms).

C++ is still a great language, and has its place within specific industries. Game development is still primarily performed in C++, mainly due to the performance requirements where every bit of speed must be squeezed out of the code.

C++ is definitely a professional programming language, and requires the programmer to understand the power it can provide. A high degree of technical aptitude is required to create concrete, easy to understand, scalable, and powerful applications in C++. Unfortunately, it also takes more time.

However, instead of focusing on technical aptitude, developers should focus on adding value to the domain they are developing for. This means most thought should be spent thinking about how best to express the core domain, where all of the business rules and logic should reside.

Compiler instructions and nifty technical tricks are cool, but they take time away from adding to the core domain. As Eric Evans has illustrated, the easiest way to determine the core domain is ask why is the development effort important? How will the code you are writing help the business compete?

The answer to those questions should point you straight to the core domain. Expressiveness allows developers to define the core domain with a refined eloquence that helps lead to a deeper understanding of the problems at hand.

If source code is less infected with technical concepts, true domain problems are more easily read. This greatly adds to maintainability, and allows object-oriented principles to be practiced more easily.

I am excited to see more developers diving into Ruby. Hopefully, as the community becomes even more established than it already is, we will all start creating more elegant designs and expressions of problems without focusing too much on telling the compiler what to do.

Organizations That Thrive off of Waste – Anti-Lean

2009-05-31T18:15:00.001-05:00

The Lean Thinking Movement

The primary goal in Lean software development is to eliminate waste and optimize flow. This is accomplished by applying the theory of constraints and reducing the time it takes to produce artifacts in areas of a process that take the most time.

Lean ideology is critical for private organizations who cannot survive unless they optimize their business. Customers who give an organization money choose to do so solely because the organization provides the best product or service for a fair price.

As soon as another organization can produce something better, or cheaper, or a combination of the two, customers’ loyalty will promptly shift to the better organization. Capitalism thrives off of this concept: better products and services are created and refined due to competition.

Capitalism can be a beautiful thing, allowing free-enterprise to provide us with a high-tech culture, provides phenomenal products and services, creates jobs, and allows our economy to thrive. However, some organizations do not thrive off of competition.

Thriving off of Waste

Some organizations actually thrive off of being wasteful. Margins are improved by overproducing or extending the amount of time it takes to provide value.

For example, in his talk on Scrumban at the 2009 Austin Code Camp, Joe Ocampo described an insurance company who took longer to process claims because they made more money by doing so.

I am not exactly sure how they profit from this condition; perhaps it reduces their risk, or allows their investments to squeeze out more interest before they pay for a claim.

Milk The Government

The federal government has been doing business like this for years. The government encourages wasteful contractors. It is no secret that major contractors underbid government projects on purpose in order to get the contract. Once out of money, the contractor simply asks for more.

Since everybody in the sector knows that the government operates like this, they are free to underbid by great margins, fully understanding they will not be able to complete the project with the original bid.

Contractors will extend time lines, get paid to create features that add no value, and perform a number of other tricks to squeeze as much milk from the government utter as possible. How is this possible? The answer is the opposite of way capitalism thrives: lack of competition.

Since contractors only have one customer to satisfy, and they all know how that customer operates, they work together to pry as much cash out of government hands as possible. One major contractor does the majority of the underbidding, while subcontractors negotiate for their slice of the pie.

Under these circumstances, efficiency, optimization, adding value, eliminating waste, and all of the other tenants of Lean thinking do not make any sense. If a contractor changes to embrace Lean thinking, they provide a more valuable product but are not rewarded for it.

A Lean contractor would get paid less because the competition would underbid them. The competition receives more money to create more waste and less value. This type of business model has to stop!

“Change We Can Believe In” - President Obama’s Campaign Slogan?

Companies who thrive off of waste destroy what is best about a capitalistic society. The bigger a wasteful industry is, the more it hampers the economy, and sets back the great achievements of a culture. Does anyone know how to change these industries? Has anyone had success?

The biggest problem I am aware of is the Federal Government. We have got to get them to change their ways. President Obama has stated that he wants to improve the government’s way of doing business.

How do we start?

2009 Austin Code Camp Was Great!

2009-05-30T22:26:00.001-05:00

I started off watching Jimmy Bogart introduce C# 4.0. I had watched a video last year where Anders Hejlsberg introduced C# 4.0 more in depth. Jimmy’s presentation was quite good, but seeing an introduction to C# 4.0 prior to the code camp, I wish I would have gone to Joe Ocampo’s “Git For People.”

The talk on S.O.L.I.D. principles by Derick Bailey was great. However, I only attended half the talk, and left after the explanation of the open-closed principle. I have done a lot of reading on S.O.L.I.D. principles, and this was more of a recap for me.

I went to Scott Bellware’s “A Handful of Things You Can Do in Ruby That Scares the Pants Off of C# Developers.” This was one of the most entertaining talks of the day.

Ruby was fighting to be my favorite language in the past couple of months; after today it definitely is now my favorite. Scott showed some meta-programming that had a few C# developers’ jaws dropping.

I think the best talk of the day was Joe Ocampo’s discussion on Scrumban. I had yet to see how to implement Lean principles into an actual process. Joe showed his process and went into great detail. Not only was the presentation informative, but Joe, as a speaker, is very entertaining!

Finally, Chad Myers gave a very detailed presentation on how to use FubuMVC. Chad delivered exactly what I’d been hoping for: how exactly to get started with it. Prior to today, I had a hard time getting started with FubuMVC. Chad presented great documentation on how to do just that.

My Schedule For Austin Code Camp

2009-05-24T18:59:00.001-05:00

The schedule for the 2009 Austin Code Camp has been posted, and I have picked which sessions I will be attending. The Code Camp is this Saturday, May 30th.

It was very tough to pick which classes I wanted to attend due to the great content. Here is what I picked, with the class I would have attended had the main pick not been available:

09:00am - 10:00am
Room 103, Sneak Peek at C# 4.0 by Jimmy Bogard
Runner up: Git for People by Joe Ocampo

10:00am - 12:00pm
Room 103, S.O.L.I.D. Software Development: Achieving Object Oriented Principles, One Step At A Time by Derick Bailey
Runner up: Introduction to Web testing with Watir and Ruby by Jim Mathews

12:45pm - 02:45pm
Room 103, Enterprise Architecture Patterns: Presentation, Business Logic, and Persistence by Chad Myers & John Teague
Runner up: Intro to Scrumban by Joe Ocampo

02:45pm - 04:45pm
Room 207, Introduction to FubuMVC by Chad Myers
Runner up: Practical Inversion of Control by Matt Hinze

I hope to see you or meet you there!

Entities Should Not Depend on Other Objects

2009-05-24T13:52:00.002-05:00

For those familiar with Domain Driven Design (DDD), this may seem like common sense. However, as more people adopt DDD concepts, this subtlety is definitely something to pay attention to.

Quick Overview of Entities

In DDD, an entity is a design pattern used to describe an object in the domain model that is truly unique; it has its own identity and distinctive behavior. An easy way to identify entities is to ask yourself, “If I duplicate an instance of this object, will it cause data integrity issues or other problems within my domain?”

For example, an address might be a value object or an entity, depending upon how it is used in your domain. If an address can be duplicated and substituted in places where an address is needed without a problem, then it is a value object.

However, if an address is truly unique, as it might be in a post office application, a duplicate address would cause data integrity problems. If a package needed to be dispatched to a specific address, and two of those addresses existed with the same identity, this condition would cause problems; a package can only be delivered to one address.

An Example of Incorrectly Implementing Entities

Entities should be expressed with as much simplicity as possible. An entity should only contain business logic specific to itself. This concept is defined as plain-old CLR objects in C#/VB.NET, etc. (POCO), POJO in Java, PORO in Ruby, etc.

If you find your entities are dependent on other objects, this is usually a design smell calling for the use of the service DDD pattern. Let’s use the canonical customer/order example:

Look at the following sample dialog with a domain expert. This person is an expert in some sort of online retailing business you might be contracted to write software for:

You: So tell me a little bit more about your business, who are your customers?

Expert: We sell groceries online to people living in the New York City area. We are fairly new in the market and are are looking to automate our business a little more, that’s why we’re hiring you!

You: Great! I’ll do my best to improve your automation. Let’s start with your customers, how do they place orders?

Expert: First, they browse around our online store, adding items to their shopping cart. Once they are ready to checkout, they hit the checkout button. We get an email from the customer containing a list of items from our inventory, and the quantity of those items that they want to purchase.

Your brain starts to flash with ideas on how to improve their current system. First, you might make a value object to encapsulate line items in an order as follows:

   1: class LineItem

   2: {

   3:     public LineItem(uint itemId, uint quantity)

   4:     {

   5:         ItemId = itemId;

   6:         Quantity = quantity;

   7:     }

8:

   9:     public uint ItemId

  10:     {

  11:         get;

  12:         private set;

  13:     }

14:

  15:     public uint Quantity

  16:     {

  17:         get;

  18:         private set;

  19:     }

  20: }

Next, let’s focus on the representation of the customer in the domain model. The customer is definitely an entity; it cannot be duplicated and substituted for another customer, because this would result in the order being processed for the wrong person.

A representation of a customer in a domain model needs an address, and the ability to change that address. The domain expert stated that they do not service areas outside of New York City. One way of expressing that in the entity is to throw an exception whenever the customer tries to change their address to a city other than New York City.

Recall the domain expert stated, “We get an email from the customer containing a list of items from our inventory, and the quantity of those items that they want to purchase.” This statement might lead you to think that you need to encapsulate this behavior on the Customer class itself.

What the expert was really trying to communicate was that their current system compiles the customer information along with the order information and packages it up into an email. Regardless, you go along with it, and start thinking about how to implement that behavior within the customer class.

To handle the orders, you might have an order generator that serves as a DDD factory to create an order, along with an order processor that actually places the order in the system.

Enough analysis, we now have a pretty good idea of what the first iteration of the Customer class should look like:

   1: class Customer

   2: {

   3:     private readonly IOrderGenerator orderGenerator;

   4:     private readonly IOrderProcessor orderProcessor;

   5:     private Address address;

6:

   7:     public Customer(IOrderGenerator orderGenerator, IOrderProcessor orderProcessor) : this(orderGenerator, orderProcessor, new Address())

   8:     {

   9:     }

10:

  11:     public Customer(IOrderGenerator orderGenerator, IOrderProcessor orderProcessor, Address address)

  12:     {

  13:         this.orderGenerator = orderGenerator;

  14:         this.orderProcessor = orderProcessor;

  15:         this.address = address;

  16:     }

17:

  18:     public Address Address

  19:     {

  20:         get

  21:         {

  22:             return address;

  23:         }

  24:         set

  25:         {

  26:             if (newAddress.City != "New York City")

  27:                 throw new ArgumentException("We do not service customers in your area, sorry!");

28:

  29:             address = newAddress;

  30:         }

  31:     }

32:

  33:     public OrderResult PlaceOrder(IEnumerable<LineItem> lineItems)

  34:     {

  35:         var orderInformation = orderGenerator.CreateOrderFromLineItems(lineItems);

  36:         return orderProcessor.ProcessOrder(orderInformation);

  37:     }

  38: }

With this implementation, it seems very easy to place an order with code like this:

customer.PlaceOrder(lineItems);

The Correct Way of Implementing Entities

The problem with the Customer implementation is that it is coupled to an order generator and an order processor. This implies that in the real domain, customers have knowledge of these two services.

The way a customer is expressed in this domain model is fundamentally flawed. Customers do not know of such things; I frequently shop on Amazon.com, and I have no knowledge of an order generator, nor a processor.

In DDD, the order generator is an example of the factory pattern. Factories are only used to support a domain model, not to define the domain model. There are exceptions where the domain actually has some concept of creating something new, such as real factories.

The order processor is an example of the DDD service pattern, encapsulating interactions between other entities and value objects. Other services or a higher layer should be consuming the order processor, not entities or value objects.

A more appropriate implementation of the Customer class can be defined by stripping dependencies on the two services from the class, distilling what is truly important to a customer in this domain model. In this example, all that would remain is the validation that occurs when setting a new address.

This greatly simplifies the Customer class, and allows the definition to be a POCO:

   1: class Customer

   2: {

   3:     private Address address;

4:

   5:     public Customer() : this(new Address())

   6:     {

   7:     }

8:

   9:     public Customer(Address address)

  10:     {

  11:         this.address = address;

  12:     }

13:

  14:     public Address Address

  15:     {

  16:         get

  17:         {

  18:             return address;

  19:         }

  20:         set

  21:         {

  22:             if (value.City != "New York City")

  23:                 throw new ArgumentException("We do not service customers in your area, sorry!");

24:

  25:             address = value;

  26:         }

  27:     }

  28: }

Notice how simpler the class is? It contains business logic only. The messiness of invoking the services has been removed. The removed behavior is an excellent candidate for another service, due to its interaction with entities and value objects. Let’s create an OrderService class:

   1: class OrderService

   2: {

   3:     private readonly IOrderGenerator orderGenerator;

   4:     private readonly IOrderProcessor orderProcessor;

5:

   6:     public OrderService(IOrderGenerator orderGenerator, IOrderProcessor orderProcessor)

   7:     {

   8:         this.orderGenerator = orderGenerator;

   9:         this.orderProcessor = orderProcessor;

  10:     }

11:

  12:     public OrderResult PlaceOrderForCustomer(Customer customer, IEnumerable<LineItem> lineItems)

  13:     {

  14:         var orderInformation = orderGenerator.CreateOrderForCustomer(customer);

  15:         orderInformation.AddLineItems(lineItems);

  16:         return orderProcessor.ProcessOrder(orderInformation);

  17:     }

  18: }

The OrderService class adheres to the dependency inversion principle and can be configured with an IoC container to inject default implementations of the constructor dependencies. This service allows for interaction of the customer entity, line item value objects, an order generation service, and an order processing service.

It is quite common to have services be dependent upon other services. Services, factories, and repositories can have dependencies on other other pieces in the domain model or on infrastructure level objects.

We can now write a line of code to place an order similar to the previous line, without making direct calls on the Customer instance:

orderService.PlaceOrderForCustomer(customer, lineItems);

Summary

You should be weary of a design smell whenever your entities depend on other objects. These dependencies are typically domain model services or infrastructure pieces, such as logging or database support classes (ActiveRecord anyone?).

Keep your entities as simple and pure as possible. Leaving out threading, logging, and all of the other impurities that can muck up the class. Use services to encapsulate interaction between entities and value objects.

For further information, I recommend reading Eric Evans’ Domain Driven Design.

Domain-Driven Design: Tackling Complexity in the Heart of Software

Elegance in Code

2009-05-19T07:11:00.002-05:00

Elegance is a refined quality of gracefulness and good taste. An elegant solution to a problem is defined by an ingenious simplicity and neatness. Elegance demands an unusual effectiveness, and allows for complexity to be illustrated in a beautiful and fascinating way.

We should all strive for elegance in our code. Elegance is what allows clear communication of a solution, no matter how complex the problem may be.

Utterly expressive code conveys its intent explicitly, and facilitates an ease of acceptance for new features or changes to existing behaviors. In this way, illustrative code becomes the documentation of itself, eliminating the need for other artifacts to crack the code into more readable terms.

Haphazardly writing code, without a struggle for elegance, breeds endless cycles of sloppiness, “hacks,” maintenance nightmares, and confusing pieces to an endless puzzle.

Are you familiar with the broken window effect? The idea was first published in March of 1982 inside The Atlantic Monthly entitled, “Broken Windows,” by James Q. Wilson and George L. Kelling. An excerpt reads as follows:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters light fires inside. Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people start leaving bags of trash from take-out restaurants there or break into cars.

The broken window effect was used to cleanup the great city of New York in the 1990’s. Code can also have “broken windows” in the form of haphazardness, sloppiness, incompleteness, and hacks.

These broken windows can be fixed in an effort to strive toward elegance. The more the struggle toward elegance is cultivated, the easier maintenance becomes and new features are accepted with simplicity.

Bad architectural design of software that cannot be changed forces those who strive for elegance to bang their head against a wall repeatedly. Architectural changes are not cheap, and often perpetuate their cost as time goes by.

A bad architecture is like having a three-legged mule. The cost of hacking a solution up in order to ride on top of the three-legged mule will eventually compound until the mule trips and everything it was carrying crashes down with it.

Exceptional architectural design should be fanatically sought after by the people able to change it. Designers ought to be the masters of elegance; without an elegant design, the code which supports it is truly doomed.

Developers often misunderstand elegance and reduce its meaning to simplicity alone. Simplicity by itself is in no way elegant. Simplicity is not bad, but complete simplicity in a complex system is not possible; the complexities simply cannot be made simple. Elegance is required in these situations.

For example, a toaster is a simple contraption. You put an item in the slot, push the button down, and in a few minutes your toasted wishes come true. Functionally, this is a simple procedure.

However, attractive looking kitchens demand attractive looking toasters. A functional, beautiful toaster requires a bit of elegance:


A functional, inelegant toaster	A functional, beautiful, simple toaster

How can we be elegant developers? Unfortunately, there is no simple answer; elegance is not a design pattern. Usage of the proper design patterns in the proper place, and at the proper time, can positively affect the elegance of code.

Conversely, overuse or misuse of design patterns can quickly destroy any existent elegance. A continuous study of architectural design, code design, and experience while keeping elegance in mind will produce a great developer.

Therefore, the greatest developers can express complex ideas in a superior and fascinating way, explicitly communicate intent, and produce code that is surprisingly easy to read and maintain.

For further study, I would recommend reading Eric Evans’ Domain Driven Design. Eric is one of the most eloquent expressive writers I have ever read, and I am sure his code reads the same way. I would also recommend Robert C. Martin's Clean Code, as he is one of the most outspoken legends on the matter.

Domain-Driven Design

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

What happens when you change a struct to a class in .NET if you don’t recompile the type’s dependencies?

2009-05-18T08:56:00.001-05:00

An interesting issue arose out of a recent code review I was conducting. If you change a type from a struct to a class, do you have to recompile all modules that are dependent on that type?

Let’s use a simple example. The following diagram illustrates several packages that are dependent on a “Geometry” package, with the Geometry package containing a struct called “Point”:

Point is defined as follows:

   1: public struct Point

   2: {

   3:     public int X;

   4:     public int Y;

   5: }

In the dependent module, I’ve defined a class called “Consumer” and created a constructor that references the Point struct:

   1: public class Consumer

   2: {

   3:     public Consumer()

   4:     {

   5:         var point = new Point

   6:         {

   7:             X = 1,

   8:             Y = 5

   9:         };

  10:     }

  11: }

Let’s examine this constructor in IL:

   1: .method public hidebysig specialname rtspecialname instance void .ctor() cil managed

   2: {

   3:     .maxstack 2

   4:     .locals init (

   5:         [0] valuetype [DependentModule]Geometry.Point point,

   6:         [1] valuetype [DependentModule]Geometry.Point <>g__initLocal0,

   7:         [2] valuetype [DependentModule]DependentModule.Point CS$0$0000)

   8:     L_0000: ldarg.0

   9:     L_0001: call instance void [mscorlib]System.Object::.ctor()

  10:     L_0006: nop

  11:     L_0007: nop

  12:     L_0008: ldloca.s CS$0$0000

  13:     L_000a: initobj [ExampleModule]DependentModule.Point

  14:     L_0010: ldloc.2

  15:     L_0011: stloc.1

  16:     L_0012: ldloca.s <>g__initLocal0

  17:     L_0014: ldc.i4.1

  18:     L_0015: stfld int32 [ExampleModule]DependentModule.Point::X

  19:     L_001a: ldloca.s <>g__initLocal0

  20:     L_001c: ldc.i4.5

  21:     L_001d: stfld int32 [ExampleModule]DependentModule.Point::Y

  22:     L_0022: ldloc.1

  23:     L_0023: stloc.0

  24:     L_0024: nop

  25:     L_0025: ret

  26: }

Pay attention to lines 5 through 7; the “valuetype” instruction declares an instance variable as a value type. This is important, because it means that the memory that the variable “point” occupies will be passed by value, not by reference. Also notice line 13; this call’s the Point struct’s constructor.

If the Point struct changes to a class, the IL in lines 5 through 7 will throw an exception, because classes can’t be declared as value types. If we change, the Point struct to a class and recompile the Geometry and dependent modules, the constructor’s init block looks like this:

   4: .locals init (

   5:     [0] class [ExampleModule]DependentModule.Point point,

   6:     [1] class [ExampleModule]DependentModule.Point <>g__initLocal0)

Notice how the point variable is now being defined with the “class” instruction, telling the native-compiler to treat this variable as a reference type. Also, the call to initialize the variable has changed:

   13: L_0008: newobj instance void [DependentModule]Geometry.Point::.ctor()

Instead of using the “initobj” instruction, the “newobj” instruction is being used.

The impact of this nuance is very small, because everybody is either using a continuous-integration server to build their solutions (I hope). However, when you’re attempting to perform local changes on your development box this problem can manifest itself.

The Major Consequences of Using the C# “as” keyword

2009-03-01T10:21:00.000-06:00

I was recently trying to create my own "CaseInsensitiveString" class to behave as if character case did not matter in terms of comparison; this is easy enough, or at least it sounds like it is.

The first thing I did was override the Equals method to allow for case-insensitive comparison; easy enough. Next I added operator == and operator != for easier comparison syntax; easy enough. I also wanted to make my class be assignable from a string, and have it be implicitly castable to a string; easy enough, just provide an implicit operator string(MyClass) and an implicit operator MyClass(string). After righting some quick sanity unit-tests, a problem arose: all of these assertions work in this unit test:

        1: var caseInsensitiveString = new CaseInsensitiveString("Test String");

       2: string @string = caseInsensitiveString;

       3:  

       4: Assert.IsTrue(caseInsensitiveString.Equals(@string));

       5: Assert.IsTrue(caseInsensitiveString == @string);

       6: Assert.IsTrue(@string.Equals(caseInsensitiveString));

       7: Assert.IsTrue(@string == caseInsensitiveString);

However, line 7 will not work. Why?

After a little research, I found out that nUnit's Assert.IsTrue method is invoking the following version of System.String.Equals:

      bool Equals(System.Object obj);

Microsoft's implementation of this code is as follows:

       1: public bool Equals(System.Object obj)

       2: {

       3:     String str = obj as String;

       4:     if (str == null)

       5:     {

       6:         // exception will be thrown later for null this

       7:         if (this != null)

       8:             return false;

       9:     }

      10:  

      11:     return EqualsHelper(this, str);

      12: }

Do you see the problem yet? The "as" keyword, for whatever reason, does not invoke any casting operators! I find it strange that an explicit cast would work in this instance, or even an implicit cast, but not the "as" keyword.

The moral of the story is if you are using implicit type conversion operators, use the "as" keyword only if you only want the object in question to be explicitly casted to the type you provide. The “as” keyword works fine with inheritance chains (as well as the “is” keyword). However, in implicit type conversion operators it will not allow other objects to cast to the target.