Inheritance is Truly Evil

Tuesday, October 25, 2011

Lately I’ve been refactoring some really old code, and it helped me realize that in about 90% of the cases, inheritance from a class (unlike interface implementation) is a Bad Thing. Of course, I’m hardly the first to think that, but it’s not until I had to refactor deep, and absolutely wrong, object graphs until I felt it in my bones. But why? Isn’t inheritance a legitimate way to reuse code? Well, no, for several reasons: It makes the code harder to understand. To understand the flow of your class, you...
no comments

Why Too Many Overloads Can Be a Bad Thing

Tuesday, April 1, 2008

At work we're using code generation to create our data access layer. So for the users table we have a UsersDalBase with many overloads of methods such as Add(User) and Add(IList<User>). Thing is, many time we need to override the default behavior of a method. For instance we might want to change Add(User) to notify the user by mail, write something to a log, use caching, etc. We do that in a UsersDal class that inherits from UsersDalBase. But hmm, that other overload that accepts a list of users is still there. No one uses it for now, but...

Don’t Seal That Door

Friday, January 11, 2008

I've been going over this week's updates, and ran across this post in CodeBetter, that talks about why classes should be sealed by default, only to be unsealed by the 'unsealed' keyword. I couldn't disagree more. I think that you need a hell of a good reason to seal a class, so claiming that most classes should be sealed is a bit seems outrageous to me. I believe it's absurd to prevent extensibility for your classes, and if classes are sealed by default, the result will be, obviously, a lot more sealed classes around. After all, unless you plan...
tags: ,

Upgrading to .NET 2.0? PowerCollections to your Aid.

Saturday, September 1, 2007

The .NET 2.0 framework has been here a while, but if you're like my team, you're still using a lot of code that you wrote back at the .NET 1.1 days. It's likely that many of these methods are using non-generic collections. This poses an annoying issue. Check out this method: public IList GetAllUsers(IList userCodes) { IList list = new ArrayList(); //Add the users here... //... return list; ...
no comments

Anonymous Delegates or DisposableActions?

Friday, May 11, 2007

One of the most useful features of .NET 2.0 is anonymous delegates. They allow you to create "wrappers" for code which run before and after the code, handle exceptions in it, and decide whether to run it or not. Consider the following method: public static void WrapCall(Callback callback) { try { callback(); ...
tags: ,
no comments

If we didn’t have loops

Tuesday, February 27, 2007

I've stumbled upon this article which explains how to implement delegates in Java. The issue of implementing things we have taken for granted  reminded me of a course I took a few years ago, in a language called Scheme, which is a variant of Lisp. Scheme is a functional language, and has a very recursive nature. It has no loops. As exercises at this course, we had to implement things such as While and For loops and add them to the Scheme interpreter. This made me think of how I would implement loops if didn't have them at C#. I...
tags: ,
no comments

Using AOP and PostSharp to Enhance Your Code: Part B

Friday, February 2, 2007

At the last part we talked a little about post compiling, AOP and how we can use the PostSharp tool to make our code look a lot better. At this part I want to get a little more deep inside the mechanism behind this cool feature, and I'll do this by first showing another example. The Logging Attribute Let's say you want to create an attribute that enables you to log a method, including when you entered the method, the arguments it received and it's processing time. Sounds useful, no? Let's see how easy it is to do...

Using AOP and PostSharp to Enhance Your Code: Part A

Monday, January 29, 2007

Click here for Part B I've been looking at ways to improve the quality of my team's code by removing "unrelated" code from within methods. By that I mean things like opening transactions, caching and exception handling. For instance, code like that might be quite common: public object GetSomething() { try { ...