Development Central

It’s taken me a long time, but I finally finished Scott Bain’s book Emergent Design: The Evolutionary Nature of Professional Software Development.

As the title suggests, the book is evolutionary, not revolutionary. I’m still looking for someone to bridge the gap between the Agilists and the Architects, to point out where long-term design has a place. Developers experienced in both OO and Agile design may find much of the material familiar. It’s a valuable book, though, building on principles popularized by “Uncle” Bob Martin and others. Mr. Bain covers a lot of ground, and many readers will be exposed to new ideas (always a good thing).

Most of the examples are in Java, although a few are in C#. They are generally simple and to the point. A passing familiarity with UML will aid comprehension, but is not a requirement. The text is well-written; Mr. Bain has an informal style that keeps the material from being dry. He also provides amusing real-world analogies.

I found the patterns overview (Appendix B) extremely valuable. It’s 84 pages long; I read a pattern a day in the morning until I finished it.

One downside is the number of typos in the book. The UML diagrams seemed particularly susceptible.

If you’re not deeply familiar with all of the following, read this book:

• Agile development
• Cohesion
• Coupling
• Refactoring
• Unit Testing and Test-Driven Development
• Separation of Concerns
• Dependency Inversion
• Design Patterns

Bob Martin’s Clean Code would make a nice prerequisite.

See also: Practices vs. Simplicity

I’ve been (slowly) reading Scott Bain’s book Emergent Design. I’m roughly halfway through it, and I agree with most of his views and recommendations.

I cannot agree with the practice of encapsulating the constructor, though.

Bain recommends making constructors private and adding static factory methods to classes when they will be used by client classes. This avoids the new keyword outside of the class, with the goal of reducing coupling and making the system more open-closed.

I completely agree with the goals of this practice, and generally agree with Bain’s underlying principle (separating use from construction). I disagree with making this a standard practice.

To be fair, Bain states that this is an “at least do this” practice, and that separate factories and other techniques may be used instead where appropriate. I still believe it is not appropriate for general use.

Being a fan of XP, I favor doing the simplest thing that could possibly work. Bain suggests that factory methods support adding subclasses at a later time. I would not add the factory until that time comes. This practice provides benefit only if the class with the encapsulated constructor becomes polymorphic. If we favor composition over inheritance, that’s not as common as it once was.

He talks about issues extrinsic to the client for determining which subclass to instantiate. He actually implies (p. 160) that coupling the factory method to a GUI might be acceptable! Don’t do it. The moment you do, your class with the encapsulated constructor becomes effectively untestable.

What’s more, I believe that extrinsic issues like configuration settings will tempt developers to use Singletons (read: global state) as “determiners.” Again, this makes for classes that are difficult to test.

So what would I recommend instead? Dependency Injection works well for me. This can be done simply through manual constructor injection. If the system is sufficiently complex, I introduce an IoC (Inversion of Control) container. This decouples my classes, makes them easy to test, and provides great flexibility.

An IoC container is not needed on every project. Neither are factory methods.

Update - May 3, 2009

I sent Mr. Bain a link to the post, and he was kind enough to respond in the comments. Please read his well-stated position. Again, we both have the same goals.

Update - June 21, 2009

See also: Mini-review: Emergent Design

First, I found Keith Hill’s Free PowerShell EBook that I’d previously mentioned quite valuable. Recommended.

Here’s another reference you’ll want: Bruce Payette’s Windows PowerShell Refcard.

And a few more links:

• PowerShell Code Repository
• Windows PowerShell Tips on TechNet
• SQL Server 2008 support for PowerShell

Creating Cmdlets

This is a relatively advanced topic, and is not required to use PowerShell. However, it’s something I’m interested in. I’d like to try creating DSLs (Domain-Specific Languages) in PowerShell.

Allegedly, the Windows PowerShell SDK is required. The installation instructions are unnecessarily complex. Why can’t Microsoft give us a “download just the PowerShell SDK and nothing else” link? Why do I have to install the Windows Server 2008 SDK?

Once you’ve installed the relevant portions (read the download instructions carefully), you’ll then need to locate the relevant DLL to reference. If you read way down on this article on the Windows PowerShell Blog, you’ll learn that “Reference assemnblies are installed as part of SDK installation under ‘Program Files\Reference Assemblies\Microsoft’". On my system, this is:

  C:\Program Files\Reference Assemblies\Microsoft\
    WindowsPowerShell\v1.0

and the assembly that your project must reference is:

  System.Management.Automation.dll

Oddly, the folder timestamp showed that it was created on my PC long before I installed the SDK. I checked another PC that just had PowerShell and Visual Studio installed and found this assembly at the above location. In other words, I do not believe that you need to install the SDK.

To create a cmdlet in C# or VB.NET:

1. In Visual Studio, create a Class Library project
2. Add a reference to System.Management.Automation.dll (see above)
3. Add a reference to System.Configuration.Install (from the .NET tab)
4. See the sample code on MSDN
5. Build the project

To install the new cmdlet in PowerShell:

1. As per How to Register Cmdlets, register the snap-in with installutil. Note that the following command line is correct even for .NET 3.5:
   C:\Windows\Microsoft.NET\Framework\v2.0.50727\installutil MyCmdlet.dll
2. Verify in PowerShell that it’s registered:
   Get-PSSnapin -Registered
3. Add it to PowerShell:
   Add-PSSnapin [Name]
4. Optionally export it to make it permanent

When testing, you can use the /u switch with installutil to uninstall a snap-in.

Just a thought, but wouldn’t it have been simpler to have a PlugIn folder where you could drop DLLs that PowerShell would recognize and load on startup? The current process smacks of COM to me.

You can also write your own provider. Get-PSProvider lists the current providers, which allow PowerShell to treat various hierarchies like file systems on drives.

ReSharper version 4.5 added significant functionality to the Solution-wide Analysis feature. I have found this to be a valuable tool. However, it’s wise to be extremely cautious about removing public members that ReSharper says are never used.

I would not expect ReSharper to know about projects that are not part of the current solution. If you’re creating a shared library, you’re likely to see a lot of “unused” public members.

What was less obvious to me is that data binding is not detected by ReSharper in this context. For example, say I have a public string property named FullName on a class. ReSharper displays a hint that “Property ‘FullName’ is never used". ReSharper’s Find Usages likewise finds no references. The property may still be data-bound to a control, though, since data binding generally references the property name as a string. Removing the property would cause a runtime failure.

ReSharper’s Find Usages Advanced can be used to find the binding, if Textual occurences is checked.

“Class ‘Foo’ is never instantiated” hints may also be incorrect. IoC containers (such as Unity) or other Reflection-based techniques can fool ReSharper.

Please note that I’m not suggesting turning off Solution-wide Analysis (and if you’re not using ReSharper, you’re working harder, not smarter!). Just be aware of its limitations.

Moq version 3.1 is out; I updated our tests from version 2.x this afternoon. The only breaking changes I encountered were that the Expect() and ExpectGet() methods were deprecated in favor of Setup() and SetupGet(), respectively. (Not technically breaking, but I had warnings-as-errors turned on.) A few quick search-and-replaces fixed this, and all the unit tests passed.

If you’re not familiar with Moq, it’s a library for creating mock objects (or stubs, or fakes - mocks in the broad sense) to assist with unit testing. Personally, I find it significantly easier and more intuitive than Rhino Mocks. Your mileage may vary, but Moq generally works the way I expect it to.