Stuff by the Way

Prefer IEnumerable to IList for Public Members

2009-02-12T08:02:00.001-08:00

A coworker of mine knew vaguely of my preference for IEnumerable<T> over IList<T> for exposing collection members of a class. He needed to expose a collection and its count somehow, and asked me what I thought. Here it is:

I prefer IEnumerable<T> to IList<T> for the following reasons.

IEnumerable<T> is the lowest common denominator of collections, but still very useful as it is foreachable.

Because it is the lowest common denominator, my backing collection can be any number of specific collection types, including an array.

It is easy to return an empty, ad hoc, 'light-weight' enumeration: Enumerable.Empty<T>().

I can even not have a backing collection, and instead implement the enumeration in code using the yield keyword.

IList<T> has methods like Add() and Insert() and in most API situations I don't want clients adding members to my collection - IEnumerable<T> is immutable.

IEnumerable<T> is easily managed by Linq extension methods, e.g.

IEnumerable<IWidget> widgets = someObject.GetWidgets();
int count = widgets.Count();

Note that Count() is a method, not a property. It is an extension method (C# 3.0) that you have access to when you use System.Linq. The implementation, which you can see in Reflector, amounts to foreaching over the enumeration and incrementing a counter. It is efficient as it can be and we don't have to write it over and over.

It is simple to get an IEnumerable<T> into a List<T>:

List<IWidget> widgetList = new List<IWidget>();
widgetList.AddRange(widgets);

IEnumerable<T> is very composable - the new Linq extension methods allow you to do all sorts of magic with them - filtering, sorting, grouping, aggregation all chained together in a single line of code. IList<T> gets that too because it descends from IEnumerable<T>, but its pretty cool that the lowest common denominator collection gets this stuff.

The most persuasive argument is the one regarding clarity of the API. In every case I can think of, a collection property should present immutable interface, and IList<T> is mutable. If I thought I had a scenario where the client should be able to futz with my internal collection, I'd revisit my design because I probably have it wrong. IEnumerable<T> wins because it is clearly immutable.

There are alternatives that permit an IList<T> implementation that doesn't permit appending or inserting, but they're liars. For example List<T>.AsReadOnly() returns a ReadOnlyCollection, which implements IList<T>. But it lies. It has Add() and Insert() methods, but they always throw NotSupportedException. For me, it's a non-starter because the interface is misleading.

You could also just return a copy of your internal collection, something like this:

public IList<IWidget> Widgets
{
    get
    {
        IList<IWidget> temp = new List<IWidget>();
        temp.AddRange(_widgets);
        return temp;
    }
}

But I think this is just as misleading. Sure, you can honestly add and remove items, but it implies that it is the internal collection when it really isn't. Again, IEnumerable<T> wins because it makes the API clearer.

You may have a nagging concern that you are getting your Count by iterating through the enumerations rather than having and storing it somewhere. I wouldn't worry about it. It all the cases I can think of, this is trading cycles for clarity in the API. Clarity always trumps performance until we know or at least have a realistic expectation of a performance issue.

But even then, you needn't worry. Because wherever possible, these extension methods on IEnumerable<T> try cast it to a higher level collection to optimize the code. So the Count() extension method tries to cast the target to ICollection<T> so it can use the Count property. Only if it can't do that does it actually iterate through the enumerable to get the count. Check it out in Reflector.

IEnumerable<T> is a clear first class citizen with the addition of all those nifty new extension methods in System.Linq. And even without those, it should be the first choice for exposing an immutable collection.

Clean Code

2009-01-29T19:10:00.001-08:00

One of my refrain's at the recent SoCal Code Camp was "Simple Code." I was inspired by Scott Bellware's recent appearance on Hanselminutes where he equated simplicity with easy testability. It is a great podcast, and highly recommended. Ultimately the point is that we want the code we touch to become more simple. That is, more easy to understand, more easy to explain, more easy to change and more easy to test.

Well, Robert C. Martin (Uncle Bob) recently published a new book called Clean Code: A Handbook of Agile Software Craftsmanship which seems to be concerned with similar themes. I'd had it on my radar since Uncle Bob did a .NET Rocks a few months ago but hadn't gotten a copy yet. There's always more books than I have time for, particularly lately.

But after my code camp sessions, Vladimir mentioned that he was participating in a study group going through Clean Code. I had never heard of programmers doing such a thing, but it sounded great. I liked the notion of the added accountability that comes of joining a group project. "Hmmm," I thought, "that might be a great way to really learn a book."

A couple of days later when I asked Vladimir to let me know how the study group went, he surprised me with an invitation to join. So I went out and got a copy and started in on it.

My first 'meeting' was today, over the phone. And it was great. The whole conference call thing isn't real high on my list, but the book is solid and the discussion really added to it.

One meeting down and I think this has real promise. Uncle Bob is great, but Uncle Bob supplemented by a roomful of experienced software developers is a real treasure.

So I'll be attending, every Thursday at noon. Since I want to make sure I keep up my end of the discussion, I'll be taking copious notes as well. I'd like to find some way to turn them into blog posts too. so stay tuned and see what unfolds.

SoCal Rock and Roll Code Camp 01/2009

2009-01-26T07:57:00.001-08:00

Thanks to all of you who made it to my Dependency Injection sessions at the code camp. I really enjoyed doing the presentation. This was the third time I've presented this stuff and I've finally got the content into the neighborhood of where I want it, so I'm particularly satisfied.

I've gotten my slides cleaned up and saved off my sample code so I can post it on the code camp website. You can download slides and sample code for each session from its page. Here they are: Dependency Injection - Why Bother and Fun with Dependency Injection Containers.

I promised some links as well. Here they are:

Google Testing Blog - This is a great blog with vast amounts of solid practical advice. It is focused on Java rather than C#, but in most cases that won't be a problem. The principles are pretty much the same.

Particularly recommended here is the Guide: Writing Testable Code which appears to be the standards Google uses in code reviews. It is full of specific guidance and before and after examples both of code and unit tests. Again, mostly Java, but for the most part it shouldn't be a problem for C# developers.

The StructureMap site is full of good guidance on Dependency Injection Containers in general as well as StructureMap in particular.

You can find more about Autofac at Google Code. The wiki is a good source of guidance for Autofac's various features. Assuming the lambda syntax doesn't still make your brain hurt the samples are pretty easy to comprehend.

Don't forget Castle Windsor.

I spent a lot of time on the Single Responsibility Principle and the Open/Closed Principle. Robert C. Martin's (Uncle Bob) original articles are available from his web site: SRP and OCP.

Finally, a few great books:

Agile Principles, Patterns, and Practices in C#

Working Effectively with Legacy Code

Refactoring: Improving the Design of Existing Code

As I said in the sessions, feel free to contact me if you have a question you think I can help you with. It is a big topic.

Thank you again for attending. I had a lot of fun.

LA Code Camp Materials - They're Here!

2008-10-28T11:09:00.001-07:00

Okay, the Code Camp site is back up and I've been able to upload my code and slides. If you need a hand with any of it let me know. Here are direct links to each session's page.

Dependency Injection - Why Bother?

Fun with Dependency Injection Containers

In addition to the materials, there is a feedback button. I'd really appreciate it if you'd give it a click and fill it out - it won't take more than a minute.

Thanks again.

LA Code Camp Materials Part II

2008-10-28T08:25:00.001-07:00

You're probably thinking that this is the post where I say I've finally posted the sample code and slides. From the Code Camp last weekend. And maybe ask you to complete the evaluations online?

I thought it was too, until I discovered that the Code Camp site was down.

So maybe Tuesday isn't in the cards. Wednesday perhaps?

If anyone is desperate for the materials (which would be surprisingly nice) leave a comment and we'll figure something out.

But don't leave an email address unless you have a really good spam filter.

I'll try again later today. Thanks for your attendance and your patience.

LA Code Camp Materials

2008-10-27T12:24:00.001-07:00

Thanks again to all of you who attended my sessions at the Code Camp over the weekend. I had fun giving it - and the discussion was great.

I'll be posting slides and sample code on the Code Camp web site sometime on Tuesday - sorry about the delay.

Thanks again.

TDD Guidelines

2008-07-23T07:45:00.001-07:00

Heard a nice short podcast from NetObjectives on impediments to TDD this morning. I had to register to get to it, but it doesn't cost anything.

They considered the problems associated with TDD adoption. One which struck me in particular is the problem of many tests breaking when a minor change has been made. This tends to push developers to 'temporarily' ignore tests so they can get their work done. Which often becomes more than temporary. I know I've built up a test maintenance burden this way.

They addressed this by defining a "good" unit test as follows:

A unit test should fail always for a well understood reason.
A unit test should never ever fail for any other reason.
No other unit test should fail for that reason.

Well, I'm guilty.

Sometimes I get going on writing unit tests without being mindful of my 'well understood reason' just for the sake of hacking out tests. This is a nice formulation for me to keep in mind.

xUnit Test Patterns has a lot to say about this kind of thing too.

Dependency Injection Resources

2008-07-01T08:42:00.001-07:00

Here are the promised resources:

The Single Responsibility Principle by Robert C. Martin (Uncle Bob) is one of the design principles that makes Dependency Injection useful. Also recommend are his articles Open/Closed Principle; Dependency Inversion Principle; and Liskov Substitution Principle. All of these articles are more or less excerpts from his book Agile Principles, Patterns, and Practices in C#, so if you are interested in his book (which is great) these articles would be a good place to start before you make the investment. Remember there is a Java version of the book too (Agile Software Development, Principles, Patterns, and Practices).

Unfortunately due to the structure of my talk I gave these principles short-shrift, so I want to make myself clear while I have the chance: I consider them to be more important than the tool (the container). In fact, I suspect that if you aren't following SRP, OCP and DIP, a Dependency Injection container would be useless anyway.

While I'm on books, Refactoring: Improving the Design of Existing Code is a must have title. This is the book I mentioned in the talk that I bought years after having it recommended. It was too bad I waited, because the book was a revelation. Just the chapter on Code Smells alone is worth the price of admission.

The Castle Project's home page is a link worth having. There are some tutorials worth looking at here if you want to go deeper. Note that the Castle Project is a lot bigger than just the MicroKernel and Windsor Container - it also boasts the Monorail project (a .NET MVC web framework) and a really cool Dynamic Proxy. Great stuff.

Using Castle Project is a collection of Castle Windsor specific resources.

I'm not actively using StructureMap right now, but they just had a new release that is probably worth looking at. They also have a NAnt task for testing configuration, which is a really cool addition.

High-Level Concepts is a part of the StructureMap web site which gives some great summaries of concepts surrounding good design in general, and Dependency Injection in particular. These are important regardless of which container you use. It was written by Jeremy Miller, who's blog is a great resource no matter what he's talking about.

The IoC mind set: Validation is a pretty powerful article by Oren Eini on how to use a Dependency Injection Container (Castle in this case) to manage a multiplicity of validation rules. It addresses a point I had hoped to make with my final example but which got lost in the lack of time and the broken code. The container permits some *very* interesting efficiencies, that you just wouldn't come up with if you didn't have a container. It is what Oren calls the Inversion of Control Mind Set in this entry.

I'd recommend subscribing his blog if you really want to stretch your mind in this direction.

ALT.NET Portal is a good place to start for exposure to all of the ALT.NET stuff, not just Dependency Injection. The discussion groups on Yahoo are pretty rich.

Inversion of Control Containers and the Dependency Injection pattern is Martin Fowler's article on the topic. It is usually the first citation when someone covers this topic. It examines an alternative pattern as well - Service Locator.

Again, if any of you want further assistance with this stuff, call or email me and I'll be glad to help. Thanks again for attending!

Dependency Injection Containers Talk at SoCal Rock and Roll Code Camp

2008-06-30T08:16:00.001-07:00

Thanks again to all of you who attended. And to all of you who completed the evaluation forms. I had a lot of fun doing the talk, and look forward to delivering improved versions of it in the future.

I've printed out my slides to a PDF and put it on the session's page on the code camp web site. The sample code is also there now. I've only included the first two samples, but they should be enough to get you started playing around with the Windsor Container if you're interested.

I didn't include the third code sample. As I mentioned it had some dependencies that I couldn't provide - on code developed in my workplace.

But I hope to put something together to illustrate the points associated with that third, ill-fated, sample. Expect to see something here on the blog. If you're interested and don't see anything, please feel free to nag.

There are a few other resources I'd like to post - references to books and/or articles I mentioned in the talk. Look for that by Tuesday morning.

If you want to pursue this topic further and are running into roadblocks and need a hand, please feel free to call or email me. Or even post a comment on the blog. I'll do what I can to help out.

Thanks again for attending the session. I had a lot of fun.

Professionalism, Programming, and Punditry and Success as a Metric

2008-05-31T07:47:00.000-07:00

Scott Hanselman had a nice post in response to Jeff Atwood's post in response to Alastair Rankine's post "Blogging Horror". I don't feel the need to comment on Coding Horror beyond saying that I occasionally find some real jewels there. Good stuff for free.

But Scott's post struck a nerve. Here's some context.

I've been contemplating presenting at the local code camp for years now, but have never gotten around to actually doing it. I'd always figured that I should pick a topic on which I could speak with some authority. Makes sense I thought, but I was never able to pick one that moved me.

Localization is a nice, well circumscribed topic that I have engaged pretty thoroughly over the years. I have some hard earned experience, useful code and guidance borne of long hours. But I really find it difficult to care enough to put it all together into something that wouldn't risk being a waste of someone's time. So I've never done it.

The list of sessions for the code camp was posted a few weeks ago, and I'd been thinking that it would have been nice to see more and new sessions that addressed issues like SRP and OCP and Dependency Injection and other principles of good design. Maybe you've seen this coming, but I realized could do that session I wanted. Certainly then it would be on something that I actually cared about.

Of course the thing that's kept me from even considering it before is that I'm still learning, and still have a lot to learn. But I figured there's no reason that I can't do it based on my own struggles to make my code better.

I finally decided a week ago that I was actually going to do it. This past week's free time has been spent on reviewing literature, searching for good examples, and trying to make sure I've covered all the bases. I woke up at 4:30AM this morning and finally had the scenario for a good example. It was such a nice scenario that I couldn't get back to sleep.

So after I'd finished documenting my example this morning, it was really nice to see Scott's post about Jeff''s post about Alastair Rankine's post. Here's the best bit:

We're all just learning together. I started blogging so I could Google myself later, that's all. I taught as an adjunct professor so I could know the topics better as there is no better way to learn a thing deeply than to teach it. I worked on a few books so I could really dig deep, but I'm the first guy to say "dude, I have no idea." My brain bit-rots as yours does.

That is a nice bit of encouragement, isn't it?

Counting down four more weeks until the code camp and I don't even know if it is still open for submissions (hope so), but I'm going to do the work regardless of whether I can get in under the deadline. If I do it, you'll read about it here. But if I don't (and probably even if I do) it will all eventually find its way here.

We'll see what I can do . . .

Button Defaults in HTML

2005-11-15T16:45:00.000-08:00

I'm going to forget this, so . . .

Managing the active or default button on web page is tricky, depending on what kind of button you are using. At least in IE.

Submit buttons (input type submit) don't give you any options. When your form gets focus, the first submit button gets the equivalent of a setActive(). You can try to call setActive() on subsequent submit buttons, but it doesn't make any difference.

This is a bummer if you've got a wizard interface, with Cancel, Back and Next all in a row at the bottom of your form. Note that System.Web.UI.WebControls.Button in ASP.NET renders to one of these buttons.

However, buttons rendered with the button tag are more forgiving. They haven't got any default behavior, but at least you can roll your own by monitoring keystrokes in keypress. To get my wizard controls buttons to function the way I want, I've created a System.Web.UI.WebControls.Button work-alike control which renders to a button tag instead of an input tag.

While we're at this, note that setActive() and focus() are two distinct methods, and accomplish different ends. I want my default button to be setActive() when I'm in any of the controls in my form, but the specific control I'm on has the focus.

Ellipsis in Internet Explorer

2005-10-26T10:59:00.000-07:00

I forget this repeatedly - so here it is for future reference.

To get a string of indeterminent length to display inside a fixed width with ellipses indicating that it is longer, apply the following CSS styles:

overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;

You'll also need to apply a width style. If you want your entire string to appear in a tool tip, put it into the title attribute of whatever element it is going into.

2005-05-11T22:31:00.000-07:00

Gavin's Spring concert.

2005-05-06T12:30:00.000-07:00

John witnessing to someone at the Taste of Mililani.