NDepend

Improve your .NET code quality with NDepend

programming_to_an_interface_simple_explanation_ndepend

Programming to an Interface: A Simple Explanation

As an architect, you know that programming to an interface is good. It’s what everyone should do.

But what does that mean? And why should you do it?

Searching the Internet for answers might only cause more confusion. There, you’ll find people arguing over what “programming to an interface” really means. And how everyone else is wrong about it. Yet everyone’s definition sounds pretty much the same. But is supposedly different. Somehow.

Let’s remove the confusion and break it down. In this post, we’ll look at what it means to program to an interface and why you should do it.

Continue reading Programming to an Interface: A Simple Explanation

what_is_a_good_unit_test

What Is a Good Unit Test? 5 Must-Haves

In this day and age, unit testing isn’t as controversial as it once was. Sure, you still see the occasional inflammatory, clickbait-y, confrontational “unit testing is garbage” type of post on Reddit and Hacker News.

And there are still developers out there ignorant of the existence of unit testing—or any type of automated testing, for what it’s worth. Believe it or not.

However, if we consider the developers that do know about unit testing, I’d say the debate is pretty much over. It’s generally agreed, today, that unit testing has a positive influence on software projects.

With that in mind, the next question then becomes “what makes for a good unit test?” That’s what this post is all about. Today, we present you five must-haves for a great unit test.

Continue reading What Is a Good Unit Test? 5 Must-Haves

declarative_programming_in_depth

Declarative Programming in Depth

Most people that start programming learn to program in an imperative way. Shortly after, they will probably learn a declarative language too. Many developers go a long way without knowing the difference. Many will probably never know. And they could very well be great developers. But knowing the difference could change the way you write code for the better, so let’s dive in.

Continue reading Declarative Programming in Depth

Software_architecture_5_patterns_you_need_to_know

Software Architecture: the 5 Patterns You Need to Know

When I was attending night school to become a programmer, I learned several design patterns: singleton, repository, factory, builder, decorator, etc. Design patterns give us a proven solution to existing and recurring problems. What I didn’t learn was that a similar mechanism exists on a higher level: software architecture patterns. These are patterns for the overall layout of your application or applications. They all have advantages and disadvantages. And they all address specific issues.

Continue reading Software Architecture: the 5 Patterns You Need to Know

Continuing Our Clean Architecture Example in C Sharp

Continuing Our Clean Architecture Example in C#

After a somewhat long delay, it’s time to finally continue our series on clean architecture. This is the second post in the inner series in which we show you a quick implementation of said architecture and the third post in the overall series. In case you haven’t read the previous posts, please do so by using the links in the series layout below:

Without further ado, let’s continue our implementation.

Continue reading Continuing Our Clean Architecture Example in C#

Text over the depths of the ocean

Imperative Programming in Depth

Programming languages come in all shapes and sizes: interpreted vs. compiled, weak vs. strong typing, low-level vs. high-level, terse vs. expressive… There are many buckets you can put a programming language into, even though not all are equally meaningful.

One very common way people classify languages is to organize them into paradigms. You can think of a paradigm as a group of languages that share similar characteristics. There are many paradigms currently in use: procedural, functional, and object-oriented. Many of these terms are often misused or confused; there’s also some degree of overlap between different paradigms, which definitely doesn’t make things easier.

Add all of that together and what you get is a landscape that’s not too easy for a beginner to grasp.  In today’s post, we’ll try and fix this situation by giving you a clear picture of the imperative programming paradigm.

Continue reading Imperative Programming in Depth

Separation of Concerns layered over dripping yellow liquid

Separation of Concerns, Explained

Software development is a very young field, particularly when you compare it to, say, medicine or law. Despite this, there’s no shortage of wisdom pearls, which accumulated in the decades that preceded us.

One interesting phenomenon I’ve observed in myself over the years—and I’m sure there’s a name for it—is that some of these sayings sound like they must be right, even if I don’t really understand them the first time I hear them. For instance, in my post about the SOLID principles, I mentioned how the SRP’s definition—”each class should have just one reason to change”—just ticks the right boxes for me in some way that I can’t even pinpoint. 

Unfortunately, just hearing a phrase and acknowledging that it kind of sounds right doesn’t do much to really make you understand the topic, right?

Then why do so many in our industry act like that’s the case? I’ve lost count of how many times I’ve seen experienced developers toss around catchphrases like this as if they’re able to automatically inject the necessary information into beginners’ heads.

In this spirit, I’ve decided to demystify one of these catchphrases that happens to be one of my favorites: “Separation of Concerns.” What does that mean and why should you care? That’s what today’s post is all about.

Continue reading Separation of Concerns, Explained