Hello StructureMap#

In a comment on Derik Whittaker's post about using app.config with StructureMap, Brian Johnston asks for a simple "hello world" example. I figured I could re-create the app that I used when I was first learning StructureMap. This is a very simple demonstration of how to make an application use StructureMap. It does not get into the whys and whens for different scenarios. It is simply a piece of code that will let you see StructureMap "work" so that you can play with it. For more introductory details, I would highly recommend reading Chad Myers' posts that cover Basic and Medium-level usage scenarios for StructureMap.

Create the app

  1. Open Visual Studio
  2. Go to File | New | Console Application (hopefully you have Tools | Options | Projects and Solutions | "Save new projects when created" UNCHECKED so you aren't forced to choose a path for this throwaway code)
  3. Add a reference to StructureMap.dll (agonize over how slow the Add Reference dialog box is to open because it needs to populate the list on the .NET tab which will go unused when we switch to the Browse tab)
  4. Replace the contents of Program.cs with the code at the bottom of this post
  5. Run the application to see the English greeting.

Notes

  • The call to ObjectFactory.GetInstance in the Main method demonstrates how you get an object from StructureMap. Notice that it only specifies the interface for the type you'd like to retrieve so the caller is decoupled from the actual implementation that is used.
  • The ConfigureDependencies method is where I tell StructureMap which concrete implementations I would like to use for my interfaces. You can accomplish this same goal by decorating your interfaces and classes with attributes, or by using a configuration file.
  • Aside from the two bullet items above in the Program class, none of the rest of the code has any reference to or knowledge of StructureMap.
  • Notice that I only ever ask for an IAppEngine. I never had to explicitly ask for an IGreeter or IOutputDisplay. StructureMap was smart enough to recognize these dependencies of AppEngine and injected them automatically.
  • Change the second line in ConfigureDependencies so that TheDefaultIsConcreteType<FrenchGreeter> and run the application again. Notice that you now see the French greeting. You have changed the implementation that is used by AppEngine, without changing any of the application code (if you agree that the Program class is just your launching point, and not really part of the application logic). If you were using a config file to configure StructureMap, you wouldn't have had to change any code at all to see the different behavior.

Code

using System; using StructureMap; namespace ConsoleApplication1 { class Program { private static void Main(string[] args) { ConfigureDependencies(); IAppEngine appEngine = ObjectFactory.GetInstance<IAppEngine>(); appEngine.Run(); } private static void ConfigureDependencies() { StructureMapConfiguration.ForRequestedType<IAppEngine>().TheDefaultIsConcreteType<AppEngine>(); StructureMapConfiguration.ForRequestedType<IGreeter>().TheDefaultIsConcreteType<EnglishGreeter>(); StructureMapConfiguration.ForRequestedType<IOutputDisplay>().TheDefaultIsConcreteType<ConsoleOutputDisplay>(); } } public class AppEngine : IAppEngine { private readonly IGreeter greeter; private readonly IOutputDisplay outputDisplay; public AppEngine(IGreeter greeter, IOutputDisplay outputDisplay) { this.greeter = greeter; this.outputDisplay = outputDisplay; } public void Run() { outputDisplay.Show(greeter.GetGreeting()); } } public interface IAppEngine { void Run(); } public interface IGreeter { string GetGreeting(); } public class EnglishGreeter : IGreeter { public string GetGreeting() { return "Hello"; } } public class FrenchGreeter : IGreeter { public string GetGreeting() { return "Bonjour"; } } public interface IOutputDisplay { void Show(string message); } public class ConsoleOutputDisplay : IOutputDisplay { public void Show(string message) { Console.WriteLine(message); } } }
Friday, July 25, 2008 9:11:05 AM (Central Daylight Time, UTC-05:00) #    Comments [3]  | 

 

Losing your (type) religion#

As I stated in my last post, the var keyword is an acknowledgement that I do not care what the type of the variable is - I only care what it can do.

Into the IUknown

Most developer start on the path to this revelation when they discover interface-based programming.

Consider: we need to write a method that returns a collection of strings. Callers of the method will only need to loop over the items and perform some action. The number of elements to return is not known at compile time, so we'll declare a generic List<string>, populate it within a loop, and then return it to the caller.

The junior developer will declare the return type of the method as List<string>:

List<string> GetNames(){}

Acknowledging that callers should not be bothered with having to know an implementation detail (the fact that a List was used instead of a fixed-sized array), and knowing that they only need to loop over the returned items, a more experienced developer might declare the method:

IEnumerable<string> GetNames() {}

Which means any variable the receives the return value will also be typed as IEnumerable<string>:

IEnumerable<string> names = GetNames();

Here's the kicker - in both scenarios, the GetNames method is really returning an object of type List<string>! When the supposedly more experienced developer chooses to return a more abstract type like IEnumerable<string>, type information is lost. Yikes! The names local variable above holds a List<string> instance, but you (the client developer) don't know it. As scary as that might sound, you probably realize that you don't care. As long as you can do the things you need to do with names (loop over it), you are happy.

Walking like a duck

Now let's take that train of thought and consider duck typing in a dynamic language like Python. I can declare the following method:

def Recycle(service):
    service.Stop()
    service.Start()

It takes a single parameter named service. What is the type of the parameter that is expected? I don't know. And after the initial anxiety settles, there is the liberating realization that I don't have to care! All I know, or care, is that any object instance that is passed to this method must implement a Start() and a Stop() method. The same method can be used with instances of a Lawnmower, AuditLogger, or SongPlayer class (assuming they all have Start and Stop methods).

Getting closer to the goal

Let me be clear - I am not suggesting that implicit typing in C# 3.0 is the same as duck typing. What I am suggesting is that the 2 examples above are points along the "progression of understanding" of the same concept: it is the behavior of an object that really matters, as opposed to the type name that is attached to it. Interface-based programming is near the start. Implicit typing is further along the progression. Duck typing is closer to the end.

I think we will find that programmers who have been exposed to and understand languages which support duck typing will be more likely to be comfortable with and embrace the var keyword. They have already made the mental leap that type information serves the computer more than it serves the human. If you haven't yet, do yourself a favor and learn a dynamic programming language, even if you know you will continue to spend your days with static typing.

Wednesday, June 25, 2008 2:05:02 AM (Central Daylight Time, UTC-05:00) #    Comments [0]  | 

 

To var#

Dare Obsanjo asked the question To var or not to var? He asserted "case closed" at the end of his post, and closed it to further comments, but I would like to continue the conversation.

He pulls out the common straw man argument that the anti-var (C# 3.0's implicity type keyword) crowd likes to attack. They assume that fans of implicit typing just want to save a few keystrokes. It isn't about less keystrokes. For me, its about thinking a little bit less like a computer and a little bit more like a human. I prefer to think less about Types and more about behaviors. The var keyword is an acknowledgement that I do not care what the type of the variable is - I only care what it can do.

I'll address a few specific quotes from his post (emphasis is mine).

[Referring to ReSharper] So it seems there are two suggestion modes. The first suggests using the var keyword when the name of the type is obvious from the right hand side expression being evaluated such as casts or new object creation. The second mode suggests replacing type declarations with the var keyword anywhere the compiler can infer the type... The first suggestion mode makes sense to me since the code doesn't lose any clarity and it makes for shorter code. The second mode is the one I find problematic it takes information out of the equation to save a couple of characters per line of code.

In both situations, it is about removing compiler noise. I have already given the compiler enough information for it to do its job. I don't care about a couple characters.

For example, the claim that it leads to "better naming for local variables" really means it compels developers to use LONGER HUNGARIAN STYLE VARIABLE NAMES.

Longer, more descriptive variable names? Yes, please. Hungarian style? That assumes I care about the type (which I don't see my follow-up post).

...these long variable names add more noise to the code overall since they show up everywhere the variable is used compared to a single type name showing up when the variable is declared.

This is completely different understanding of the term "noise" as it relates to code. To me, "noise" in a computer language is all of the stuff that makes code look like something that needs to be decoded. It is all of the stuff that normal humans would not use when communicating with each other. Your source code is a communication medium - it communicates intent to the computer, and to the humans that need to maintain it. Anything that is added purely for the computer's benefit is noise to the human. It commonly takes the form of angle brackets, parentheses, semi-colons, etc. Sometimes it takes the form of redundant or extraneous type information. But I would never consider a descriptive variable name "noise", just because it takes up a little more screen real-estate.

It is interesting that Dare seems to reject the argument that var helps promote use of better variable names, and yet the example which spurred his post illustrates it perfectly:

I found this change to be somewhat puzzling since while it may have shortened the code by a couple of characters [There he goes counting characters again] on each line but at the cost of making the code less readable. For example, I can't tell what the type of the variable named lvi is just by looking at the code.

The var keyword did not make the code less readable, it just made the poor choice of variable names more apparent. Might listItem or feedItem be a little more readable than lvi?

It seems his primary argument against var is that always knowing the type of a variable is of utmost importance. Why? When you are writing code, doesn't your IDE let you know what behaviors are available to your object instances? When you are reading code, can you not assume that the compiler has already checked it for invalid code?

Wednesday, June 25, 2008 1:11:04 AM (Central Daylight Time, UTC-05:00) #    Comments [0]  | 

 

Building Domain Specific Languages in Boo on the .NET Platform#

Ayende Rahien will be giving a course on buliding DSLs with Boo in Austin on May 19-20. I'm a closet fan of Boo, having lurked on the mailing list for about 6 months, and really looking forward to getting a stronger grasp of the language, and the benefits of building your own domain specific languages. This is a great opportunity to learn from the preeminent creator of Boo DSLs.

Scott Bellware sent a good writeup to the AgileATX mailing list:

This class takes you deeper into the reasoning and power of dynamic
programming on the CLR.  It will show you how to build and take
advantage of DSL's for your own CLR applications, and why DSL's and
language-oriented programming are such a valuable practice at this
point on the programming timeline. 
You'll leave this class having been jump-started on a new, powerful
language and paradigm, and be connected to other motivated .NET folks
who are working toward bringing some of successes of dynamic
programming communities into the .NET community.

The class will also give you the opportunity to check out a town that
folks are starting to recognize as a progressive and leading .NET
competency in North America, and to have some fun with Austin's
developer community folks in lush green and sunshine of Central Texas.

There are still some spots open, if you are interested you can register here.

.NET | Boo
Saturday, May 10, 2008 10:45:43 PM (Central Daylight Time, UTC-05:00) #    Comments [0]  | 

 

The power of yield (return)#

Yield is one of the coolest, yet underused, new .NET 2.0 features that you may not be familiar with. Yes, I'm talking about a 2.0 feature - even though 3.5 just came out, it is my experience that a large number of developers have still not embraced all that 2.0 gave us. Hopefully this article will help make this powerful, yet initially confusing, feature more approachable.

Some background facts

When you "foreach" over an object (array, collection, etc), it must implement IEnumerable or IEnumerable<T> - the generic version which returns strongly typed objects (for the rest of this article, I'll just refer to IEnumerable).

All arrays, and most collections (ArrayList, List<T>) implement IEnumerable, which is why you can "foreach" over them.

If ALL you need to do to a collection is cycle through its members - you only need to reference it as an IEnumerable. That explains why the following code is perfectly valid:

IEnumerable<int> numbers = new int[] { 1, 2, 3 }; foreach (int i in numbers) { Console.WriteLine(i); }

It is always better to depend on abstract types (interfaces, abstract base classes) rather than concrete types. This allows you to change the implementation of a method without impacting any of its callers.

Consider this example where CallingMethod gets a set of numbers from MethodBeingCalled. It really doesn't care if it gets an array or a List or whatever. It just does a foreach over it, which means it only needs the functionality exposed by the IEnumerable interface.

public void CallingMethod() { List<int> numbers = MethodBeingCalled(); foreach (int i in numbers) { Console.WriteLine(i); } } private List<int> MethodBeingCalled() { List<int> numbers = new List<int>(); numbers.AddRange(new int[] { 1, 2, 3 }); return numbers; }

The problem with the current design is that the CallingMethod declares the list of numbers List<int>. That is a specific implementation detail. If CallingMethod needed to add more numbers to the list after it was returned from MethodBeingCalled, or if individual numbers were being accessed by their index, then it would make sense to declare it as a List<T> (or better, IList<T>). But it really only needs to cycle through the numbers in order. If MethodBeingCalled wanted to change its implementation to return an int[] instead, it would have to change its signature, and CallingMethod would also have to change. However, if CallingMethod had just declared its local variable as IEnumerable<int> (because that is the only functionality it truly depends on), then it would not have to change if MethodBeingCalled changes - as long as it still returns something that implements IEnumerable<int>.

So what does foreach do? It asks the IEnumerable if it has any items. If so, it gets the next item and uses it within the loop. It then asks the IEnumerable again if it has more items, gets the next one, and so on, until there are no more items. The important thing to note here is that foreach never works with the entire collection all it once - it only deals with one item at a time.

Introducing yield

How can we use all of this information? If you have a method that returns a collection of data, and you can be sure that callers are only going to be interested in looping over each item in the collection, one at a time (which is very common), you can declare your method's return value as IEnumerable<T>.

When you declare your method's return value as IEnumerable<T>, something magic happens: the C# compiler will now let you use the yield keyword within the body! So why does that matter? Because it allows you to take advantage of the way that foreach really works. Remember, foreach will just ask for one value at a time. When it does, it will call into your method - your method will run until it encounters a yield return statement. When it reaches a yield return statement, that value is immediately returned to the caller. In the next iteration of the caller's loop, it will ask again if there is another value, your method will start executing again, but this time it will start on the line after the last yield statement that was run. Yes, you read that right: execution alternates between the calling method and the method being called, all the way through the loop. This is completely different from the normal way that methods interact, where one method gives up control to another method, which doesn't return until it is completely finished executing.

This has at least 2 very important implications for the method that returns the IEnumerable<T>:
1) It does not need to build up a big list of all of the items it plans to return, holding them all in memory at the same time. If the list of items is very large, holding them all in memory at once can be a significant burden.

2) It does not necessarily need to do the work to produce all of the items in the list. If the caller breaks out of the foreach loop before the entire collection has been traversed - all of the work needed to produce the remaining items in the colleciton is avoided. Without using the yield keyword, you would have to build up the entire collection to return, even if the caller was only going to look at the first few items.

Demonstration

To illustrate the advantage of this approach, I included sample code at the bottom. You can create a new Console Application and paste this over the default Program.cs.

A method, GetCombinations returns a collection of 2 numbers combined. The caller then loops through the collection, looking for a specific combination: "13".

First, run it using GetCombinations. This is implemented the way most people would write a method that returns a collection, in .NET 1.1. The output willl look something like this (the indented output is from within GetCombinations):

BEFORE call to GetCombinations
        Beginning execution of GetCombinations
        Producing 33
        Producing 23
        Producing 13
        Producing 32
        Producing 22
        Producing 12
        Producing 31
        Producing 21
        Producing 11
        Ending execution of GetCombinations
AFTER call to GetCombinations
Checking 33
Checking 23
Checking 13
Found!
Elapsed: 00:00:08.9931583

Now, comment out the line that calls GetCombinations, and uncomment the line that calls BetterGetCombinations. It is important to note that BetterGetCombinations uses the exact same algorithm as GetCombinations - given the same input, they will both return the exact same list of strings, in the same order (I've emphasized the lines that changed, in the sample code below). But since the caller is only looking for a specific combination, not all combinations need to be produced. Consider the output:

BEFORE call to GetCombinations
AFTER call to GetCombinations
        Beginning execution of BetterGetCombinations <-- notice that BetterGetCombinations doesn't really start until the foreach loop - NOT when the method was first called!

        Producing 33
Checking 33
        Producing 23
Checking 23
        Producing 13
Checking 13
Found!
Elapsed: 00:00:02.9976438

With the improved implementation that took advantage of the yield keyword, the program was able to finish its job in less than half the time! It also used much less memory, as it never had to store all 9 strings in a collection. Now imagine the potential impact if GetCombinations returned a collection with thousands of entries!

Sample Code

Paste the code below over the default Program.cs in a new Console Application:

using System; using System.Collections.Generic; using System.Diagnostics; using System.Threading; namespace YieldDemo { class Program { static void Main() { Stopwatch timer = Stopwatch.StartNew(); Console.WriteLine("BEFORE call to GetCombinations"); //1) First try running using the GetCombinations that returns a List<string> List<string> combinations = GetCombinations(3, 3); //2) After observing the output, comment out the above line, uncomment the next line, and re-run // IEnumerable<string> combinations = BetterGetCombinations(3, 3); Console.WriteLine("AFTER call to GetCombinations"); foreach (string combination in combinations) { Console.WriteLine("Checking " + combination); if (combination == "13") { Console.WriteLine("Found!"); break; } } timer.Stop(); Console.WriteLine("Elapsed: " + timer.Elapsed); } static List<string> GetCombinations(int left, int right) { Console.WriteLine("\tBeginning execution of GetCombinations"); List<string> output = new List<string>(); int currentLeft; int currentRight = right; while (currentRight > 0) { currentLeft = left; while (currentLeft > 0) { string newCombinationToProduce = currentLeft.ToString() + currentRight; Console.WriteLine("\tProducing " + newCombinationToProduce); Thread.Sleep(1000); // simulate expensive process to produce a combination output.Add(newCombinationToProduce); --currentLeft; } --currentRight; } Console.WriteLine("\tEnding execution of GetCombinations"); return output; } static IEnumerable<string> BetterGetCombinations(int left, int right) { Console.WriteLine("\tBeginning execution of BetterGetCombinations"); // NOTE The local List is not necessary in this implementation int currentLeft; int currentRight = right; while (currentRight > 0) { currentLeft = left; while (currentLeft > 0) { string newCombinationToProduce = currentLeft.ToString() + currentRight; Console.WriteLine("\tProducing " + newCombinationToProduce); Thread.Sleep(1000); // simulate expensive process to produce a combination yield return newCombinationToProduce; // insteading of adding to a list, just return the value --currentLeft; } --currentRight; } Console.WriteLine("\tEnding execution of BetterGetCombinations"); } } }
Sunday, February 03, 2008 12:02:09 PM (Central Standard Time, UTC-06:00) #    Comments [18]  | 

 

All content © 2008, Joshua Flanagan
About this site
Send mail to the author(s) Contact me
Feed your aggregator (RSS 2.0)
Joshua Flanagan
I have been developing software professionally for 10 years; focusing on .NET since its release. I use this site to interact with, and contribute to, the .NET software development community.
Microsoft Certified Application Developer

On this page
Archives
Rest of the world

Acknowledgements

Powered by: newtelligence dasBlog 2.1.8209.14743

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Site theme based on the essence design by Jelle Druyts