Probably the most C# common interview question in London is "What's the difference between an abstract class and an interface?".  Let's be clear: if you use the word contract in your answer, you're not getting a job if I'm asking the question.  Contracts are a concept that doesn't directly correspond to any code construct in C#, abstract classes and interfaces are your fundamental building blocks of well written code. Here's the one word answer:  Code.  Abstract classes can have code, interfaces can't.  C#, like Java, doesn't allow you to pull code from two sources, so you can only inherit from...

When I first try to demonstrate the power of abstraction to developers, often they get confused.  Partly this is because they're unused to thinking in these terms, but partly it's because there's so many different types.  Ultimately, it's a case of tools for the job: you pull out a hammer when you've got a nail, a screwdriver when you've got a screw.  The problem is:  they can all be combined together in useful ways.  There's no such thing as a hammer than you twist, but abstract classes and interfaces can be used together in the one solution. Parameterization Everyone...

When we looked at the Open / Closed principle, we saw that certain practices produced fragile code. Static Methods Non-virtual methods Creating objects Too-specific variable declarations Hard-coded values Using the wrong object (the Law of Demeter) Of these, the first three are all things you can't override.  If you can't override things, they're inflexible and, inevitably, will cause problems.  In the cases we've seen, the Law of Demeter problem could be solved just by using the right object in the first place.  Equally, a non-virtual method is easy to fix, you just make it...