Design/Coding Guidance

In my previous post, I showed how the Dispose Pattern is effectively obsolete. But, there’s one area that I didn’t really cover.  What do you do when you want to create a class that implements IDisposable, doesn’t implement the Dispose Pattern, and will be derived from classes that will also implement disposal? The Dispose Pattern covered this by coincidence.  Since something that derives from a class that implements the Dispose Pattern simply overrides the Dispose(bool) method, you effectively have a way to chain disposal from the sub to the base. There’s a lot of unrelated chaff that comes along with … Continue reading IDisposable and Class Hierarchies

When .NET first came out, the framework only had abstractions for what seemed like a handful of Windows features.  Developers were required to write their own abstractions around the Windows features that did not have abstractions.  Working with these features required you to work with unmanaged resources in many instances.  Unmanaged resources, as the name suggests, are not managed in any way by the .NET Framework.  If you don’t free those unmanaged resources when you’re done with them, they’ll leak.  Unmanaged resources need attention and they need it differently from managed resources.  Managed resources, by definition, are managed by the … Continue reading The Dispose Pattern as an anti-pattern

There’s a couple of good axioms about software design: You Can’t Future-Proof Solutions and the Ivory Tower Architect You Can’t Future-Proof Solutions basically details the fact that you can’t predict the future.  You can’t possibly come up with a solution that is “future-proof” without being able to know exactly what will happen in the future.  If you could do that, you shouldn’t be writing software, you should be playing the stock market. Ivory Tower Architect is a software development archetype whose attributes are that they are disconnected from the people and users their architecture is supposed to serve.  They don’t … Continue reading Leave predicting to meteorologists and fortune-tellers

Now that we’ve seen how a singular x86-x64 focus might affect how we can synchronize atomic invariants, let’s look at non-atomic invariants. While an atomic invariant really doesn’t need much in the way of guarding, non-atomic invariants often do.  The rules by which the invariant is correct are often much more complex.  Ensuring an atomic invariant like int, for example is pretty easy: you can’t set it to an invalid value, you just need to make sure the value is visible.  Non-atomic invariants involve data that can’t natively be modified atomically.  The typical case is more than one variable, but … Continue reading Thread synchronization of non-atomic invariants in .NET 4.5

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

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

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

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

Some things to keep in mind when writing units tests for code that use async methods: You’re not trying to test the framework’s “awaitability” and you’re not trying to test framework methods that are “awaitable”.  You want to test your code in certain isolation contexts.  One context, of course, is independent of asynchronicity–do individual units of code that don’t depend on asynchronous invocation “work”…  e.g. “Task<string> MyMethodAsync()”, you want to have a unit test that make sure this method does what it’s supposed to do (one being it returns a “valid” Task<string> object, the other being that individual side-effects occur, … Continue reading Testing Strategies Involving Async Functions

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