The Daily Parker

Politics, Weather, Photography, and the Dog

R is for Reflection

Blogging A to ZOK, I lied. I managed to find 15 minutes to bring you day 18 of the Blogging A-to-Z challenge, in which I'll discuss one of the coolest feature of the .NET ecosystem: reflection.

Reflection gives .NET code the ability to inspect and use any other .NET code, full stop. If you think about it, the runtime has to have this ability just to function. But any code can use tools in the System.Reflection namespace. This lets you do some pretty cool stuff.

Here's a (necessarily brief) example, from the Inner Drive Extensible Architecture. This method, in the TypeInfo class, uses reflection to describe all the methods in a Type:

using System;
using System.Collections.Generic;
using System.Data;
using System.Diagnostics;
using System.Globalization;
using System.Linq;
using System.Reflection;
using System.Text;

public static IDictionary<string, MethodInfo> ReflectMethods(object target)
{
	if (null == target) return new Dictionary<string, MethodInfo>();

	var thisType = target.GetType();
	var methods = thisType.GetMethods(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Static);

	var returnList = new Dictionary<string, MethodInfo>();
	foreach (var thisMethod in methods.OrderBy(m => m.Name))
	{
		var parameters = thisMethod.GetParameters();
		var keyBuilder = new StringBuilder(thisMethod.Name.Length + (parameters.Length * 16));
		keyBuilder.Append(thisMethod.Name);
		foreach (var t in parameters)
		{
			keyBuilder.Append(";P=");
			keyBuilder.Append(t.ParameterType.ToString());
		}
		keyBuilder.Append(";R=");
		keyBuilder.Append(thisMethod.ReturnType.ToString());
		keyBuilder.Append(";F=");
		keyBuilder.Append(thisMethod.Attributes.ToString());

		try 
		{
			returnList.Add(keyBuilder.ToString(), thisMethod);
		}
		catch (ArgumentException aex) 
		{
			Trace.WriteLine(string.Format(CultureInfo.InvariantCulture, "> Exception on {0}: {1}", keyBuilder, aex.Message));
		}
		catch (Exception ex)
		{
			Trace.WriteLine(string.Format(CultureInfo.InvariantCulture, "> Exception on {0}: {1}", keyBuilder, ex.Message));
			throw;
		}
	}

	return returnList;
}

The System.Reflection.Assembly class also allows you to create and activate instances of any type, use its methods, read its properties, and send it events.

Reflection is hugely powerful and hugely useful. And very, very cool.

Q is for Querying

Blogging A to ZPosting day 17 of the Blogging A-to-Z challenge just a little late because of stuff (see next post). Apologies.

Today's topic is querying, which .NET makes relatively easy through the magic of LINQ. Last week I showed how LINQ works when dealing with in-memory collections of things. In combination with Entity Framework, or another object-relational mapper (ORM), LINQ makes getting data out of your database a ton easier.

When querying a database in a .NET application, you will generally need a database connection object, a database command object, and a data reader. Here's a simple example using SQL Server:

public void DirectQueryExample(string connectionString)
{
	using (var conn = new SqlConnection(connectionString))
	{
		var command = new SqlCommand("SELECT * FROM LookupData", conn);
		conn.Open();
		var reader = command.ExecuteReader();
		foreach (var row in reader)
		{
			Console.WriteLine(reader[0]);
		}
	}
}

(Let's skip for now how bad it is to execute raw SQL from your application.)

With Entity Framework (or another ORM), the ORM generates classes that represent tables or views in your database. Imagine you have an animals table, represented by an animal class in your data project. Finding them in your database might now look like this:

public IEnumerable<Animal> OrmQueryExample(string species)
{
	var result = new List<Animal>();
	using (var db = Orm.Context)
	{
		var dtos = db.Animals.Where(p => p.Species == species);
		result.AddRange(dtos.ForEach(MapDtoToDomainObject));
	}

	return result;
}

private Animal MapDtoToDomainObject(AnimalDto animalDto)
{
	// Code elided
}

That looks a little different, no? Instead of opening a connection to the database and executing a query, we use a database context that Entity Framework supplies. We then execute a LINQ query directly on the Animals table representation with a predicate. The ORM handles constructing and executing the query, and returns an IQueryable<T> of its self-generated Animal data transfer object (DTO). When we get that collection back, we map the fields on the DTO to the domain object we want, and return an IEnumerable<T> of our own domain object back to the caller. If the query comes up empty, we return an empty list. (Here's a decent Stack Overflow post on the difference between the two collection types.)

These are naive examples, of course, and there are many other ways of using EF. For example, for field mapping we might use a package like AutoMapper instead of rolling our own field-level mapping. I encourage you to read up on EF and related technologies.

P is for Polymorphism

Blogging A to ZWe're now past the half-way point, 16 days into the Blogging A-to-Z challenge. Time to go back to object-oriented design fundamentals.

OO design has four basic concepts:

All four have specific meanings. Today we'll just look at polymorphism (from Greek: "poly" meaning many and "morph" meaning shape).

Essentially, polymorphism means using the same identifiers in different ways. Let's take a contrived but common example: animals.

Imagine you have a class representing any animal (see under "abstraction"). Animals can move. So:

public abstract class Animal
{
	public abstract void Move();
}

Notice that the Move method has no implementation, since animal species have many different ways of moving.

Now imagine two concrete animal classes:

public class Dog : Animal
{
	public override void Move() 
	{
		// Walk like a quadraped
	}
}

public class Guppy : Animal
{
	public override void Move() 
	{
		// Swim like a fish
	}
}

Guppies and dogs both move around just fine in their own environments, and dogs can move around in the littoral areas of a guppy's environment as well. So both animals have a Move method.

In this way, the Move method is polymorphic. A caller doesn't need to know anything about guppies or dogs in order to get them to move. And the implementations of the Move method will be completely different:

public void MoveAll(IEnumerable<Animal> animals)
{
	animals.ForEach(a => a.Move());
}

That method doesn't care what the list contains. It moves them all the same.

Now imagine this class:

public class Electron : Lepton
{
	public override void Move() 
	{
		// Walk like a quadraped
	}
}

Electrons move too. The implementation of Electron.Move() differs from Dog.Move() or Guppy.Move() so vastly that no one really knows how electrons do it. But if you call Electron.Move(), you expect the thing to move.

I've only given examples of subtyping and duck typing today, so it's worth reading more about polymorphism in general. Also, as you recall from my discussion of interfaces, you probably would also define an interface like IMovable to express that your class can move, rather than relying on the abstract classes and inheritance. (Program to interfaces, not to implementations!)

N is for Namespace

Blogging A to ZDay 14 of the Blogging A-to-Z challenge brings us to namespaces.

Simply put, a namespace puts logical scope around a group of types. In .NET and in other languages, types typically belong to namespaces two or three levels down.

Look at the sample code for this series. You'll notice that all of the types have a scope around them something like this:

namespace InnerDrive.Application.Module
{
}

(In some languages it's customary to use the complete domain name of the organization creating the code as part of the namespace and to use alternate letter cases. If I were writing Java, for example, that would look like com.inner-drive.application.module.)

Every type defined in the namespace belongs to only that namespace. If I defined a type in the example namespace above called Foo, the fully-qualified type name would be InnerDrive.Application.Module.Foo. Because using FQTNs requires a lot of typing and makes code harder to read, .NET gives you another use of the namespace keyword:

using InnerDrive.Application.Module;

namespace InnerDrive.Application.OtherModule
{
	public class Bar
	{
		public void Initialize() 
		{
			// var foo = new InnerDrive.Application.Module.Foo() is not required
			var foo = new Foo();
			foo.Start();
		}
	}
}

Also, that Bar class belongs only to the InnerDrive.Application.OtherModule namespace, so another developer could create another Bar class in her own namespace without needing to worry about mine.

M is for Method

Blogging A to ZAlphabetical order doesn't actually put topics in the best sequence for learning, so we've had to wait until Day 13 of the Blogging A-to-Z challenge to talk about one of the most basic parts of an object-oriented program: methods.

A method takes a message from an object and does something with it. It's the behavior part of the behavior-plus-data pairing that orients your objects in the OO universe.

In .NET, even though you define fields, events, properties, and methods on your classes, under the hood the CLR sees only fields and methods. Properties and events are basically special flavors of methods that C# syntax makes easier to understand for humans. (See Monday's post.)

Take this simple C# snippet:

public string Name { get; internal set; }

The compiled code for that property will look almost the same as the compiled code for this pair of methods with a backing field:

public string get_Name()
{
	return _name;
}

internal void set_Name(string value)
{
	_name = value;
}

private string _name;

In fact, the method pair should look very familiar to Java developers, since that language hasn't really kept up with the times, you know? (Java developers would call the simplified version "syntactic sugar," which is what people call things that make life simpler when their salaries depend on it being complicated. It's essentially every argument a Rails developer has with her .NET counterpart until the first time she needs to decouple the database from the front end. That's when the .NET guy shows her a coding horror from the VB3 era with a mournful warning not to let this happen to her. But I digress.)

To sum up: Methods change the data or behavior of an object, but C# prefers that you use properties to change data, events to express behaviors to external consumers, and methods to ask the object to do something.

The A-to-Z challenge is off tomorrow, but it will return next week with a basic tool of organizing your software, a basic tool of performance testing, a basic principle of OO design, and three other posts I haven't thought about yet.

L is for LINQ

Blogging A to ZDay 12 of the Blogging A-to-Z challenge will introduce you to LINQ, another way .NET makes your life easier.

LINQ stands for Language INtegrated Query, which Microsoft describes as follows:

Traditionally, queries against data are expressed as simple strings without type checking at compile time or IntelliSense support. Furthermore, you have to learn a different query language for each type of data source: SQL databases, XML documents, various Web services, and so on. With LINQ, a query is a first-class language construct, just like classes, methods, events.

LINQ does a lot of things, so let me show just a small example. Before LINQ, if you wanted to loop through a collection and filter for specific characteristics, you'd have to do something like this:

public static ICollection<Room> ForEachLooping(IEnumerable<Room> rooms, string filter)
{
	var result = new List<Room>();
	foreach (var item in rooms)
	{
		if (filter == item.Name) result.Add(item);
	}

	return result;
}

Here's the LINQ version; see if you can spot the difference:

public static ICollection<Room> LinqLooping(IEnumerable<Room> rooms, string filter)
{
	return rooms.Where(p => p.Name == filter).ToList();
}

LINQ adds a whole set of extension methods to the IEnumerable<T> interface, including Average, Sum, Sort, Join...basically, everything you can do with a SQL statement, you can do with a LINQ statement.

In fact, there's an alternate syntax that's even more SQL-like:

public static ICollection<Room> SqlishLinq(IEnumerable<Room> rooms, string filter)
{
	return
		(from r in rooms
		where r.Name == filter
		select r)
	.ToList();
}

Note that LINQ naturally operates on and returns IEnumerable<T>, not ICollection<T>, so I invoked the .ToList() method for easier testing. In fact you would want to return IEnumerable<T> so that you can easily chain methods that use LINQ, as LINQ doesn't evaluate the whole query chain until you try to use one of its results. Calling ToList() forces an invocation.

LINQ is super-powerful and super-handy in too many cases to enumerate* in this short post. But if you use ReSharper (see Tuesday's post), you will learn it super-quickly.

(* See what I did there?)

I is for Interface

Blogging A to ZDay 9 of the Blogging A-to-Z challenge brings up one of the key concepts in object-oriented design: the interface.

In object-oriented design, rule #1 is "program to interfaces, not to implementation." In other words, when interacting with an object in your system, you should care about what behaviors and data you need to use, not what the object actually does with them.

Going back to last week's room-and-window example: the original problem was that I want to close all the windows in the house with one method call. The solution on Saturday involved having a Room class that exposed a list of Window objects which you could iterate over and call the Close() method on each.

That's great, but what if I want to close all the windows, doors, fireplaces, and anything else that I can close, because of the zombie apocalypse? In Saturday's implementation, I need to know that rooms have windows, doors, fireplaces, and other things specifically. That is, I need to know how each room is implemented.

I really don't care whether the thing is a window, a door, or a squirrel's mouth; I want it closed now, before the zombies get in.

So let's do this instead: define the behavior of a thing that I can close, and operate on the behavior rather than the thing itself. In C#, I can define an interface, which would look like this (and refer back to Saturday or the code sample file for the rest of the implementation):

namespace InnerDrive.DailyParkerAtoZ.WeekOne
{
    public interface ICloseable
    {
	    void Close();
    }
}

That defines a single behavior that a class can do. (Interfaces can also define data and events, but that's beyond the scope of this post.)

Now I can add the interface to the Window class:

public class Window : ICloseable
{
	public void Close() { }
	public void Open() { }
}

And then refactor the Room class so that you can add and close all manner of closeable things:

public class Room
{
	public void Add(ICloseable closeable)
	{
		_closeableThings.Add(closeable);
	}

	public void CloseEverything()
	{
		foreach (var thing in _closeableThings)
		{
			thing.Close();
		}
	}

	public IEnumerable<ICloseable> Windows => 
		new List<ICloseable>(_closeableThings.Where(p => p is Window));

	private readonly List<ICloseable> _closeableThings = new List<ICloseable>();
}

Well, that looks different. Instead of adding windows to a room, I can now add anything that can be closed. And because of that, at lines 16 and 17, in order to make sure the Windows list still works, I have to change the code so it only returns windows.

It's still a dumb piece of code, but you can start to see how powerful interfaces are. If in the future I create some new class with a Close() method, I can apply the ICloseable interface to it and stick it in a room. (Books, maybe? Escrow accounts? People named Glenn?)

There are many, many implications to all of this. But this is one of the foundations of OO design. I don't care what the thing is, I care what it does or knows. Program to interfaces, not to implementations.

H is for Human Factors

Blogging A to ZThe Blogging A-to-Z challenge enters its second week with a note about you, the human.

Last week I discussed several topics that you probably thought were about computers. They weren't. They were about how you interact with computers.

Computers don't need programming languages. This is a perfectly runnable program for the 6502 microprocessor:

0600: a9 01 8d 00 02 a9 05 8d 01 02 a9 08 8d 02 02

The human-readable version looks like this:

$0600    a9 01     LDA #$01
$0602    8d 00 02  STA $0200
$0605    a9 05     LDA #$05
$0607    8d 01 02  STA $0201
$060a    a9 08     LDA #$08
$060c    8d 02 02  STA $0202

Imagine looking at that all day and trying to debug it. You'd go insane. I know, because back in the day, I wrote that kind of code for 6502 chips and, well, you have evidence about my sanity in these pages.

This is why we use high-level languages instead of low-level ones. We try to abstract away all the crap. Instead of writing for the machine to read, as you do with assembly language (and even there you have a thin abstraction layer), you write software for a human to read.

And the languages continuously improve. Here, below, is some of the first code I ever plagiarized wrote that lived in a production application. You might understand what it does from reading it:

day=VAL(MID$(dtee$,4,2))
month=VAL(LEFT$(dtee$,2))
year=VAL(RIGHT$(dtee$,4))
hour=VAL(LEFT$(ttee$,2))
minute=VAL(MID$(ttee$,4,2))

MDYTOJULIAN:
   julian!=INT(365.2422# * year + 30.44 * (month-1) + day + 1)
   t1=month - 2 - 12 * (month<3)
   t2=year + (month<3)
   t3=INT(t2/100)
   t2=t2-100*t3
   weekday!=INT(2.61*t1-.2) + day + t2 + INT(t2/4)
   weekday! = (weekday! + INT(t3/4) - t3 - t3 + 77) MOD 7 + 1
   t4=julian! - 7 * INT(julian!/7)
   julian!=julian!-t4+weekday!+7*(t4<weekday!-1)+1721060#
   day$=dow$(weekday!)+","+STR$(day)+" "+month$(month)+STR$(year)
   h=hour-12
   IF h<0 THEN julian!=julian!-1:_
      h=h+24
   ju#=CDBL(julian!)
   ju#=ju#+(h/24)+(minute/1440)

That language is called QuickBASIC, which Microsoft published from 1985 until 1991, when Visual BASIC took over. It's a subroutine that converts a date into its Julian day number. I developed it because in QuickBASIC there was no way to do simple date calculations, but in astronomy, there was.

Here's the C# version:

public static double ToJulianDayNumber(this DateTimeOffset date)
{
   return date.ToOADate() + 2415018.5;
}

Forget that this is a naïve implementation, as there are a ton of special cases before the 19th century; and also forget that it uses a magic number that depends on understanding a bit of .NET and Windows internals (like, for example, that JD 2415018.5 is 30 December 1899, which is the epoch date for OLE automation).

The point is, I can abstract away all the calculations and create an extension method which allows me to get any Julian day number just by calling that method on any date-time struct:

var julian = DateTimeOffset.UtcNow.ToJulianDayNumber();

As a human, I'd bet you find that a lot easier to read and understand than the MDYTOJULIAN subroutine above.

But C# makes it even easier to calculate the difference between two dates, obviating the Julian day entirely, unless you're writing software specifically for astronomers:

var otherDay = new DateTimeOffset(2017, 01, 20, 17, 0, 0, TimeSpan.Zero)
var days = DateTimeOffset.Now.Subtract(otherDay).TotalDays;

Because really, you're trying to get the total days between two dates. The Julian day is a required abstraction when you don't have date arithmetic built in. But when you can just do date.Subtract(otherDate) to get a TimeSpan object, the code is a lot easier for humans to read.

Let the compiler worry about the machine. You worry about other humans.

Further reading:

G is for Generics

Blogging A to ZFor day 7 of the Blogging A-to-Z challenge, I'm going totally generic.

A generic in C# allows your code to "defer the specification of one or more types until the class or method is declared and instantiated by client code." In other words, you can declare a class that takes a type to be named later.

Imagine you have a program that represents a house. Your house has rooms, and the rooms have windows, doors, and in some cases, fireplaces. They also have furniture. And sometimes headless corpses. (Don't ask.)

If you were using C# 1.0, you'd need to design structures to hold all of these things, and you'd probably wind up using arrays, like this:

#region Copyright ©2002 Inner Drive Technology

using System.Collections;

#endregion

namespace InnerDrive.DailyParkerAtoZ.WeekOne
{
	public class Window
	{
		public void Close() { }
		public void Open() { }
	}


	public class RoomV1
	{
		public void Add(Window window)
		{
			_windows.Add(window);
		}

		public IEnumerable Windows
		{
			get
			{
				return new ArrayList(_windows);
			}
		}

		private readonly ArrayList _windows = new ArrayList();
	}
}

The only problem is...you don't really know for sure whether the things going into or coming out of the _windows array list are actually windows. That's because the System.Collections.ArrayList class only stores objects, not specific kinds of objects.

Generics allow you to impose type safety on the collection of windows through the use of a type parameter. Now you can do this:

public class Room
{
	public void Add(Window window)
	{
		_windows.Add(window);
	}

	public IEnumerable<Window> Windows => new List<Window>(_windows);

	private readonly List<Window> _windows = new	List<Window>();
}

(Notice also the nifty shorthand on line 8 that eliminates the get method.)

This works because the List<T> class takes any object type for T, leaving it up to the compiler to work out what type it should contain. The prototype for the class looks something like this:

public class List<T>
{
	public void Add(T input) { }
}

The type parameter T can be anything. (You can restrict what T can contain, which I will leave as an exercise for the reader.)

Generics simplify a lot of programming tasks. But just wait until Tuesday when I show you how to make object-oriented designs really fly in C#.

Housekeeping note: The A-to-Z Challenge takes Sundays off. The next post in this series will be on Monday. Enjoy your weekend!

E is for Encapsulation

Blogging A to ZWelcome to day 5 of the Blogging A-to-Z challenge.

In object-oriented design, we talk about a number of basic concepts that make code easier for humans to read and maintain. Encapsulation is fundamental, by hiding the internal data of a class so that only the class can use it. To access data within the class, you can't just reach in and grab it; you need to use the public properties and methods of the class.

Here's a stupid class:

#region Copyright ©2018 Inner Drive Technology

using System;
using System.Collections.Generic;

#endregion

namespace InnerDrive.DailyParkerAtoZ.WeekOne
{
	public class Encapsulation
	{
		public string Name { get; private set; }

		public void ChangeName(string newName)
		{
			if (string.IsNullOrWhiteSpace(newName))
			{
				throw new ArgumentException("Name must have a value", nameof(newName));
			}
			Name = newName;
			_names.Add(newName);
		}

		internal void Clear()
		{
			Name = string.Empty;
		}

		public IEnumerable<string> NameList => new List<string>(_names);

		private readonly List<string> _names = new List<string>();
	}
}

Seriously, this is dumb. But it demonstrates some of the ways C# encapsulates data.

Line 12 creates a property called Name that any code anywhere can call, because it's public. But it also declares a setter method that is private, meaning only the Encapsulation class itself can set the value of Name.

Lines 14-22 show how this works. The ChangeName method first makes sure you are giving it a real value, then changes Name and adds the new name to a list of names that is itself private. So the only way to change Name is to use the ChangeName method. (There's another way to do this in the property setter, but I wanted to show how this works exactly.)

Lines 24-27 provide you a way of clearing Name, but the method is marked internal. That means only classes in the same assembly can use this method, which has consequences for our unit tests, below.

Line 29 does a nifty trick where, instead of actually giving outside code access to its private list of _names (line 31), it creates a copy of the list and sends that out. Otherwise, anyone would be able to change the contents of _names just by using the NameList property.

Now here's the unit test code:

#region Copyright ©2018 Inner Drive Technology

using System.Linq;
using InnerDrive.DailyParkerAtoZ.WeekOne;
using Microsoft.VisualStudio.TestTools.UnitTesting;

#endregion

namespace InnerDrive.DailyParkerAtoZ.UnitTests
{
	[TestClass]
	public class EncapsulationTests
	{
		[TestMethod]
		public void CanSetNameOfObject()
		{
			var thing = new Encapsulation();
			//thing.Name = "This won't compile";
			//thing._names.Add("This won't compile either");
			thing.ChangeName("Ernie");
			Assert.AreEqual("Ernie", thing.Name);
			Assert.AreEqual(1, thing.NameList.Count());
		}

		[TestMethod]
		public void CanClearNames()
		{
			var thing = new Encapsulation();
			thing.ChangeName("Ernie");
			Assert.AreEqual("Ernie", thing.Name);
			Assert.AreEqual(1, thing.NameList.Count());

			// thing.Clear(); // oops—won't compile!

			// Assertions fail!
			Assert.IsTrue(string.IsNullOrWhiteSpace(thing.Name));
			Assert.AreEqual(1, thing.NameList.Count());
		}
	}
}

The comments explain what's going on.

So how can we test the Encapsulation.Clear() method? By adding this line to the InnerDrive.DailyParkerAtoZ.WeekOne.AssemblyInfo.cs file:

[assembly: InternalsVisibleTo("InnerDrive.DailyParkerAtoZ.UnitTests")]

Now all of the objects, properties, and methods in the WeekOne assembly marked internal are visible to the unit test class, and the tests pass.

Cool, right?

As always, the growing Visual Studio solution is here. The ZIP file contains the complete Git log of the project, by the way. Enjoy.