Code Redundancy Is NOT Necessarily Bad

Posts: 74
Comments: 71
Trackbacks: 0

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

Code Redundancy Is NOT Necessarily Bad: 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 Print

Comments

# re: Code Redundancy Is NOT Necessarily Bad: Jonathan Starr; 6/22/2008 1:15 AM; 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

# re: Code Redundancy Is NOT Necessarily Bad: Mark Hildreth; 6/22/2008 3:02 AM; 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

# re: Code Redundancy Is NOT Necessarily Bad: Casey; 6/24/2008 11:42 AM; 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 ...

# re: Code Redundancy Is NOT Necessarily Bad: Dhananjay Nene; 6/25/2008 1:50 PM; @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.

# re: Code Redundancy Is NOT Necessarily Bad: ncloud; 6/25/2008 4:50 PM; 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.

# re: Code Redundancy Is NOT Necessarily Bad: eric; 6/25/2008 5:00 PM; 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...

# re: Code Redundancy Is NOT Necessarily Bad: zynasis; 6/25/2008 5:34 PM; good call eric

# re: Code Redundancy Is NOT Necessarily Bad: Jonathan Starr; 6/25/2008 5:57 PM; 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.

# re: Code Redundancy Is NOT Necessarily Bad: Alexey Bobyakov; 6/26/2008 6:08 AM; 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.

Post Comment

Title *
Name *
Email
Url
Comment *: Remember Me?

Please add 1 and 4 and type the answer here:

Enter the code shown above:

Archives

Post Categories

Image Galleries

Fishing Trip

About the Author

Blogs

GeeksWithBlogs

Geometry

Music

Programming

Storage

Skydrive

Videos

Trunk Monkey

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

Jonathan Starr's Blog

Post Comment

Tag Cloud