Search results for 'app:weblogs' matching tag 'Design/Coding Guidance'

The Rat-hole of Object-oriented Mapping

PeterRitchie — Fri, 10 Feb 2012 06:00:00 GMT

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 communicates with a domain layer about musical track information. That track information that is communicated lives in a hand-crafted Track abstraction. Typically this abstraction would live with the lower-level layer to maintain the unidirectional coupling. Of course the UI layer needs a Track concretion for it to do its job and must map between the higher-level layer and the lower-level layer. To further complicate things other decoupling may occur within each layer to manage dependencies. The UI may implement an MVx pattern in which case there may be a specific “view-model” track abstraction, the data layer may employ object-relational mapping, etc. etc.

Mark goes on to describe some “solutions” that often fall out of scenarios like this in a need to help manage the sheer magnitude of the classes involved: shared DTOs as cross-cutting entities, POCO classes, classes with only automatic properties, etc.

It's not just layering. Layering lives in this grey area between in-memory modules and out-of-process "tiers". Layering, I think, is an attempt to get the benefits of out-of-process decoupling without the infrastructure concerns of connecting and communicating between out-of-process processes. Of course, over and above the module/assembly separation, the only thing enforcing this decoupling in layers is skill and being methodical.

I'm convinced layering is often, or often becomes, a "speculative generality" to give some "future proofing" to the application since layering so closely resembles "tiering" (not to be confused with the eventual response of "tearing") as to make it easy to make it tiered should there ever be a need for it. To be clear, this is the wrong impetus to design an software. You’re effectively setting yourself up to fail by essentially “making up” requirements that are more than likely going to be wrong. If the requirements for the design are based on fallacies, they too are designed wrong. But, you have to continue to maintain this design until you re-write it (ever noticed that anti-pattern?).

But, implementing tiers or any sort of communication between processes often ends up in the same state. You have internal "domain" entities within the processes (and even within logical boundaries within those processes) that end up spawning the need for "DTO" objects that live at the seams on one or either side of the communication. Further that, many times that communication is facilitated by frameworks like WCF that create their own DTOs (SOAP envelopes for example). Except you're mandated by the physical boundaries of processes and you're forced to do things like shared-type assemblies to model the cross-cutting "entities" (if you choose that cross-cutting "optimization”) introducing a whole new level of effort and a massive surface area for attracting human error (you've technically introduced the need for versioning, potentially serialization, deployment issues, etc. etc.).

Creating an object-oriented type to simply act as a one-way container to something that lives on the other size of some logical of physical boundary has appeared to me to be a smell for quite a while. e.g. the UI layer in your original example has this concept of a "Track" DTO-like type that when used is only used in one direction at a time. When moving from the UI to the domain layer it's only written to. If it gets a "track" back from the domain layer the UI layer only reads from it. Abstracting this into an OO class seems pointless and, as Mark says, not particularly beneficial.

Let’s look specifically at the in-memory representation of something like a “Track”. We’ll limit our self and say that we need four Track abstractions: one for the view model, one for the domain layer abstraction, one for the data layer abstraction, and one for the object-relational mapping. (I’ve assumed that the data layer may not have a track “entity” and is only responsible for pushing data around). So, in effect we have four Track DTO classes in our system (and two or three Track “entities”). But, if we look at the in-memory representation of instances of these objects they’re effectively identical—each one can’t really have more data than another otherwise there’s something wrong. If we look at what’s actually happing with this data, we’re really writing a lot of code to copy memory around in a really inefficient way. The DTO classes in part become the way to copy memory. To be fair, this is a side-effect of the fact we’re manually mapping from one abstraction to another or from one abstraction to an entity (or vice-versa).

This type of thing isn’t entirely unknown; it sometimes goes by the name of ceremony.

For the most part, I think computer languages are hindering us in our ability to address this. Languages in general tend to maintain this specific way of messaging called method-calling that limits our ability to communicate only information that can be encapsulated by the language's or platform's type-system. But, to a certain extent we're also hindered by our myopia of "everything must be a type in language X". Maybe this is another manifestation of Maslow's Hammer.

Imagine if you removed all the mapping code in a complex system—especially a distributed system—and were left with just the “domain” code. I’ve done this with one system and I was astounded that over 75% of the code in the system had nothing to do with the systems “domain” (the “value-add”) and was “ceremony” to facilitate data mapping.

I sometimes hear this isn’t so much of a problem with specific frameworks. I’m often told that these frameworks do all the heavy lifting like this for us. But, they really don’t. The frameworks really just introduce another seam. The issue of Impedance Mismatch isn’t just related to object-relational mapping. I has to do with any mapping where both sides aren’t constrained by the same rules. I’ve blogged about this before. but I can use some “data framework” to generate “entities” based on a data model or even based on POCO’s. Some view this as solving the problem; but it doesn’t. Each side operates under different rules. The generated classes can only have as much impedance as what it has to communicate with, and you have to plan that that’s different than the impedance you’ll end up mapping from/to. The only real solution to this is to introduce another DTO to map between your domain and the classes generated by the framework so you are decoupled from the eventual “gotchas” where your domain has different expectations or rules than the framework you’re communicating with. When people don’t do this, you see all sorts of complains like “date/time in X isn’t the same as what I need”, etc.

Don’t fall into this rut. Think about what you’re doing; if you’re got 4 DTOs to hold the same data; maybe there’s a better way of doing it. Try to come up with something better and blog about it or at least talk about the problem out in the open like Mark.

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

PeterRitchie — Thu, 24 Nov 2011 06:00:00 GMT

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 myCommand...
		}
		//...
	}

If, while my active configuration is RELEASE, I rename-refactor DateAndTimeOfTransaction to TransactionDateTime then the block of code in the #if DEBUG is now invalid—DateAndTimeOfTransaction will not be renamed within this block. I will now get compile errors if I switch to DEBUG configuration (or worse still, if I check in an my continuous integration environment does a debug build).

I would have run into the same problem had I been in a DEBUG configuration with all the “#if RELEASE” blocks. Yes, I could create a configuration and define DEBUG and RELEASE and do my work in there. Yeah, no, not going down that twisted path… i.e. try doing it without manually adding a conditional compilation symbol.

I got to thinking about a better way. It dawned on me that #if blocks are effectively comments in other configurations (assuming DEBUG or RELEASE; but true with any symbol) and that comments are apologies, and it quickly became clear to me how to fix this.

Enter Extract Method refactoring and Conditional Methods. If you’ve been living under a rock or have simply forgotten, there exists a type in the BCL: System.Diagnostics.ConditionalAttribute. You put this attribute on methods that[whose calls] may or may not be included in the resulting binary (IL). But, they are still compiled (and thus syntax checked). So, if I followed the basic tenet for code comment smells and performed an Extract Method refactoring and applied the ConditionalAttribute to the resulting method, I’d end up with something like this:

		//...
		public void ProcessCommand(MyCommand myCommand)
		{
			CheckMyCommandPreconditions(myCommand);
			// do more stuff with myCommand...
		}
 
		[Conditional("DEBUG")]
		private static void CheckMyCommandPreconditions(MyCommand myCommand)
		{
			if (myCommand.DateAndTimeOfTransaction > DateTime.Now)
				throw new InvalidOperationException("DateTime expected to be in the past");
		}

Now, if I perform a rename refactoring on MyCommand.DateAndTimeOfTransaction, all usages of DateAndTimeOfTransaction get renamed and I no longer introduce compile errors.

Code Contracts

If you look closely at the name I chose for the extracted method you’ll notice that what this DEBUG code is actually doing is asserting method preconditions. This type of thing is actually supported in Code Contracts. Code Contracts implement a concept called Design by Contract (DbC). One benefit to DbC is that these checks are effectively proved at compile time so there’s no reason to perform this check at runtime or even write unit tests to check them because code to violate them becomes a “compile error” with Code Contracts. But, for my example I didn’t use DbC despite potentially being a better way of implementing this particular code.

Anyone know what we call a refactoring that introduces unwanted side-effects like compile errors?

[UPDATE: small correction to the description of conditional methods and what does/doesn't get generated to IL based on comment from Motti Shaked]

Criteria for Success

PeterRitchie — Sat, 07 May 2011 05:00:00 GMT

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 sight of things and not having a “destination”. This is what I refer to by “criteria for success”.

Criteria for success is basically the criteria by which what is expected to be delivered will be evaluated.

This criteria no only gives you a focused destination, it also provides a focus for the team. Without some sort of criteria it’s hard to gauge whether the team is side-tracked on something that doesn’t add value to the project. Criteria for success not only gives you a destination to strive for; but also means your efforts can be focused on that destination and be able to get to that destination quicker. This means the project can be completed quicker and progress can be judged more accurately.

Without defining criteria for success, software projects that do succeed succeed by accident. I don’t know about the rest of the industry; but I’m not really comfortable with completing my work “by accident”.

Defining “Done”

Defining “Done” is a very similar. Defining done is another popular mantra; but, I think “criteria for success” is more clear in its goal in that it’s almost explicit that acceptance criteria is what we’re looking for. “Done” can be a little wishy-washy and open for interpretation.

Defining Criteria

I don’t think it’s enough to complain that people have a problem defining success or “done”; so, I think it’s also important to help people get their own criteria for success. i.e. people have a problem coming up with criteria for success because no one has defined criteria for success for defining criteria for success—so to speak.

There’s various tools to help with this sort of thing; the most obvious is Agile. Defining user stories and getting acceptance from stakeholders on these stories is an excellent first step. Many people simply view user stories as a check-list of items. This can be extremely useful; but explicitly defining criteria (acceptance criteria is the more general term) isn’t an explicit task for most people.

Often we can’t expect out stakeholders to know how to define the acceptance criteria. “Just do it” or “make it work” are often the definition of done—which doesn’t leave us much in the way of unambiguous.

Agile kind of get’s away from “requirements” because requirements are often associated with waterfall methodologies and people expect that “requirements” mean a full set of requirements for the project before the project commences and doesn’t change for the life of the project. This really isn’t what requirements are; but, we’ll continue using terms like “criteria for success” and “defining ‘done’” to avoid these associations. But, theories and practices for effectively defining requirements can give us some valuable tools for defining good criteria. Karl Wiegers has a couple of excellent books that has some great criteria that we can reuse for our criteria:

Correct

Is the criteria correct (easy to say)? Is how we’re judging the deliverable right? If we’re judging x against y, is y what will actually be used as the criteria? If it’s really z, we can’t deliver something that satisfies y on purpose.

Feasible

Is the criteria even attainable? If we simply can’t reach that criteria, we’re going to fail… This can be a bit tricky because we don’t always know whether what we’re actually working is actually possible. With Agile, we like to separate what is known to be possible from what is not known to be possible with “spikes”. We purposely research things we’re not sure are possible (or not entirely sure how long things may take) into spikes so we can gather the information we need to define our criteria for success correctly. This mitigates the risk and gives is the ability to separate and time-box these aspects of the project because if we’re not really sure if it’s feasible or how long it’s going to take we need to prioritize it differently and explicitly.

Necessary

This is kind of obvious; but without this explicit criteria our criteria may lack focus and our work not be prioritized correctly and we end up working on tasks that are not important (i.e. not necessary). It’s critical that the criteria actually define necessary qualities.

Prioritized

I’ve already alluded to this; but prioritized criteria is essential for getting a project done properly. “Prioritized” is a bit ambiguous; so, it’s important to define what we mean by prioritization. The most essential part is that criteria is prioritized in relation to other criteria. There’s a tendency for everything to be prioritized as “important” and this has the opposite effect because it also means everything is defined as “unimportant” and the order that tasks get performed is open to interpretation (ease of implementation, interest in the task, coolness of the task, etc. none of which are stakeholder criteria). If it’s not important enough to prioritize a task correctly, it’s not important enough to actually perform the task.

Unambiguous

It may seem obvious; be we need to make sure our criteria is not ambiguous. It’s easy for criteria to be open for interpretation and end up being ambiguous. See the next point…

Verifiable

The criteria that Weigers’ details is that the criteria needs to be verifiable. It’s not enough to say “done” or “works”, we need to be able to unambiguously and empirically verify our work against specific criteria. Criteria like “works” just doesn’t cut it. This is stakeholder-driven. Often we’ll need to help our stakeholders think through what they’re ultimately going to use for verification—we want them to think about this before we begin the work, not after (which is very common).

Mapping to Your Database is a Private Affair

PeterRitchie — Sat, 26 Mar 2011 05:00:00 GMT

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 it generates private.

This may sound inconsequential, but there are some very real examples of how the limits of your choice of mapping framework can adversely affect your external interfaces. Let's look at some specific cases of this.

WCF supports data contracts and collection types. But, because of the nature of WCF and SOAP, it deals with serializing collections in a specific way. If you have an entity class with a collection property on it, it may be perfectly acceptable to be able to add objects to that collection and expect them to make their way back into the database. But, what does that mean for some entity that’s been serialized over the wire to another remote computer that doesn’t have access to your database? It means the entity you publish over WCF has a different behaviour that those local to (presumably) the server. But, you don’t want to modify your entity to work in a different way just for your WCF interface. You’ve published an interface to the outside world, clients are using it and you realise you need to make a change to your database. Opps, can’t it’s tightly coupled to your WCF interface; if you change your database and regenerate your entities you interface will change; breaking all your clients.

It works the other way around too. If you want to publish types over WCF, you have to annotate them, potentially, with all sorts of things to get them to serialize the way you want them to. The simplest is DataContractAttribute and DataMemberAttribute; but, could get more complex with things like IExtensibleObject, things like DataContractSerializer versus XmlSerializer, etc. Then there’s things like versioning… Do you really want to add all these annotations to code generated by your mapper? In some cases you can’t annotate them.

So, classes that map to/from the data effectively should be implementation details of your system; they should be private to your data layer; but, then how do we detail transferring data from our domain to the outside world? The Facade pattern and the Data Transfer Object pattern are a perfect solution to this. Your WCF interface is effectively a facade—an interface (usually simplified) to a different body of code—or a type of view to your model. When you have to provide complex data structures in your interface (i.e., other than base types) use Data Transfer Objects (DTOs) to wrap them in. Should the body of code that the facade wraps needs to change, simply modify the code that generates the DTOs. (I almost always get this question next: “What if the change means I can no longer produce the same DTO?”. Well, then you’ll have to decide if you should violate your contract and break all your clients, or find a way to make it work.)

I find it amusing to see all the examples of things like using your LINQ to SQL or LINQ to Entities classes in WCF interfaces. The examples are simple and often work; but once you try to do that in a complex system quickly realize you’re down a rat hole with really only one way out. Do yourself a favour and completely abstract your implementation details from your internally accessible interfaces; you’ll thank yourself.

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

PeterRitchie — Thu, 27 May 2010 05:00:00 GMT

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 class that the algorithm should operate upon. Essentially, a Visitor class is created to contain the algorithm that would be invoked through its Visit method and the classes that the algorithm operates upon some sort of method that accepts a reference to a Visitor object (which would simply invoke the Visit method). The example that Jarek provided was very similar to:

 	public interface IShapeVisitor

 		void Visit(Circle square);

 		void Visit(Rectangle square);

 	public class Circle : Shape

 		public override void Accept(IShapeVisitor shapeVisitor)

 			shapeVisitor.Visit(this);

 		//...

And an implementation of IShapeVisitor would be provided like this:

 	public  class  DrawingVisitor  : IShapeVisitor

 		public  void  Visit(Circle circle)

 			// draw circle here

 		public  void  Visit(Rectangle rectangle)

 			// draw rectangle here

In our case, the bodies of Visit methods would call a Draw method contained in another class like a View implementation. For example:

 	public  class  DrawingVisitor  : IShapeVisitor

 		private  IView  view;

 		public  DrawingVisitor(IView  view)

 			this.view = view;

 		public  void  Visit(Circle  circle)

 			view.Draw(circle);

 		public  void  Visit(Rectangle  rectangle)

 			view.Draw(rectangle);

This of course, adds another level of indirection that allows our target (a Shape implementation) to invoke a virtual method that ends up delegating to the Visitor. An implementation of Double Dispatch. This allows objects whose type isn’t known until run-time to properly invoke overloaded methods of another type.

As you can see, this is very powerful but adds a bit more complexity.

Now, in my original scenario (before I wrote the example for the post), I was dealing with invoking particular series of static overloads of System.Convert. Because I was dealing both with a class outside of my control and dealing with static overloads, the Visitor pattern could not be applied.

Using the dynamic Keyword in C# to Improve Object-Orientation

PeterRitchie — Mon, 24 May 2010 05:00:00 GMT

With polymorphism, object-oriented languages allow "...different data types to be handled using a uniform interface". Ad-hoc polymorphism is when you declare multiple methods of the same name but differ by the type of an argument. For example:

 private  static  void  Draw(Circle  circle)

 	//...

 private  static  void  Draw(Square  square)

 	//...

These are usually referred to as method overloads or method overloading. Which Draw method that gets invoked would be decided upon at compile-time based on the type of the parameter passed to it.

This is great, there’s many situations where this is useful; but what about situations where you don't know the exact type of the object until run-time? Many programmers instinctly lean towards using the GetType method available on all objects in .NET and perform a manual type comparison. For example:

 public  void  ProcessShape(Shape  shape)

 	Type  type = shape.GetType();

 	if  (type == typeof (Square ))

 		Draw((Square )shape);

 	else  if  (type == typeof (Circle ))

 		Draw((Circle )shape);

 	//...

There's other variants of this that make it a little harder to detect (and often gets around static code analysis warnings):

 public  void  ProcessShape(Shape  shape)

 	Square  square = shape as  Square ;

 	if  (square != null )

 		Draw(square);

 		return ;

 	Circle  circle = shape as  Circle ;

 	if  (circle != null )

 		Draw(circle);

 		return ;

 	//...

This code is a problem because we lose the benefits of C#s polymorphism (this code is coupled to Circle and Shape, if either is removed, this code would have to be changed and re-tested. If another Shape derivative were added, the code would again have to be changed and re-tested). There's multiple circumstances where this might happen over and above the so-far specious examples above. For example, deserializing an object from a Stream often results in not knowing the exact type of the object that has been deserialized. This is common with type hierarchies. For example:

 private  static  Shape  DeserializeShape(Stream  stream)

 	IFormatter  formatter = new  BinaryFormatter ();

 	return  formatter.Deserialize(stream) as  Shape ;

With the above code, we've re-hydrated either a Circle of a Square object into a Shape object (and ignored the appropriate checks to make sure a Shape object was loaded). We're now unable to use all the other polymorphism features of C#: method overloading won't work, C# will always only use the overload with the Shape argument and generics suffers from the same problem, it will always resolve to the type parameter of type Shape. For example, if we try to call one of our two Draw methods with our re-hydrated Shape object:

 			Draw(shape);

...we simply get a CS1502 warning because there is now Draw(Shape shape) method.

When programmers simply compare types, they're admitting that polymorphism has been circumvented and they have to resort to introducing the Conditional Complexity Code Smell or the Switch Statement Code Smell (C# doesn't support Type in a switch statement, so some programmers go ahead and create a integer type code--or even worse, use String in the switch statement)

So, what's a programmer to do to keep our code object-oriented and use polymorphism?

Well, if you read the title of this post, you've probably figured it out: use the dynamic keyword. The dynamic keyword bypasses static (compile-time) type checking and performs the type-checking dynamically (at run-time). So, for us to use our Draw overloads with our Shape object, we simply assign it to a dynamic object and use that object instead. For example:

 			Shape  shape = DeserializeShape(stream);

 			dynamic  dynShape = shape;

 			Draw(dynShape);

Now the runtime will check to see the actual type of dynShape object and invoke the corresponding Draw overload.

In our example, we've used inheritance to derive our two shapes from a single base. But, given our current use of Circle and Square objects, we don't need them to inherit from the same base class. We could simply view these shapes as an Object when we want to use dynamic. For example:

 private  static  Object  DeserializeShape(Stream  stream)

 	IFormatter  formatter = new  BinaryFormatter ();

 	return  formatter.Deserialize(stream);

 			//...

 			dynamic  shape = DeserializeShape(stream);

 			Draw(shape);

With the above, we’d have the same result without deriving both Circle and Square from Shape.

Using the dynamic Keyword in C# to Improve Object-Orientation

PeterRitchie — Mon, 24 May 2010 05:00:00 GMT

 private  static  void  Draw(Circle  circle)

 	//...

 private  static  void  Draw(Square  square)

 	//...

These are usually referred to as method overloads or method overloading. Which Draw method that gets invoked would be decided upon at compile-time based on the type of the parameter passed to it.

This is great, there are many situations where this is useful; but what about situations where you don't know the exact type of the object until run-time? Many programmers instinctly lean towards using the GetType method available on all objects in .NET and perform a manual type comparison. For example:

 public  void  ProcessShape(Shape  shape)

 	Type  type = shape.GetType();

 	if  (type == typeof (Square ))

 		Draw((Square )shape);

 	else  if  (type == typeof (Circle ))

 		Draw((Circle )shape);

 	//...

There are other variants of this that make it a little harder to detect (and often gets around static code analysis warnings):

 public  void  ProcessShape(Shape  shape)

 	Square  square = shape as  Square ;

 	if  (square != null )

 		Draw(square);

 		return ;

 	Circle  circle = shape as  Circle ;

 	if  (circle != null )

 		Draw(circle);

 		return ;

 	//...

This code is a problem because we lose the benefits of C#s polymorphism (this code is coupled to Circle and Shape, if either is removed, this code would have to be changed and re-tested. If another Shape derivative were added, the code would again have to be changed and re-tested). There are multiple circumstances where this might happen over and above the so-far specious examples above. For example, deserializing an object from a Stream often results in not knowing the exact type of the object that has been deserialized. This is common with type hierarchies. For example:

 private  static  Shape  DeserializeShape(Stream  stream)

 	IFormatter  formatter = new  BinaryFormatter ();

 	return  formatter.Deserialize(stream) as  Shape ;

 			Draw(shape);

...we simply get a CS1502 warning because there is now Draw(Shape shape) method.

So, what's a programmer to do to keep our code object-oriented and use polymorphism?

 			Shape  shape = DeserializeShape(stream);

 			dynamic  dynShape = shape;

 			Draw(dynShape);

Now the runtime will check to see the actual type of dynShape object and invoke the corresponding Draw overload.

 private  static  Object  DeserializeShape(Stream  stream)

 	IFormatter  formatter = new  BinaryFormatter ();

 	return  formatter.Deserialize(stream);

 			//...

 			dynamic  shape = DeserializeShape(stream);

 			Draw(shape);

With the above, we’d have the same result without deriving both Circle and Square from Shape.

The Difference between an Anti-Pattern and a Code Smell

PeterRitchie — Wed, 03 Feb 2010 06:00:00 GMT

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 term Anti-Pattern used in a couple of places lately that describe scenarios where patterns are used incorrectly. Each and every pattern has a time and a place (a context). Outside of that context, it is not an anti-pattern.

The term Code Smell is much better to describe inappropriate uses of patterns.

For example, Mark Seemann recently blogged that Service Locator is an Anti-Pattern. I disagree. I argue that there is a time and a place for Service Locator. Incorrect use of Service Locator is definitely a code smell—it’s an indication (a hint, not a certainty) that there’s something wrong with the design. The fact that you’re using Service Locator instead of Dependency Injection is, indeed, a design issue. But, dependency injection may not be possible. WebForms, for example. I can’t inject dependencies into a web form because I have no control over it’s construction. I’m forced to either use a Service Locator or a Factory to aid in my decoupling efforts.

del.icio.us Tags: AntiPattern,Design/coding Guidance,Patterns,Software Development,Software Development Guidance

Evolving code over time

PeterRitchie — Mon, 30 Mar 2009 05:00:00 GMT

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 that creates a blob of bytes to send to a host over the wire:

public static byte[] CreateRequestPacket()
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = NO_OPTIONAL_DATA_FLAG;
    result[2] = (byte) (result.Length - 2);

    Random random = new Random();
    for(int i = 3; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

In iteration x it writes out a request making certain assumptions about what the request contains. But, in iteration y it needs to optionally include other data. A non additive way is to simply modify CreateRequestPacket to do what is needed:

public static byte[] CreateRequestPacket(bool useOptionalData)
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = OPTIONAL_DATA_FLAG;
    int index = 2;
    if(useOptionalData)
    {
        result[index] = GetOptionalData();
        ++index;
    }
    result[index] = (byte) (result.Length - index);

    Random random = new Random();
    for(int i = index + 1; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

Now all calls to CreateRequestPacket need to change before a build can occure and you might not be able to modify all the files that contain these calls. So it causes undue blocking and forces you to change a number of files before you can check the file that CreateRequestPacket is contained withing.

Another way of implementing this would be to implement an additive change. That is, add a method that does what is needed and change the previous implementation to call the new method. For example:

public static byte[] CreateRequestPacket(bool useOptionalData)
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = OPTIONAL_DATA_FLAG;
    int index = 2;
    if(useOptionalData)
    {
        result[index] = GetOptionalData();
        ++index;
    }
    result[index] = (byte) (result.Length - index);

    Random random = new Random();
    for(int i = index + 1; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

public static byte[] CreateRequestPacket()
{
    return CreateRequestPacket(false);
}

This allows you to check the file that contains CreateRequestPacket in right after passing unit testing and allows you to gradually change all calls to CreateRequestPacket as time permits.

DevTeach 2009 Vancouver

PeterRitchie — Thu, 26 Mar 2009 05:00:00 GMT

The schedule for DevTeach 2009 Vancouver has been announced (http://www.devteach.com/). There’s lots of great software development sessions from some of the leaders in our industry.

If you’re planning on improving yourself, this is the conference to go to. Not only can you attend excellent sessions; but you can hob-knob with the presenters and pick their brains.

If you have a friend or co-worker who’s interested, there’s a limited-time two-for-one offer for an even better price: http://www.devteach.com/Register.aspx