Back to basics: Using interface vs. abstract class

No comments

Tuesday, January 31, 2017

While teaching a course on design patterns I was asked by one of the participants when would I use an interface and when to use an abstract class. I've started the outline the reasons for each and ended up with a few good ones which I like to share in the following post.

Interfaces and abstract classes in an OO world

Most object oriented languages have the ability to define both interfaces and abstract classes. Even languages that have only abstract classed it's usually simple to implement interfaces by defining an abstract class without any method implementation (I'm looking at you C++).
And that's the main difference - while an interface defines a contract,, an abstract class (or pure virtual class) have several default behaviors implemented as well.

At first it does not look like a big issue – either define an interface IMyInterface or define a base class MyAbstractBase with the same methods. The real issues start further down the road - usually when a new class introduced into the system.

The problem down the road

The reason the question came up during my design patterns course is that one of the developers had an issue in his code: a few versions ago they had created a base abstract class as the and created many inheriting classes in an important part of their application. And so a few months went by and they discovered that while some of their classes needed to keep the old functionality – the a new class needed to perform similarly defined methods/operations using a completely different implementation. Unfortunately at this point it meant making a lot of changes to their existing code which could break existing functionality - and no one wants that! So in retrospective they wished they have used interfaces when passing object and that way new behavior can be introduced to the system without many breaking changes - right?

Why not use interfaces all the time?

Using interfaces instead of classes when defining dependencies is usually a good idea. Not all OOP languages were created equal: For example in Java all methods are overridable unless declared final while C# and C++ it's the other way around. This means that my ability to override a method depends on my language of choice. It also means that down the line, I might need to use external libraries which relay on the ability to override methods we might discoverer that we failed to make the right methods virtual. And so using ORMs, IoCs and Mocking frameworks (to name a few) makes our base classes look weird with some methods virtual and might cause even weirder behavior.
In Java where all of the methods are virtual unless declared otherwise there are a different set of problems - namely other developers inheriting classes and changing functionality in ways that were not anticipated by the class creator. And so defining an interface as a way of defining a clear contract between an object and its dependencies is a good way to make sure that it can be replaces easily without "paying" the price for previous implementation. Unfortunately it also means that every time I write new class implementing that interface I needs to figure out all of the needed functionality - a problem that can be avoided with a base class that implements common behavior - "free of charge". It seems that the best solution would be to use both an interface and a base class that implements it and add the common desired?

Using An interface and an abstract class together

The textbook solution is to have an interface which is passed around and referenced throughout my system as well as a base class implementing some of the common functionality. This means I can use the base class or not - according to the project’s needs. This way you do not have to commit to a specific implementation in case I do not need it. The price in this case is in maintenance. Every change to the interface needs to be reflected in the base class - new methods, deleted methods and so on.

It's not a huge price but this kind of work tend to become tiring real quick, and developers will end implementing one of the solutions described above and we’re back to square one.


The end of this debate we’ve ended up with more questions than answers but we did found a few ground rules – when in doubt use an interface and if use abstract classes when refactoring duplicate code. And in any case never-ever name your classes with the suffix “Impl”

The 5 D’s of creating software

No comments

Monday, December 12, 2016

Warning: Do not take the following post too seriously

The software development world is governed by many forces beyond our control. There's so much to do and so little time, there’s so much to learn an experience and on top of that it software development keeps on changing and mutating all of the time.

There are forces or rather aspects of software development that remains the same regardless of technology. Those are timeless and do not change. And so to fully control the software which is our creation a professional software developer must master the five disciplines all which mysteriously starts with the letter ‘D’:

Design (& Architecture)

The act of deciding what your software look like before it’s even written. Design is also a balance between what we know now, what we expect to happen and some of our wishful thinking. Design can be abused by overthinking, over design happen when developers want to use the latest technology or by someone who has just read a good book about design patterns and completely missed the point.

A good software design is understandable, maintainable and flexible. A good design is easy to change as requirements are added, bugs are found and customers change their mind. Design can be created using a pen and a napkin or grown over time using tests and lesson learned. There are projects without architects but very few with architecture - they are a mess – the lack of a guiding hand and clear development path gives births to ugly, unmaintainable ugly which later become a story to frighten junior developers in years to come.

A good developer knows how to design enough, and can choose the right tools and technologies that best fits the task at hand.


This is the act of writing the code. Some think that is the only thing that software developers are good for.
Writing software starts at the developer’s mind and become reality using the keyboard (and sometime the mouse).

It is what software developers do (hence the name). But it's more than hitting your keyboard and fast and as hard as you can. But on how clearly a developer can express complex and sometimes contradicting ideas using code.

A seasoned developer knows how to employ his development environment of choice to create elegant code. He knows the keyboard shortcuts and knows how to refactor and navigate his code. But the real tool of a good developer is the ability to learn. New technology, new paradigm, new programming languages all of which are more tools to use.

Software development is more than just writing code. It's making sure that code works and employing the right methodology so that that code continue on working.


An overlooked art of finding and fixing past mistakes. Debugging is rarely talked about but carry a lot of power in the hand of a real professional.

There's more to debugging than pressing F10 countless times and mastering debugging is hard. A bug catches you when you least expects it. And when debugging happens a developer is most likely concerned about getting back to his work than finding ways to reduce the time and pain of trying to solve yet another issue no one has thought about.

In order to be good at debugging a developer must understand his code top to bottom, as well as how that code interacts with other parts of the system. Debugging can require finding information that no longer exist that happened during condition that no longer valid. A new set of tools need to be used, under pressure from peers and managers while time runs out.


Your code does not begin and ends on your machine. In order for clients to use your code they need your code to magically move from your machine all they way to the client's passing testing and staging environment on the way.

Deployment goes hand in hand with automation. Your code should be build and tested on another machine and if you get it right - even update the next machine all the way to the production environment or easily downloaded installer.

Although some developers think that deployment is none of their business. A smart developer will learn a lot by participating in the journey of his code and understand valuable lessons while contributing to the overall success of the project - in ways that transcend "just writing code".


The beginning and end of every software project. No deadlines sounds like fun but without deadlines there is no project. The art of deadline is also the art of trying to estimate work, prioritize and divide tasks to create an iterative progress that guarantees that even if the project won't be finished on time - at least your client (and boss) will be happy.


So there you have it - the five D's of software development. Now go write some code!

Upcoming speaking engagements: Vancouver here I come!

No comments

Monday, November 14, 2016

At the beginning of December I’m going to speak at ConFoo Vancouver.
Vancouver 2016 | December 5-7, 2016
I spoke at ConFoo Montreal in the past and I look forward to speaking at the first ever ConFoo Vancouver.
I’ll be speaking on two of my favorite topics – unit testing and electronics (not at the same session).
5 Unit Testing Facts I Wish I’d Known 7 Years Ago – on Tuesday (6th) . A session I’ve created as a kind of retrospective of what worked, and especially what didn’t work when I attempted to start unit test my code. I wanted to provide a few tips for software developer starting down the unit testing path so that they won’t fail just like I did oh so many years ago.
Electronics 101 for Software Developers – on Wednesday (7th). A fun session for all developers who want to start building cool IoT/electronics projects. I plan to start from the basics of electricity and explain how to use sensors and read circuit diagrams – it would be fun, informative and useful for anyone who ever wanted to build his own robot army:
Before all that on Monday night (5/12) I’m going to speak at the Windows Platform Developer Group with Ariel Ben Horesh.
We’re going to do a two part meetup – I’ll talk about Visual Studio debugging tricks every .NET developer should know and Ariel is going to discuss how to build your company’s mobile development strategy in “Calling the Shots: Should I go Native or Cross Platform?
If you’re interested in learning how to quickly and effectively debug your code you should come – especially since you might receive an OzCode license.

So if you’re living in Vancouver or you’re just in town for ConFoo – come by and say hello.

With every new version the C# language has grown and improved. The last version so a.k.a C# 6 has brought some of my favorite features. And with C# 7 just around the corner I know there's more to come.

One of the new useful features added to C# is the ability to filter exceptions. Consider the following - completely (and poorly) invented class:

public class MyClass 
public class MyClass
    public void MyMethod(int count)
        throw new MyException(1000 + count);

If I need to exit only when an exception with a specific error code is thrown I can write the following code:

class Program
    static void Main(string[] args)
        var myClass = new MyClass();

        for (int i = 0; i < 10; i++)

            catch (MyException ex) when (ex.ErrorCode == 1003)
                Console.WriteLine($"Got the right exception in iteration: {i}");
            catch (MyException ex)
                Console.WriteLine($"Other exception: {ex.ErrorCode}");

And each exception with value which is not 1003 will be swallowed. There are limitless scenarios in which this feature can be useful - for example have a look at Jimmy Bogard's post on how to avoid exceptions on the weekends.

But what happens when I need the same functionality but just for a specific debug session or if I'm working on a project which does not use C# 6 (yet?). For those cases I can use the magic of conditional breakpoints.

Filtering with conditional breakpoints

There are two ways to set a conditional breakpoint - the old way and the OzCode way.

If you never used them - you should; it's a time saving tool which will save you valuable debug time.

In order to use Conditional breakpoints just create a regular breakpoint at the exception's constructor and then add condition to that breakpoint - simple as that. With OzCode it's even easier:

  1. Create a "regular" breakpoint at the exception's constructor
  2. Run until breakpoint
  3. Open the quick watch window
  4. Choose the property you care about
  5. Update the condition
  6. Press "ok" and run



Once you fix the bug you can delete the conditional breakpoint and continue working – or find and fix another bug.


Conditional breakpoints have been part of your favorite IDE of choice for ever and yet not all developers use them as often as they should. Catching just the right exception is one scenario where they help find and fix bugs and save us time in which we can develop new features for our customers or just grab another cup of coffee.

Faking DateTime using Microsoft Fakes seems to be broken

No comments

Tuesday, November 08, 2016

It seems as if causing DateTime.Now to return another value has become the demo to show when demoing an unconstrained Mocking framework. It’s easy to show and needed in many unit tests – unless you want your tests to be affected by time – trust me and you don’t.
That’s why I was amazed to find out that the demo from MSDN which showed how to use Shims has somehow stopped working…

What I initially did

In order to start using Microsoft Fakes you need to use Visual Studio Enterprise edition – I’ve used VS2015 update 5 in this case.
The next step is to right click on the assembly you need to fake and choose Add Fake Assembly
this will generate the same assembly followed .fakes so if you’re faking MyAssembly a new MyAssembly.Fakes will be created this is not the case with System as I was quickly reminded.
Now according to my knowledge and the demos at hand all I needed to do now is find ShimDateTime and use some magic to change how it behaved – but it was no where to be found – in fact I could not see anything to do with DateTime which I know for certain existed inside System.
It took me a while to get it but looking at the project’s references showed the problem:
You see – usually when faking System two fake assemblies are created – one for System and one for mscorlib where the good stuff is.
You can even see that under Fakes folder there are two configuration files one for each – but no mscorlib to be found.

The Solution?

I did what any developer would have done: I’ve decided to repeat the same process again expecting different results. Actually first I Googled a bit and found very little information.
And so I need to delete three files – the fakes assembly and two configuration files (fake configuration?) and try again – and I got the exact same mess.
After trying two more time – just to make sure I’ve decided to check the output window and saw the following:
Armed with this new knowledge I’ve decided to dig into some documentation and found that some new breaking changes caused issues when creating fakes and quick workaround would be to remove a few classes from the To fake list” and so I’ve opened mscorlib.fakes configuration file and written (read: pasted) the following code:
<Fakes xmlns="">
  <Assembly Name="mscorlib" Version=""/>
    <Remove FullName="System.Diagnostics.Tracing"/>
    <Remove FullName="System.Text.Encoding"/>
    <Remove FullName="System.Security.Cryptography" />
Next I’ve deleted System. and system.fakes and right-clicked System->Add Fakes Assembly and got the following:
And now I was able to write my test using my DateTime of choosing.

Frustrating? you bet! but at least now I know a quick workaround and able to test time based code – if all I have is Microsoft Fakes.
Last week my very first Pluralsight course went live!
My course on unit testing in C++ using CATCH is ready for your viewing pleasure. It’s about a topic I’m passionate about - how to write good unit tests, I’ve used Catch because I found that it helps writing good tests while avoiding many of the pitfalls that unit test practitioners might stumble on.
It was cool seeing the result of several months (more if you count the audition) of work.
Writing unit tests is a big part of being a professional software developer. This course would teach you how to write readable and robust unit tests using Catch, a simple, yet powerful unit testing framework.

I like to thank the good people of Pluralsight for helping me create this course and for the excellent feedback and all their hard work.
If you have any feedback or suggestion please let me know.

An open letter to conference’s organizers

No comments

Sunday, October 23, 2016

I got my first international speaking opportunity in 2012. After sending countless proposals and getting just as many rejects I got an email from DevReach telling me I got accepted – I remember reading it twice just to make sure. Speaking on DevReach was a big change from the user group talks I’ve done until then (and still do) – it was an amazing conference and I had the time of my life. Since then I’ve spoke at many other conferences and enjoyed every single one of them. However over the years I’ve noticed several things that some conferences did better than others – I’m not talking about the venue, number of speakers or the food/snacks but rather I’d like to focus on the relation between the single speaker and the conference’s organizers.

But first of all – if you’re a conference organizer I’d like to say one thing:

Thank you!

I’d like to say it again – thank you!

If you ever helped organize a conference – you’ve helped make our craft better and made a difference to countless other developers. You’ve labored for days (and nights) so that other practitioners of our craft can learn things that will make them better at their job while having a damn good time on top of that.

Thank you for providing a place to share ideas and learn new things – and if by chance you’re responsible for a conference I was fortunate to speak at – I will ever be in your debt (or owe you a beer).

Having said that, there are three things I’ve noticed some conference employ which I  wish all conference would do – I guess that the whole purpose of this post – and so without further ado let’s talk about the very beginning – how to find out about your conference: 

Please help me find out about your conference

As a speaker there is nothing more frustrating than finding out that you’ve just missed a conference’s CFP (Call For Papers) – that magical time in which you can submit talk abstracts to be considered, evaluated and even be selected as a fitting topic for that conference.

Some conference have a notification in place if you’ve already spoken at a conference in the past or it has a speaker mailing list. Otherwise a speaker needs to scan the internet with the hope of not missing another conference for the third time in a row. I do try, but I miss conferences CFP all the time even with good friends helping me catch CFPs, and following many twitter accounts as well as searching the internet on a monthly basis – I still find that catching the right conference is just too hard.

So if you want to make potential speakers lives easier – just create a mailing list and send us an email so we know when your conference is looking for speakers.

Make the speaker’s “benefits” known upfront (I.e. reimbursement)

Some conferences offer travel and/or hotel reimbursements while other offer different forms of compensation and some conferences don’t offer any – which is ok.

Not all conferences have the same budget – some have sponsors and ticket sales, while other are free and so cannot help the speaker with any travel or boarding costs - what you can or would provide your speakers it strictly up to you. All of this is well but the least you can do is let me know up-front.

The first thing I look for before submitting a few talks is if I’ll need to pay in order to speak, I need to be able to decide if the cost of travel and/or hotel on top of lost work days is worth speaking at your conference – if you let me know in time I might get an employer to cover some of the costs or even sponsor your conference, or I decide not to waste both our time.

In the last year I had to refuse a few speaking opportunities because the conference organizer notified me that I’ll need to cover my plane ticket only after my talk was already accepted and it was too late to do anything about it – other than cancel my appearance.

Help be become a better speaker (a.k.a feedback)

Everyone want to improve. If you’ve just rejected my session(s) – take a minute and tell me why. I used to send emails back to organizers asking what they did not like about my proposals – and gained a lot from their response. One conference which I like and respect did something even better – they post the reasons they have rejected your talks in your personal space on their site – so you get an explanation on how you can improve the next time you send session proposals.

Once a talk is over I like to talk with the audience to find out if they liked my talk and which parts they think were better and which should be tossed away. Some conferences do a good job of providing valuable, usable feedback as quickly as they can – and I wish I had proper feedback for each session I ever given.


This post is not a rant. Most of the conferences I spoke at over the years employed at least one of the practices mentioned  above. It’s all a matter of thinking about the speaker which in turn would help you make your conference great.

So if you’re planning a new conference or about to have the 99th year of an existing conference I wish you take the points I wrote about to heart.

And for the rest of you – the next time you go to an conference remember that someone worked hard to make sure you have a good time and be able to learn new cool things – and say thanks the organizers.


Until then – Happy coding…

Related Posts Plugin for WordPress, Blogger...