My previous two posts about Bertrand Meyer's Design by Contract (DbC) were mainly introductions to pre- and post-conditions and class invariants and how they can be implemented in C# – in this one we'll check out what implications DbC has if it is combined with the inheritance mechanism of object-oriented programming languages.

If you’ve ever programmed in XAML-based technologies, you know Resource Dictionaries: these XAML files usually contain the styles and templates you want to share across different views, or provide the default styles for Custom Controls you’ve written.

If you want to merge Resource Dictionaries into others (like e.g. within your App.xaml file), you normally use so-called PACK URIs to reference them. However, there is another way: you can combine your XAML file with a code-behind file to create a subclass of ResourceDictionary and reference it via its class name. This is what I call Stronger-Typed Resource Dictionaries.

Are you writing Windows 10 Apps already? I'm currently updating one app from Windows 8.1 Store to the Universal Windows Platform, which of course means that some redesign is required, too. If you ever have developed a Windows Store App, you probably know the Segoe UI Symbol font because it offers a lot of icons that you can use for e.g. buttons in the app bar. The benefit is clear: you do not have to create these icons by yourself, they fit within the overall design of Windows and you can scale them however you want because it's a font – it's always rendered crisp and sharp.

In one of my last posts, I discussed the basics of Bertrand Meyer's Design by Contract, namely pre- and post-conditions on methods. These Boolean assertions are used to check if the caller supplied valid arguments and performed the call while the target object was in a valid state, as well as to verify that the method produced the correct return value and/or side effects after it executed completely. This allows us to give semantic meaning to methods on our objects.

In this post, we will go one step further and discuss what class invariants are.

In one of his recent posts, Mark Seemann argued that you should not use the internal modifier for types and their members, because this decreases the testability of your code. While I totally agree with him on the subject, I want to highlight another reason for not using internal: the extensibility of your reusable code bases.

In my video series on the Dependency Inversion Principle that you can watch on YouTube now, I talk a lot about object-oriented abstractions and how we can use them to structure our code in a loosely coupled way. But I didn’t really specify what ‘Abstraction’ actually means in terms of Computer Science.

During the past weeks, I have been releasing videos on the Dependency Inversion Principle (DIP) which was originally published by Uncle Bob in 1996. I'm happy to announce that my video series is finished – you can watch it on YouTube now.

I'm currently reading Bertrand Meyer's "Object-Oriented Software Construction" (finally, I should say) and I'm absolutely amazed. Part of the reason I haven't touched this book yet is its age: the second edition was released in 1998. A book that is now 17 years old (the first edition being even ten years older) – what could I learn from it, especially in a field like software development where things change relatively fast?

I've finished my newest video series called “Beginning TDD” and you can watch it on YouTube now.