James Michael Hare

...hare-brained ideas from the realm of software development...
posts - 166 , comments - 1431 , trackbacks - 0

My Links


Welcome to my blog! I'm a Sr. Software Development Engineer in the Seattle area, who has been performing C++/C#/Java development for over 20 years, but have definitely learned that there is always more to learn!

All thoughts and opinions expressed in my blog and my comments are my own and do not represent the thoughts of my employer.

Blogs I Read

Follow BlkRabbitCoder on Twitter

Tag Cloud

Article Categories


Post Categories

Image Galleries



Little Wonders

Little Wonders


May 2010 Entries

Code Reuse is (Damn) Hard
Being a development team lead, the task of interviewing new candidates was part of my job. Like any typical interview, we started with some easy questions to get them warmed up and help calm their nerves before hitting the hard stuff. One of those easier questions was almost always: “Name some benefits of object-oriented development.” Nearly every time, the candidate would chime in with a plethora of canned answers which typically included: “it helps ease code reuse.” Of course, this is a gross oversimplification. ......

Posted On Thursday, May 27, 2010 8:48 PM | Comments (11) | Filed Under [ My Blog Software ]

C#: System.Lazy<T> and the Singleton Design Pattern
So we've all coded a Singleton at one time or another. It's a really simple pattern and can be a slightly more elegant alternative to global variables. Make no mistake, Singletons can be abused and are often over-used -- but occasionally you find a Singleton is the most elegant solution. For those of you not familiar with a Singleton, the basic Design Pattern is that a Singleton class is one where there is only ever one instance of the class created. This means that constructors must be private to ......

Posted On Wednesday, May 19, 2010 6:41 PM | Comments (34) | Filed Under [ My Blog C# Software .NET Fundamentals ]

C#: Handling Notifications: inheritance, events, or delegates?
Often times as developers we have to design a class where we get notification when certain things happen. In older object-oriented code this would often be implemented by overriding methods -- with events, delegates, and interfaces, however, we have far more elegant options. So, when should you use each of these methods and what are their strengths and weaknesses? Now, for the purposes of this article when I say notification, I'm just talking about ways for a class to let a user know that something ......

Posted On Tuesday, May 18, 2010 6:10 PM | Comments (5) | Filed Under [ My Blog C# ]

C# Fundamentals: String Concat() vs. Format() vs. StringBuilder
I was looking through my groups’ C# coding standards the other day and there were a couple of legacy items in there that caught my eye. They had been passed down from committee to committee so many times that no one even thought to second guess and try them for a long time. It’s yet another example of how micro-optimizations can often get the best of us and cause us to write code that is not as maintainable as it could be for the sake of squeezing an extra ounce of performance out of our software. ......

Posted On Monday, May 10, 2010 9:59 PM | Comments (6) | Filed Under [ My Blog C# Software .NET Fundamentals ]

C#: Why Decorate When You Can Intercept
We've all heard of the old Decorator Design Pattern (here) or used it at one time or another either directly or indirectly. A decorator is a class that wraps a given abstract class or interface and presents the same (or a superset) public interface but "decorated" with additional functionality. As a really simplistic example, consider the System.IO.BufferedStream, it itself is a descendent of System.IO.Stream and wraps the given stream with buffering logic while still presenting System.IO.Stream's ......

Posted On Thursday, May 6, 2010 7:01 PM | Comments (10) | Filed Under [ My Blog C# ]

C#: Does an IDisposable in a Halted Iterator Dispose?
If that sounds confusing, let me give you an example. Let's say you expose a method to read a database of products, and instead of returning a List<Product> you return an IEnumerable<Product> in iterator form (yield return). This accomplishes several good things: The IDataReader is not passed out of the Data Access Layer which prevents abstraction leak and resource leak potentials. You don't need to construct a full List<Product> in memory (which could be very big) if you just want ......

Posted On Tuesday, May 4, 2010 7:52 PM | Comments (2) | Filed Under [ My Blog C# ]

Powered by: