AbstractCode

‘as’ is no safer than cast without a null check

Colin David Scott — Tue, 03 Nov 2009 07:44:17 GMT

I’ve recently encountered code which looks something like:

var someInstance = someParameter as ISomething;
someInstance.DoSomething();

The problem with this code is that it is wide open for a highly unhelpful NullReferenceException. If someParameter cannot be cast to ISomething the as operator will return null. But this code doesn’t check if someInstance is null. It makes the assumption that someParameter may be case to ISomething, even though in practice this assumption may not hold.

There are two solutions to this. You may replace the use of the as operator with an explicit cast. This will throw an InvalidCastException if the cast cannot be performed, which at least is more informative that the NullReferenceException. It’s also going to be somewhat faster but the performance gain will be sufficiently trivial that this is unlikely to be a useful optimisation. It also makes the code more explicit in what it expects which aids readability.

The preferred solution would be to check the result of the as operator for null and handle this case appropriately. In many cases this would be to throw an exception, but this exception may be more informative than a generic InvalidCastException or NullReferenceException. In general you should throw a specific exception that provides meaningful information in the context, rather than a technical exception(what went wrong rather than how). In other cases there may be an appropriate alternate activity to be performed, or the method could simply do nothing in this case. Regardless of the appropriate behaviour it is important that it be considered and the code actually implement this behaviour.

In which I review my old phone

Colin David Scott — Sat, 19 Sep 2009 04:29:00 GMT

My phone has been annoying me for some time, as it’s been slow and buggy. I’ve therefore decided to do a review.

To start with I need some tools:

Safety is of course paramount, so I’ll also need:

Reviewing can be dangerous. Kids, never review something without adult supervision.

Before review:

Here we see that in the event of attack by chisel the phone easily separates into two components, after which it ceases to function.

Further we can see that the device is vulnerable to chisel injection attacks:

Hopefully this will help you which your phone purchasing decisions in high-chisel environments.

Slides from my presentation to the Perth .NET Community of Practice

Colin David Scott — Fri, 04 Sep 2009 10:28:00 GMT

Some people asked for the slides for my Continuous Integration presentation at the Perth .NET Community of Practice yesterday. Enjoy.

Download the Presentation here

This presentation was targetted at developers new to Continuous Integration. The examples use my Abstract2ion project which comes set up for Continuous Integration. If you are trying to set this up with TeamCity the table below has some of the configuration values necessary (TeamCity is pretty easy to use, so I'm not going to write a step by step guide):

Artifact paths:	Abstract2ion\Package\*.zip
Build runner:	MSBuild
Build File Path:	Abstract2ion\Abstract2ion.build
MSBuild Version	Microsoft .NET Framework 3.5
MSBuild ToolsVersion	3.5
Targets	Test;Package
Command Line Parameters	/property:Configuration=Release

Presenting at the Perth .NET Community of Practice

Colin David Scott — Sat, 29 Aug 2009 09:03:14 GMT

I’m doing a presentation on Continuous Integration at the Perth .NET Community of Practice Thursday 3rd September. This is a completely reworked version of a presentation I’ve given to colleagues aimed primarily at .NET developers looking to start using CI.

Details:

Date: Thursday September 3rd, 5:30pm

Venue: Excom, Ground Floor, 23 Barrack St, Perth

Cost: Free

If how many times you scream at the screen in anger is the metric…

Colin David Scott — Sat, 15 Aug 2009 10:49:14 GMT

…then The Howard Years is a much better documentary than Liberal Rule.

A small example of the value of separation of concerns

Colin David Scott — Sat, 15 Aug 2009 07:35:42 GMT

In a recent project I’ve had to implement a feature I think is a good example of a separation of concerns at a small scale.

This feature involves giving the user a choice from a set of items. The available items from which the user may select an option is determined by a couple of factors. First there is a pool from which they may draw items. Users will preferentially get only those items directly associated with themselves if any are available. If no items are associated with the user then they get those associated with their user class. Finally, if there are no items associated with either the user or the user’s class they get a set of unassociated items as their pool.

Once we have the pool we also do filtering on a set of dynamic criteria, such as the current order value. This filtered set them becomes the list of options the end user is presented with.

For various implementation reasons determining the pool items can be expensive but the pool items appropriate to a user change relatively infrequently. They are therefore perfect candidates for caching. The filtering of the pool is based on dynamic criteria that may change frequently and are therefore not amenable to caching.

What this leads to is that we have three separate concerns:

Retrievable of the pool items
Caching of the pool items
Filtering of the pool items

It would be possible to implement all of these concerns within a single service. That would isolate the client of the service from all of these concerns. It would pass the service the current relevant state (such as order value) and receive in response a list of items to display. That the service may use caching to reduce the impact of potentially expensive operations is irrelevant to the client, as are the exact rules used for filtering. The client is therefore simpler than if it new of these concerns.

Although the client may be simpler the service itself is not. It contains three concerns and must deal with all their interactions and implementation concerns. This does not conform to the Single Responsibility Principal.

We can simplify this by making each concern its own distinct service. At the lowest level we have a service that performs only the retrieval of the pool items. This service becomes the only point where we need to consider the current user, as its results will always be restricted to those available to that user.

On top of the retrieval service we can place a caching service. When items are requested from this service it will preferentially return the cached set if they exist. Otherwise it will utilise the retrieval service, saving the results object in the cache as well as returning them it its own caller.

Finally we have a filter service. It gets an item pool from the caching service and applies filtering criteria, returning the results to its own caller. It would therefore have the same signature as the original merged service.

This would seem to have tripled the complexity. Instead of a single service we now have three. However each individual service is significantly simpler than the original implementation. Each has a smaller area of responsibility and interacts with fewer external dependencies. Therefore what we have is lower overall complexity where we trade some increase in complexity between elements for lower complexity inside the elements. As we can use autowiring Dependency Injection containers to do all the hookup for us this is in most cases a significant gain in maintainability.

We additionally get reuse potential that would not otherwise exist. In this case we may be able to genericise the caching service to be applicable in many scenarios where caching is required. This would allow us to apply caching using interception to a variety of actions with only some configuration of the DI container.

Another area where benefits can be found is in future extension. Once these services were implemented a further requirement changed how the pool was generated. A new class of item was introduced that need to be handled separately. The same filtering sequence against user and user class were to be used, but we needed to do this separately for items of the class and items not of the class. The two resulting lists would then be merged.

As the interface of the retrieval service did not change it was possible to constrain the changes purely to this service. This localisation of changes simplified testing significantly.

Customisation at compile time

Colin David Scott — Sat, 15 Aug 2009 06:22:33 GMT

On my current project we’re building multiple websites that share the majority of their logic but each have requirements relevant only to their target audience. This means we need a way to configure the common elements to behave appropriately to each scenario. This post discusses the mechanism I’ve chosen to do this.

In building this mechanism I had a number of goals:

Minimal Duplication It was not acceptable to simply duplicate whatever logic needed to vary. Whatever mechanism I chose has to keep as much logic common as possible to constraint development cost and ensure consistency of operation in the common elements.
Low Coupling Most of the elements involved have no need to know about the specific sites and their requirements. These elements do need to know configuration values for their elements but this does not imply that they need to know how decisions for each site are made. This would tie each element to the current sites and require extensive modification if the feature distribution changes or new sites are added.
Simplicity As this mechanism will be used throughout the system it needs to be simple to adopt so as not to negatively impact the maintainability of the system. Additionally it should not make the system difficult to deploy or run.
Robustness The system should be reliable and not prone to the introduction of errors. In particular it should not increase the risk of errors at deployment.
Testable As a strong proponent of TDD I need a solution that will support testing the elements behaviour in each scenario.
Low Effort I’m looking for a mechanism that doesn’t take significant amounts of time to use, either during development or at deployment.

I also have an advantage in that I can make the decisions at compile time. In this scenario I don’t need the ability to dynamically change these behaviours. This means I don’t actually need to configure things in the sense of having an XML configuration file or similar. Configuration is needed but this may occur at compile time.

I’ve previously discussed making configuration using the standard .NET infrastructure injectable. This does some of what I need, but it still requires XML configuration files which introduce significant complexity and risk to deployments. However I can get where I need to go by keeping the interfaces and changing the implementation.

In my previous usage the code needing configuration has no dependency on the .NET configuration infrastructure. It happens to be provided an implementation that uses it, but this is not necessary. Hence I define interfaces that provide the necessary configuration options. For each site I provide implementations of the interface that supply configuration values relevant to that site. The dependency injection configuration for each site is configured to supply the implementations relevant to that site, and I have a complete solution that meets all my goals.

We start with a configuration interface that may look something like:

internal interface ISiteConfiguration
{
    bool SomeConfigurationValue { get; }
    bool SomeOtherConfigurationValue { get; }
}

We can start with a single interface and potentially break it apart as the number of properties grows.

public class SomeSiteConfiguration : ISiteConfiguration
{
    public bool SomeConfigurationValue
    {
        get { return false; }
    }
    public bool SomeOtherConfigurationValue
    {
        get { return true; }
    }
}

The implementation above provides fixed values for each of these configuration properties. There is nothing here to get wrong an deployment time, I can’t accidentally misconfigure a feature with an inappropriate configuration setting. I’m looking here to provide a different configuration between sites and other sites get supplied a different implementation of ISiteConfiguration. This means that I can have some confidence that the set of configuration values will always be consistent.

It is not mandatory to provide fixed values. The properties may apply logic to determine the configuration value, with the different implementations allowing this logic to be varied between uses (or to support fixed values in some places and calculated in others).

In the site dependency injection configuration I then specify the appropriate implementation for that site. If I’m using a container that supports configuration in code I can have things such that the implementation to use is baked into the site and there is no configuration to go wrong between deployments. For instance with StructureMap I could do something like:

ObjectFactory.Initialize(initialise =>
    {
        initialise.ForRequestedType<ISiteConfiguration>().TheDefaultIsConcreteType<SomeSiteConfiguration>();
    });

So how does this measure up to my critieria:

Minimal Duplication All the instances of a configuration decision are collected into a single location. With some refactoring duplication can essentially be eliminated.
Low Coupling There is an abstraction between the use of the configuration and the making of the configuration decisions.
Simplicity Using the configuration is as simple as injecting the configuration interface which is trivial with most containers. As demonstrated above there is nothing to configure at deployment which is about as simple as you can get.
Robustness The solution ensures configuration decisions are provided, otherwise the system will fail quickly in development. At deployment there is nothing to go wrong as the system is already configured.
Testable The configuration interfaces are easily mocked for testing purposes.
Low Effort This utilises my existing DI setup and involves relatively trivial interfaces and implementations.

I’m therefore pretty happy with this system. It can be seen that it is basically the Strategy pattern as applied to configuration, with the extra goodness that it comes pre-configured at deployment.

I’ve discussed this in the context of multiple websites as that is the current scenario I’m dealing with, but this approach may be applied whenever multiple executables share common logic requiring configuration that may be defined at development. If you introduced some configuration for selecting configuration implementations only you could also adapt this to providing fixed sets of configuration for the same executable in multiple environments. This would maintain the majority of the benefits (consistent configuration sets, elimination of the majority of configuration values) for a relatively low cost in deployment effort and risk.

Lee Campbell talks interfaces and Unity

Colin David Scott — Sat, 15 Aug 2009 05:22:24 GMT

Further to the discussion that Rhys Campbell and myself have been having regarding interfaces, Lee Campbell has stepped in with a discussion of interfaces primarily related to Unity. Well worth a read, and I like to think somewhat of a justification to go download StructureMap.

On the granularity of services

Colin David Scott — Tue, 11 Aug 2009 16:52:30 GMT

When implementing services there are a number of practices I like to adopt. I have already discussed the use of interfaces to define the service contract. This post is to discuss the granularity of the contracts in a system.

In all but the most trivial of systems multiple service actions will be required. In providing these actions we can choose a position on a continuum. At one end we have a single contract that has all the actions as methods. At the other end we have a separate contract for each action. In between we have contracts that provide subsets of the actions. We must therefore make a decision as to where on this continuum we wish our system to be.

The single contract that provides all actions is unwieldy and results in code that is difficult to understand and modify. I’d love to claim that this is a deliberate exaggeration that no one would ever do in practice but 9000+ line counter-examples I’ve encountered would make that a lie. Nevertheless this end of the continuum involves a complete lack of separation of concerns and demonstrates terrible maintainability.

The question therefore is whether the other extreme is similarly bad and that an intermediate position with multiple contracts each containing multiple actions is the reasonable solution. I’ve certainly encountered the argument that having a single action per service interface will result in an unmanageable number of interfaces and classes. This argument holds that complexity of a large number of service interfaces is very high and hence we must consolidate them in order to make the complexity manageable.

This position reminds me of political compromise where there is often a view that the centerist position between two extremes is preferable. I wont comment on the relative merits of this view in politics but I will assert that I do not believe it to be applicable here.

I do not agree that many interfaces and classes is in this case more complex overall. Each class that implements a service interface will be less complex as it is now responsible only for a single action. Although there are more classes it is my contention that this implementation is overall simpler as all the elements of any service class are directly associated with the single action of the relevant contract. As the number of actions on the interface increase the number of concerns in the class not relevant to a selected action will also increase. This makes maintaining the service more difficult as the number of concerns increases the cognitive overhead of reasoning about the implementation.

I also do not agree that fewer service interfaces is inherently simpler. Fine grained service contracts that are properly named can increase readability through additional information carried in the name. A service that requires an IShoppingCartService may be doing anything to the shopping cart. A service that requires an IClearShoppingCartService has a clearly indicated requirement to be able to clear the shopping cart contents. An additional benefit is that it can be determined from the number of dependencies that a service is dependent on too many external actions and that refactoring may be applicable.

It may be suggested that dealing with a large number of services is difficult, error prone or inefficient. Again I do not agree. A decent Dependency Injection framework with automatic registration and wiring will handle the vast majority of the instantiation with some simple conventions (StructureMap, my current DI container of choice, has some very nice options for this). In general avoiding considerations such as circular dependencies can be managed by avoiding circular references between namespaces and between service types within namespaces.

Many service interfaces will mean many more service class instances to be instantiated. It is highly unlikely that this will be an efficiency issue. Stateless instances are cheap to instantiate and unlikely to be a significant resource problem in your application. It is much more likely that resource utilisation in the business logic will be orders of magnitude higher and a much greater concern in considering efficiency and performance.

I therefore find that in the general case it is preferable to have a single action per service interface as this is the least complex and most maintainable option. However there are notable exceptions. In particular this is not (at least currently) my preferred option when dealing with communications using WCF.

When defining a service contract in WCF there are a number of additional concerns that do not apply to general services, such as the configuration of endpoint addresses and communication channel properties, as well as the metadata to be defined on the service contract and implementation. This additional overhead means that there is additional complexity as the number of service contracts increases. As such a single action per contract is generally not the least complex option.

Even in this exception I would not start reducing the granularity of business logic. My WCF services are generally facades that invoke business services rather than contain business logic themselves, and these business services would continue to have a single action per service contract.

It should also be noted that having a single action on the service interface does not imply a single method on the implementing service class. The service class may have whatever methods make sense to effectively implement its function. Only one of these methods will be exposed (via the contract) to other types.

Rhys Campbell has recently discussed, both in response to my post on interfaces and on his own blog, explicitly implementing interfaces so that you will have compile time errors if a method is removed from an interface but is maintained on a class that implements the interface. At least for services I don’t favour this approach as for a service interface with a single method if that method is removed then the interface itself is unnecessary. Hence I don’t feel explicit implementation is actually beneficial here. I can see value for other classes of interface which have multiple methods, but I’m currently unconvinced that the additional complexity of working with explicitly implemented methods is justified by what I see as relatively small benefits (compiler detection of obsolete methods, not removal of code bloat). It will be interesting to see if Rhys has further thoughts on this topic.

Simple organisational improvements: Remember the alphabet

Colin David Scott — Wed, 22 Jul 2009 06:37:52 GMT

Software contains many examples where a number of named items must be listed in a context where the order is not important. This is particularly prevalent in configuration files but is also found in code. One example I’m currently looking at is a set of WCF service host classes that need to be run in a service. The order they start is irrelevant as long as they are all started. As there are a number of types it’d be nice if I didn’t have to scan the list every time I wanted to see if something was included.

This is particularly a problem in large configuration files. Using search is an option but this is not always sufficient and fails for printed material. It is for this reason that I alphabetise these items unless ordering is significant. This simplifies the task of working with the items as it becomes predictable where they are located.

This is useful for configuration files and list items. I’d not recommend it for use in organising methods and other type members. These should be organised by their function, alphabetising would generally decrease the readability of the code.