The Rat-hole of Object-oriented Mapping

Mark Seemann recently had a great post that, as most of his posts seem to do, challenges the average reader to re-think their reality a bit.  The post is titled “Is Layering Worth the Mapping”.  In the post Mark essentially details some of the grief and friction that developers face when they need to decouple two or more concepts by way of an abstraction. Mark takes the example of layering.  Layering is a one way coupling between two “layers” where the “higher-level” layer takes a dependency on abstractions in a “lower-level” layer.  Part of his example is a UI layer … Continue reading The Rat-hole of Object-oriented Mapping

Avoid the volatile Modifier

[Update: 25-Jan-12 5:45 pm; fixed typo] I was reminded recently of the misconceptions of the volatile modifier in C#, and I’d thought I’d pass along the recommendations of other’s that is tantamount to “avoid the volatile modifier”.  The volatile modifier in C# “indicates that a field might be modified by multiple threads that are executing at the same time” [1]. The first problem is that documentation.  What does that really mean to someone developing code that uses multiple threads?  Does that make the code “thread-safe”?  The answer is “maybe”; the real answer is “rarely”. Most people just stick volatile on … Continue reading Avoid the volatile Modifier

If You’re Using “#if DEBUG”, You’re Doing it Wrong

I was going through some legacy code the other day, refactoring it all over the place and I ran into many blocks of code wrapped in “#if DEBUG”.  Of course, after a bit of refactoring in a RELEASE configuration these blocks of code were quickly out of date (and by out of date, I mean no longer compiling).  A huge PITA. For example, take the following code: public class MyCommand { public DateTime DateAndTimeOfTransaction; } public class Test { //… public void ProcessCommand(MyCommand myCommand) { #if DEBUG if (myCommand.DateAndTimeOfTransaction > DateTime.Now) throw new InvalidOperationException("DateTime expected to be in the past"); #endif // do more stuff with … Continue reading If You’re Using “#if DEBUG”, You’re Doing it Wrong

Criteria for Success

I was having a  conversation with a client recently and the topic of “11th hour” came up.  He seemed to think it wasn’t possible to deliver a software project without some sort of “11th hour” panic.  I disagreed I disagree because I’ve done it on small and large projects.  Don’t get me wrong; it’s very easy to lose sight of things and easily get a project into a state where “11th hour” panic is inevitable.  But, it’s not something that can’t be avoided. One of the problems with software projects, it seems, (and with other projects, I suppose) is losing … Continue reading Criteria for Success

Mapping to Your Database is a Private Affair

Your mapping to your database is generally coupled to the design of the data and the mapping provider’s ability to implement a relational or non-relational model.  This means your ORM influences the design of your mapped classes and/or the design of system that uses these mapped classes.  i.e. your design can be limited in certain aspects by how the mapper is implemented. Because of these idiosyncrasies, your choice of ORM becomes an implementation detail; so, you want to keep any of its details and generated classes out of your interfaces.  You want to keep your ORM’s classes and the classes … Continue reading Mapping to Your Database is a Private Affair

Developing Windows Services in Visual Studio

Inevitably distributed systems often need a Windows service or two for certain tasks.  The creation of a Windows service project and hooking up a project installer to the service is fairly straightforward; so, I’m not going to get into much detail about that stuff. The stuff that I find that isn’t well understood is how to debug and deploy these services in a development environment. First off, debugging.  A service is just an executable that is started up by the Windows service manager.  From a native application standpoint, it has some entry points in it that the service manager looks … Continue reading Developing Windows Services in Visual Studio

The Custom Configuration Section Code Smell

I was recently involved in a project that involved some design-time configuration.  That design-time configuration was based on custom config sections. I didn’t really pay too much attention to it at the time because I don’t write my own custom config sections.  As I worked on the project and do what I usually do by refactoring and evolving the system to use various patterns and principles, I came to realize why I don’t use my own custom config sections. That realization came as I began refactoring code for dependency inversion.  As I progressed getting the majority object creation code to … Continue reading The Custom Configuration Section Code Smell

Deep Dive on Closure Pitfalls

I’ve blogged about closures in C# and their pitfalls before.  I keep seeing problems with closures–more now that lambdas expressions and statements (“lambdas”) are becoming more widespread–even with experienced developers. So, I’d thought i’d post about some of the details surrounding where the C# compiler generates closures in the hopes that people will recognize more where they write code that creates a closure and its context. The C# language spec does not refer specifically to “closures”, with regard to capturing state for anonymous methods (including lambdas)–it refers to “outer variables” and “captured outer variables”.  The captured outer variables for a specific … Continue reading Deep Dive on Closure Pitfalls

The Difference between an Anti-Pattern and a Code Smell

I think the term “Anti-Pattern” is being over used.  There’s various definitions for Anti-Pattern like “obvious but wrong, solutions to recurring problems” and “common approaches to solving recurring problems that prove to be ineffective”.  All definitions have a common thread: they’re recognizable solutions (pattern) that don’t work in at least one way and should never be used. This means that anything that does work, when used correctly, isn’t an Anti-Pattern.  Transitively, that doesn’t make incorrectly used Patterns Anti-Patterns. Code Smells, on the other hand, are defined as “…a hint that something might be wrong, not a certainty.”. I’ve seen the … Continue reading The Difference between an Anti-Pattern and a Code Smell

Evolving code over time

Given economics, time constraints, resource limitations, etc.; you can’t write all the functionality for a given solution for a single release.  Even if you weren’t limited by these constraints, you’re likely to get changing requirements as development progresses and everyone learns more about the software under development. It’s fairly easy to prioritize what is developed and what isn’t.  You simply develop only what you need (see YAGNI).  But, how do you manage adding new functionality without causing undue grief?  One way is to only make additive changes to the code.  For example, let’s say we have the method create CreateRequestPacket … Continue reading Evolving code over time