Posts
74
Comments
75
Trackbacks
0
June 2008 Entries
Hint for today - Install SQL Server 2008

improve my => 'code' Add to Google

Even if your databases are from prior versions of SQL Server, you should download the new CTP for SQL Server 2008.

https://connect.microsoft.com/SQLServer/content/content.aspx?ContentID=5395

The new version's Management Studio will connect to older versions of SQL Server databases and give you intellisense (almost as good as Red Gate's Sql Prompt!).

Hope this saves you some time,

Jonathan

posted @ Wednesday, June 25, 2008 12:07 PM | Feedback (0)
Code Redundancy is NOT Bad - Part 2

improve my => 'code' Add to Google

I got some responses from a post I made on Saturday, that troubled me.  I really think it is important to code to an interface whenever possible - not only to give your application to flexibilty, but to give it testability as well.  So I thought I might give you an example.

Say I have a class that depends on two other classes I have.  In this example, Partitioner depends on SystemIOAdapter and MerchantRecordCounter.                                                                                                                                                                

                                                                                                                                                                                                                    

using Interfaces;

namespace Program

{

    public class Partitioner : IPartitioner

    {

        public void PartitionMerchants(ISystemIOAdapter io, IMerchantRecordCounter counter, string mappedPath, string partitionPath, int maximumCount)

        {

           // implementation details.

        }

    }

}

If the method PartitionMerchants had been written using class declarations instead of interfaces, than any test I would write for this method would be an integration test, not a unit test...  Because the failure could be in one of the dependent classes, not in the class that is under test in my unit test! 

Integration tests are useful as smoke tests to identify that a problem exists.  But they don't help me quickly identify the root cause of problems when they arise.

The following shows a unit test for a Partitioner class that depends on a SystemIOAdapter (so dependencies on a specific IO is removed),  and a MerchantrecordCounter class.  You may notice that the only way to mock these out are by creating classes that implement the same interfaces used in the PartitionMerchants method.  (In this case I am using Rhono Mocks to do this quickly).

using Project.Interfaces;

using NUnit.Framework;

using Rhino.Mocks;

namespace Tests

{

    [TestFixture]

    public class Partitioner_UT

    {

        private MockRepository mocks;

        private string mappedpath = "mappedpath";

        private string partitionedpath = "partitionedPath";

        private ISystemIOAdapter io;

        [SetUp]

        public void SetUp()

        {

            mocks = new MockRepository();

            io = mocks.CreateMock<ISystemIOAdapter>();

        }

         [Test]

        public void PartitionDirectory_OnlyOneMerchantFound()

        {

            IMerchantRecordCounter counter = mocks.CreateMock<IMerchantRecordCounter>();

            using (mocks.Record())

            {

                // set up call expectations here

            }

            using (mocks.Playback())

            {

                IPartitioner partitioner = new Partitioner();

                partitioner.PartitionMerchants(io, counter, mappedpath, partitionedpath, 0);

                // Add assertions here

            }

        }

    }

}

I hope this clears up why it is so important to write code using interfaces whenever possible!

Jonathan Starr

posted @ Monday, June 23, 2008 6:26 PM | Feedback (2)
Code Redundancy Is NOT Necessarily Bad

improve my => 'code' Add to Google

I was just reading Jeff Atwood's recent blog article Department of Declaration Redundancy Department

He makes the case that writing code without static typing is easier to read, and "Anything that removes redundancy from our code should be aggressively pursued -- up to and including switching languages."

My take is "maybe".

Say I have a class named Example that implements two interfaces, IFoo and IBar.  When I instantiate I have several options when dong so statically.

Example example1 = new Example();
IFoo example2 = new Example();
IBar example3 = new Example();

In the second case I am ensuring that example2 implements a certain interface, and I can swap this out with an instantiation of a different object that implements IFoo.  This strategy pattern is fundamental to object oriented programming, and 'getting in the habit of writing code using var' can provide inflexible suboptimal design.  Additionally, if you are coding using (Test Driven Development) you won't be able to write unit tests that remove all dependencies for your class unless you write your dependencies as interfaces.

The way the compiler in C# 3.5 automatically converts LINQ queries to IEnumerable objects is nice.  But the following statement

var reader = new StreamReader(fileName);

is cast to the child static type, not to the its abstract parent (as I think it should be).

Interested in your thoughts.


Jonathan
posted @ Saturday, June 21, 2008 5:43 PM | Feedback (10)
News
Jonathan Starr is a developer in Saint Louis, MO. He holds an MBA in Finance from Columbia Business School and earned his MCSD from Microsoft.


All statements in this blog are personal opinions and do not reflect the opinions of his employer.





Related Sites
Join My Community at MyBloglog!

Tag Cloud