Thursday, April 25, 2013

Performance impact of sorted arrays.

Computer performance is filled with unexpected results. This morning on  stack overflow I found  such a result, and decided to replicate it in C#.



Take an array of random integers and sum only the big integers.  Next, sort the array and re-sum the big integers. Does sorting the array affect the time taken to compute the aggregation? Let's code it up:



The results:




Wow, it's 5 times faster to perform this sum over a sorted array then an unsorted array. What's going on? Branch prediction!  If you've never heard of branch prediction check out the stack overflow answer that inspired this post.



You can quickly replicate this experiment using LinqPad and MeasureIt.Net, by loading this file.

Wednesday, April 17, 2013

Getting Caller Information in C# without reflection (AKA: __LINE__ and __FILE__)

When writing tracing code it's very useful to know your caller. If you've used C or C++ you likely combined macro's,  __LINE__  and __FILE__ to implement this capability.



In C# 4.5 there is a better way to solve this problem. By adding attributed function parameters you can instruct the compiler to have your callers supply their calling information.  The code (full source @ bitbucket):

 
public static void TraceMessage(string message,
[CallerMemberName] string memberName = "",
[CallerFilePath] string sourceFilePath = "",
[CallerLineNumber] int sourceLineNumber = 0)
{
Console.WriteLine("message: " + message);
Console.WriteLine("member name: " + memberName);
Console.WriteLine("source file path: " + sourceFilePath);
Console.WriteLine("source line number: " + sourceLineNumber);
}

static void Main(string[] args)
{
TraceMessage("Hi");
}

Which provides the output:

PS C:\hgs\ig2600_blog\CallerInformation\bin\Debug> .\CallerInformation.exe
message: Hi
member name: Main
source file path: c:\hgs\ig2600_blog\CallerInformation\Program.cs
source line number: 27
PS C:\hgs\ig2600_blog\CallerInformation\bin\Debug>



For those who like to peek behind the curtain, this feature is implemented by having the compiler add the calling information to the call site, which we see from the IL:

.method private hidebysig static 
void Main (
string[] args
) cil managed
{
.entrypoint
IL_0000: nop
IL_0001: ldstr "Hi"
IL_0006: ldstr "Main"
IL_000b: ldstr "c:\\hgs\\ig2600_blog\\CallerInformation\\Program.cs"
IL_0010: ldc.i4.s 27
IL_0012: call void CallerInformation.Program::TraceMessage(string, string, string, int32)
IL_0017: nop
IL_0018: ret
}

Saturday, April 13, 2013

Cool Tools: Text to UML













I've replaced all these tools with the much simpler plant UML:



http://plantuml.com/
























Diagram Type


Input Text


Output Diagram





title Easy to draw Sequence Diagrams





Smart Fellow-> Igor's Blog: Read


Smarter Fellow-> Igor's Blog: Read


Smarter Fellow->Igor's Blog: Leave Comment













[Person|Weight|Speak();Walk()]


[Person]^-[Igor|FunnySocks|Juggle()]










For more complex sequence diagrams I recommend SDEdit.

Sunday, April 7, 2013

DevPreview: Agile Principles Patterns and Practices Part2 II: Agile Design Principles

This post is in devpreview - skip if you're not passionate about this topic, leave comments if you are. 





I read lots, and
often forget what I wrote about.  To help
me remember, I’m going to take notes on my blog. Feel free to discuss what
you've seen in the comments.





Terminology























Term


Definition


Entity


The
"thing" to which principles are applied.


Client


An entity which
consumes this entity .


Dependent


The entity on
which this entity depends to function.










Summary
of Principles





At 10,000 feet, design principles ensure that changes to a software entity, due to bugs or requirement changes,  have minimal impact on clients. 





























Principle


Elevator Pitch


SRP: Single
Responsibility


Entities should
have one and only one reason to change.


OCP: Open Closed


Entities should be
closed to changes, but open to extension


LSP: Liskov
Substitution


Derived entity
must be "substitutable" for the base entity in all regards.





DIP: Dependency
Inversion


An entity should
define the interfaces it requires of dependents. 


ISP: Interface
Segregation


An entity who
provides functionality for multiple types of clients should expose that
functionality via multiple interfaces.










SRP:
Single Responsibility Principle


An entity should
have a single responsibility. This can be tested if the entity can only require
change for a single reason.





You need to use it if:


You're changing your
entity for multiple reasons (e.g. how the objects are drawn, how the objects
are persisted)





Required
Because Traditionally


We lumped lots of
functionality into one big object.





You're
over doing it if:


You've created
separate classes which have never required changes.





OCP:
Open Closed Principle


Changes should only occur at predefined extension points.





You're
need to use it if:


Every time you
change your software, the changes are all through lots of the code.





Required
Because Traditionally


We didn't think
about where software would require flexibility.





You're
over doing it if:


You have extension
points that have only a single implementation.





LSP:
Liskov Substitution Principle


Derived entity must
be "substitutable" for the base entity in all regards.





You need to use it if:


Derived classes
break existing functionality.





Required
Because Traditionally


Derived entities
implemented "is-a" from a structural perspective. Inheritance needs
to be "is-a" from a behavioral point of you - more appropriately
named "acts-as".





Example
Violation:


Square deriving from
rectangle. Square is-a rectangle structurally, but no be behaviorally.  We can't substitute a square for a rectangle
for example, for a rectangle - rect.Height = 3; rect.Width=7; assert(rect.Height
==3) is not true for a square.





Notes


The "key"
for my understanding of this principle is that the invariants break on the base
class, not on the derived class. AKA a Square can be accessed as a rectangle,
but a rectangle cannot be access as a square.





IS-A is behavioral,
not structural!  The better English word
for this is can be substituted, or acts-as.





Unit tests against
the base class will often catch LSP violations.


Another way to catch
these is with pre and post conditions on base classes.





You're
over doing it if:


I don't think you
can over due this principle.








DIP:
Dependency Inversion Principle


Entities should
provide interfaces for their dependents to implement.





You need to use it if:


Your entities
require changes when your dependents change.





Required
Because Traditionally


We implemented
entities directly on the implementations exposed by their dependents.





You're
over doing it if:


You're creating
interfaces for well baked objects in the base classes (e.g. String) and your
software   will not be used cross
platform.





Notes


This is called
inversion, as traditionally, entities simply consumed the implementation
provided by their dependents.  If I had
my druthers would be called "dependency specification".





At the core:


  • No variable should hold a ref
    to a concrete class

  • No class should derive from a
    concrete class

  • No class should override an
    implemented base class method






ISP:
The interface segregation principle


A class can
implement many interfaces, but each interface is cohesive!





You need to use it if:


The interfaces do
not ad-here to the SRP principle.





Required
Because Traditionally


We used to create
interfaces that didn't match individual behavior, but instead created
interfaces to represent an implemented class.





You're
over doing it if:


You have a bunch of
single method interfaces.





Notes:


Clients should not
be forced to depend on a method they do not need.





Fat classes are OK,
but fat interfaces are not





Two separation
methods:





  1. Multiple inheritance of
    interface

  2. Use an adapter to convert
    from type 1 to type 2 (Add example)






Even when a client
depends on two interfaces implemented by the same class, specify the dependency
as two interfaces.





If you expose two
interfaces with similar functionality, repeat the duplication in the
interfaces.  Recall the interfaces will
be used by independent clients, and you don't want to force a change in a
client if their needs have not changed.

Friday, April 5, 2013

Duck typing in C#

There are two types of typing, static and dynamic (also known as duck). In Static typing systems you specify the type at compile time and if your program accesses a field not declared in your type, you get a handy compiler error. By contrast in dynamic typing systems a  type is never specified, and can't be validated at compile time. Thus errors are caught as runtime exceptions.



If dynamic typing is error prone, why would you want to use it? As usual, you'd want to use it because it provides  extra power. For example, imagine you have a list of several objects that implement Quack(). How can you call  Quack on all objects that support it?

class Dog
{
public string Quack() {return "Bark";}
}

class Cat
{
public string Quack() {return "Meow";}
}

class Mouse
{}

var animals = new List<object>() {new Dog(), new Cat(), new Mouse()};



If you've only used static languages, you'd think you need to add an interface IDuck{string Quack();}, and then change Dog and Cat to inherit from IDuck.  Knowing about design patterns, you might prefer to create an adapter to convert to a class that implements IDuck.  On the other hand, if you've used dynamic languages, you don't care. Instead of adding an interface, you use Duck Typing.  Duck typing gets it's name from the old adage - if it walks like a duck, and talks like a duck,  it's a duck.  C#4.0 added the duck typing feature which you can unlock via the dynamic type.  You can solve our earlier problem problem of collecting quackers like so:



var ducks = animals
// Enter the dynamic type system.
.Cast<dynamic>()
// Remove objects that can't quack
.Where(x=>x.GetType().GetMember("Quack").Length > 0 )
// return to the static type system.
.Select(x=>new {Quack = x.Quack()});

// Write the different quacks to the console.
foreach(var d in ducks) Console.WriteLine(d.Quack);



There you have it - duck typing is a powerful way to interact with your objects. Iin C# 4.0 you can mix C#'s safe static typing with the powerful, yet dangerous so use sparingly, duck typing system.