Posts

Showing posts from 2012

Code Contracts by Example

So how does one get his feet wet with Design-by-Contract? I remember when I first started using Microsoft Code Contracts I immediately made a huge mess of my projects from which it took several weeks to fully recover. After a while I figured out what worked and what didn't and I've developed a habitual way of doing things that seems to work okay. I won't go so far as to say they are best practices, but they keep me out of trouble. So without delving too deep into the theory of DbC, here are a few of the patterns I use. Constructor-based Dependency Injection While property-based DI is possible with code contracts, it gets ugly really quickly. The only way I've been able to make it work is with a backing field and explicit null checks in the getter. Basically, if you have a public setter then all bets are off as far as invariants are concerned. Constructor-based injection, on the other hand, is very clean and straightforward, and allows you to offload some of ...
Post a Comment
Read more

More on Non-nullable Reference Types

I was thinking about this some more today, and it occurred to me that a very simple construct could achieve what is being asked for without making any changes to the language or tools. Nullable value types (structs) were first implemented with an explicit wrapper class; it wasn't until later that the ValueType ? shorthand appeared. With implicit operators, we could basically do the same for non-nullable reference types: public struct NotNull<T> : IEquatable<T>, IEquatable<NotNull&ltT>> where T: class { private T _value; public NotNull(T value) { if (value == null) { throw new ArgumentNullException("value"); } _value = value; } public T Dereference() { if (_value == null) { throw new NullReferenceException(); } return _value; } public override bool Equals(object other) { if (ReferenceEquals(null, other)) ...
Post a Comment
Read more

Non-nullable Reference Types

A few days ago on InfoQ I saw a link to this blog post offering a solution to "The Billion Dollar Mistake" : allowing null references. The proposal, non-nullable reference types, is designed to replace this: /// <exception cref="ArgumentNullException"> /// Thrown if <paramref name="argument"/> is null. /// </exception> public void Method(SomeType argument) { if (argument == null) { throw ArgumentNullException("argument"); } // Do stuff... } With something like this: public void Method(SomeType! argument) { // Do stuff... } Of course complications arise with arrays of non-nullable reference types and with the methods that feature non-nullable output parameters. There are workarounds for those issues, but the result is a convoluted syntax and unnecessary overhead. But I think the main problem is that we're looking at the problem from the wrong direction. I think we have to accept...
2 comments
Read more

Code Formatting in Blogger

I've several hours of research, trial, and error, I've finally come across a workable solution for formatting code snippets in Blogger. Here are the basic steps: From your dashboard view, click "Template" and then "Edit HTML".  A modal confirmation dialog will appear.  Click "Proceed". Find the <head> tag and insert the following on the next line: <link href='https://sites.google.com/site/itswadesh/codehighlighter/shCore.css' rel='stylesheet' type='text/css' /> <link href='http://sites.google.com/site/itswadesh/codehighlighter/shThemeDefault.css' rel='stylesheet' type='text/css' /> <script src='http://sites.google.com/site/itswadesh/codehighlighter/shCore.js' type='text/javascript' /> <script src='http://sites.google.com/site/itswadesh/codehighlighter/shBrushCSharp.js' type='text/javascript' /> <script src='http:...
Post a Comment
Read more

20 Questions

In the game 20 questions one player thinks of something and the other players ask yes or no questions in an attempt to determine what the first player is thinking of.  The first player considers each question in light of his privately held information and replies with the appropriate response. This is a great model for encapsulation.  The first player thinks of an object and holds it in memory, and the details of the object are not available to the other players (private state).  Other player ask questions (invoke behaviors) to gather information about the object.  The behaviors are limited to yes or no questions and consist mostly of a common, predictable set of useful questions:  Is it an animal, vegetable, or mineral?  Is it bigger or smaller than a breadbox? Is it something you eat? etc. Suppose the game ends without a successful guess, and the first player thinks of another object for the next round of questions.  The new object replaces the ...
Post a Comment
Read more

Objects Are People, Too

Determining what state or behaviors to expose on an object can be difficult.  We all know the basic rules—encapsulate logic, only expose immutable value objects, and so on—but putting those rules into practice does not come naturally.  In fact, given our heritage of anemic, relational models, it’s almost unnatural .  Several years ago I remember reading about SOLID and other OOP principles and thinking to myself, how on earth would you persist that? Of course not all objects are persistent, and having the benefit of experience I now know that the view, domain, and persistence models need not be one and the same.  That being the case, there are incredible benefits to encapsulation, if done properly.  But how exactly does one put aside relational habits? One trick I have is to imagine objects have personalities and imagine how they would react if I asked certain questions or requested certain behaviors.  For example, suppose I had a Person object and I w...
1 comment
Read more

Practical Uses of the Visitor Pattern

When I first read about the visitor pattern I did not understand why it worked or how it would be useful.  Now, many years later, I finally understand why it works, but until recently I haven't encountered a situation where the visitor pattern was superior to alternative patterns. Today I came across a problem in which the visitor pattern actually seemed to offer some value in real code.  A data contract specifies a message containing a member with an abstract data type.  The caller is expected to provide a concrete implementation of that abstract type (one of several known DTO types) in the message.  When the message is received, the concrete object must be mapped onto a corresponding domain object.  Then after the request has completed, the domain object must be mapped back onto the DTO type for inclusion in the response message.  Both the DTO type and the domain object type are polymorphic, so the concrete implementations are not at all impo...
Post a Comment
Read more