Code Redundancy Is NOT Necessarily Bad

Geeks With Blogs

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.

Join My Community at MyBloglog!

Jonathan Starr's Blog Thoughts on C#, Ajax, WCF, LINQ, Agile et al.

<< Hillary as Darth | Home | Code Redundancy is NOT Bad - Part 2 >>

Code Redundancy Is NOT Necessarily Bad

Comments (11) | Share

improve my => 'code'

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 TDD (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 on Saturday, June 21, 2008 5:43 PM C# , Software Design , Software Development , Agile Development | Back to top

Comments on this post: Code Redundancy Is NOT Necessarily Bad

# re: Code Redundancy Is NOT Necessarily Bad

Nitin,

I had not considered the possibility that the code may become less readable by making the declaration for a variable to its abstract parent or to its relevant interface. This may be the case, but I think these junior developers will, in this way, be taught bad coding habits.

Coding to an interface instead of a concrete really is a better coding practice - not only to give you more flexibility in your application but more importantly it lets you mock out the dependencies in your class when it comes to writing unit tests. If this is not done, your tests will be integration tests, and will not isolate which classes need to be reworked when tests fail.

Jonathan Starr

Left by Jonathan Starr on Jun 22, 2008 1:15 AM

# re: Code Redundancy Is NOT Necessarily Bad

I'm not quite following your logic re: "Additionally...you won't be able to write unit tests".
And yes, very small text box indeed :P

Left by Mark Hildreth on Jun 22, 2008 3:02 AM

# re: Code Redundancy Is NOT Necessarily Bad

What you would be writing is:
var example2 = new Example() as IFoo;

That is assuming you use new() and do not use a factory, builder or IoC container as you probably should be doing ...

Left by Casey on Jun 24, 2008 11:42 AM

# re: Code Redundancy Is NOT Necessarily Bad

@Nitin - I would offer a contrary opinion. A variable is probably declared only once but may be used tens of times. The name and type you associate with it indicates the role it is playing. If in a particular context it is playing only a smaller role as represented by the interface - it makes sense to declare it as that interface rather than as a concrete class. (Of course you should declare it as a concrete class - if you want it to play a role of the concrete class).

Junior programmers will this way learn to focus on the roles the concrete classes play and not just the fact that they have to deal with concrete classes. Junior developers will learn some *good* coding habits.

Left by Dhananjay Nene on Jun 25, 2008 1:50 PM

# re: Code Redundancy Is NOT Necessarily Bad

I can see the point in your first example, where I am instantiating a variable of the type I declare it to be (as opposed to an abstract type or interface) -- that would be a good candidate for the var keyword. But anything else that would benefit from programming to an interface as opposed to an implementation should still be strongly typed.

Left by ncloud on Jun 25, 2008 4:50 PM

# re: Code Redundancy Is NOT Necessarily Bad

Please, for the love of all that is good, stop putting an I in the name of your interfaces!! It does not matter if your parent class is an interface or an abstract class.. do you put A in front of your abstract classes? I know, just because the Microsoft does it...

Left by eric on Jun 25, 2008 5:00 PM

# re: Code Redundancy Is NOT Necessarily Bad

good call eric

Left by zynasis on Jun 25, 2008 5:34 PM

# re: Code Redundancy Is NOT Necessarily Bad

eric... do you think we designate something is an interface by a suffix? i would like it to be similar to the class that implements it if only one class implements other than say a mock class.

Left by Jonathan Starr on Jun 25, 2008 5:57 PM

# re: Code Redundancy Is NOT Necessarily Bad

I fail to see redundancy in this statement:
IFoo example2 = new Example();

However, there is redundancy in the first example which is eliminated by the keyword. Using 'var' with 'new' or anonymous classes is perfectly fine and doesn't hurt readability a bit.

Left by Alexey Bobyakov on Jun 26, 2008 6:08 AM

# re: Code Redundancy Is NOT Necessarily Bad

Hopefully you'll be doing:
var f = IocContainer.Resolve<IFoo>();

I can't see a reason to implement something like IFoo and IBar, which sound like they have different responsibilities, but implement them together. It feels like that would break SRP.

@eric That is a really hard habit to break, but I do agree that once you start coding to the interfaces, they become the names you use everywhere so why not use Foo instead of IFoo and then FooImp instead of Foo.

Left by Mark on Oct 08, 2008 11:14 AM

# re: Code Redundancy Is NOT Necessarily Bad

The scope of a StreamReader is usually limited to a method. As soon as you use it as a parameter to another method, that parameter should be of the interface type.

This is the case for most variables declared within a method.

public void main()
{
var xses = new List<X>;
xses.add(CreateX("foo"));
xses.add(CreateX("bar"));
DoSomething(xses)
}

public void DoSomething(IEnumerable<X> xses)
{
foreach (var x in xses)
{
DoSomething(x);
}
}

Left by Bart Kemps on Aug 07, 2011 5:00 PM

Your comment:

Title:

Name:

Email: (never displayed) (will show your gravatar)

Comment: Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code

Verification:

ASP.Net SQL Server Apple Google SharePoint Windows Visual Studio Team Foundation Server Agile Office Design Patterns Web Azure