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 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

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

Fluent Builders, Part 1

I’ve seen some conversations about fluent builders as of late, and I’d thought I’d post some information about fluent builders, the principles behind them, the problems they address, and how to implement them. Fluent Builder is a combination of the builder pattern and a fluent API. The builder pattern is similar to the factory pattern in that it’s intended to abstract the creation of other objects.  This is often meant to abstract the fact that many objects need to be created (ala the composite pattern).  It’s often intended to hide the fact that the creation of one object is dependant … Continue reading Fluent Builders, Part 1

Using the dynamic Keyword in C# to Improve Object Orientation – A Follow-up

Based on some feedback, some clarification is warranted with regard to my previous post titled “Using the dynamic Keyword in C# to Improve Object Orientation”. As Jarek Kowalski correctly pointed out, the example code that I provided could have used the Visitor pattern instead to get the same result.  My impetus for using the dynamic keyword the way I did was slightly different from how I described my example—which was meant to be easier to read. I think it’s worthwhile describing the Visitor Pattern.  The Visitor pattern is a pattern used to separate the responsibility of an algorithm from the … Continue reading Using the dynamic Keyword in C# to Improve Object Orientation – A Follow-up

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

A Upcoming Pandemic of Domain Anaemia

There’s a well-known anti-pattern called the anaemic domain model[1][2].  This anti-pattern basically says domain entities, chronically, have little or no behaviour (remember, object-oriented design is about attributes and behaviour). It should be obvious that a domain model that isn’t truly object oriented is a domain model with a problem.  But, let’s look at other reasons why the Anaemic Domain Model is an anti-pattern.  Your Domain is the nexus, the essence, of your system. An anaemic domain model is basically a reporting system.  Each “Entity” becomes, essentially, a query.  This is fine, reporting systems are necessary and prevalent.  But, to shoe-horn … Continue reading A Upcoming Pandemic of Domain Anaemia

Pontificating Virtual Parameterized Constructors in C#

Tom Hollander recently posted about a change he required to the Enterprise Library for date/time validation.  He had to create a new class (rather than modify the Enterprise Library) that derived from another, defective class.  One of his complaints was that in order to effectively implement the base class he had to also write matching constructors that simply called the base class.  His suggestion was effectively to add the concept of virtual parameterized constructors to C#.  I detail “parameterized constructors” because C# already effectively has virtual default constructors.  In the following example the base constructor (Form()) is automatically called by … Continue reading Pontificating Virtual Parameterized Constructors in C#

Bridges and Factories

In my previous post, I talked about Dependency Injection (DI).  One implementation of DI is using interface-oriented design to abstract a class from an injected dependency via an interface.  This is one possible implementation of the Bridge pattern.  Depending only upon an interface and classes to implement that interface opens up some very interesting possibilities. The tried-and-true means of creating an object is to simply directly use it’s constructor, for example:         IPerson person = new Employee(“Peter”, “Ritchie”); This is nice and simple; but we’re still coupled to Employee despite using an IPerson object thereafter.  The above code hasn’t truly eliminated the … Continue reading Bridges and Factories

Dependency Injection

Dependency injection (DI) is a form of inversion of control.  There seems to be a tendency in some circles to refer to dependency injection as inversion of control (IoC).  Dependency injection is a form of abstraction by removing physical dependencies between classes and potentially assemblies.  This abstraction can have many different motives.  One motive is for Aspect Oriented Software Development (ASOD) where you’re abstracting shared (or cross-cutting) concerns into independent classes.  Another motive is for Test-Driven Development (TDD) where you want to be able to test each class independently of its dependencies–in which case injected dependencies are “mocked”–technically this is … Continue reading Dependency Injection