IDisposable and Class Hierarchies

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

The Dispose Pattern as an anti-pattern

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

Leave predicting to meteorologists and fortune-tellers

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

Thread synchronization of non-atomic invariants in .NET 4.5

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

Thread synchronization of atomic invariants in .NET 4.5 clarifications

In Thread synchronization of atomic invariants in .NET 4.5 I’m presenting my observations of what the compiler does in very narrow context of only on Intel x86 and Intel x64 with a particular version of .NET.  You can install SDKs that give you access to compilers to other processors.  For example, if you write something for Windows Phone or Windows Store, you’ll get compilers for other processors (e.g. ARM) with memory models looser than x86 and x64.  That post was only observations in the context of x86 and x64.  I believe more knowledge is always better; but you have to … Continue reading Thread synchronization of atomic invariants in .NET 4.5 clarifications

Thread synchronization of atomic invariants in .NET 4.5

I’ve written before about multi-threaded programming in .NET (C#).  Spinning up threads and executing code on another thread isn’t really the hard part.  The hard part is synchronization of data between threads. Most of what I’ve written about is from a processor agnostic point of view.  It’s written from the historical point of view: that .NET supports many processors with varying memory models.  The stance has generally been that you’re programming for the .NET memory model and not a particular processor memory model. But, that’s no longer entirely true.  In 2010 Microsoft basically dropped support for Itanium in both Windows … Continue reading Thread synchronization of atomic invariants in .NET 4.5

Visual Studio 2010 Best Practices published

Most of my spare time in the last few months has been taken up by writing Visual Studio 2010 Best Practices.  This has now been published and is available through publisher (no longer pre-order) at http://bit.ly/Px43Pw.  The pre-order price is still available for a limited time.  Amazon still has it out of stock; but $39.99 at http://amzn.to/QDDmF7. The title of the book really doesn’t do the content justice.  Least of which is “Best Practices”.  Anyone who knows me should know I don’t really like that term.  But, hopefully those looking for best practices will read the book and learn from chapter … Continue reading Visual Studio 2010 Best Practices published

Automated Testing Isn’t Just for Business Logic

I had a conversation with Kelly Sommers the other day that was partially a short support group session on the annoying tendencies of development teams to completely lose focus on the architecture and design principles of a system and let the code base devolve into a ball of muddy spaghetti. One particular area that we discussed, and it’s one area I’ve detailed elsewhere, has to do with layers.  Our gripe was that developers seem to completely ignore layering principles once they start coding and introduce cycles, put things in the wrong layer, etc.  A brief recap of layering principles:  Types … Continue reading Automated Testing Isn’t Just for Business Logic

“Virtual method call from constructor” What Could Go Wrong?

If you’ve used any sort of static analysis on source code you may have seen a message like “Virtual method call from constructor”.  In FxCop/Visual-Studio-Code-Analysis it’s CA2214 “Do not call overridable methods in constructors”.  It’s “syntactically correct”; some devs have said “what could go wrong with that”.  I’ve seen this problem in so many places, I’m compelled to write this post. I won’t get into one of my many pet peeves about ignoring messages like that and not educating yourself about ticking time bombs and continuing in ignorant bliss; but, I will try to make it more clear and hopefully … Continue reading “Virtual method call from constructor” What Could Go Wrong?

Software Design and First Principles–Part 0: Concepts of Object Orientation

I often compare software development with building houses or woodworking.  I sometimes even compare software development with the vocation of electrician.  In each of these other vocations, craftspeople need to go through a period of apprenticeship and mentoring before being “allowed” to practice their craft.  In each of these vocations there are a series of rules that apply to a lot of the basics of what what they do.  With building houses there are techniques and principles that are regulated by building codes; with electricians there’s techniques and fundamentals that are effectively regulated by electrical codes and standards.  It’s one … Continue reading Software Design and First Principles–Part 0: Concepts of Object Orientation