Find examples of code, tutorials, and walkthroughs! When discussing programming and software engineering topics, examples are critical!
In this article I'll be going over one of my most used design patterns called the facade (or façade), and explaining why I like to use it. As with all things I share information about, it's important to remain pragmatic as software engineers. With that said, this article is not to persuade you to use this pattern exclusively or that there are not alternatives. Instead, I'd like to arm you with another design pattern tool in your figurative coding toolbox. The more tools you have available, the better prepared you are to go build awesome stuff. What We're Trying to Achieve With a Facade When I am developing software, whether it is personally, professionally, or as someone that is influencing the direction of software I am not directly coding myself, I encourage a focus on flexibility in software. I have…
This article is not set out to try and persuade you, the reader, that either using an iterator or materialized collection will universally solve your problems. Both iterator and materialized collection usage can be used to solve the scenarios that we'll be looking at, but both will come with a different set of pros and cons that we can further explore. The purpose of this article is to highlight scenarios based on real world experiences where either an iterator or materialized collection was being misunderstood, misused, and ultimately leading to a pile of headaches. As you read this article, if you find yourself saying "Well, sure, but they should have..." you're probably right. The problem is fundamentally not the usage of an iterator or the materialized collection, but not understanding how to consume them effectively. So I hope that when…
If you're newer to C# or programming in general, you may have used an iterator and not even realized it. Iterators can be a performant and effective tool that we have access to as .NET developers that allow us to traverse collections of data. Because one of the requirements of an iterator is that it must implement the IEnumerable interface, the results of an iterator can only be enumerated over. For example, you could use the results of an iterator in a foreach loop but you could not directly index into the iterator results (like you could an array) without some additional steps. Another requirement of iterators is that they use a special keyword called "yield" so that they can yield and return the individual elements that are to be provided to the caller of the iterator. In a nutshell,…
In C# and .NET, as programmers we have access to an interface that is called IEnumerable (or IEnumerable<T> for the generic version). Using IEnumerable allows us to iterate from a collection or data source by moving one element at a time. It's also important to note that all collection types in C# inherit from IEnumerable so collections you are familiar with like arrays and lists implement IEnumerable. I have been trying to help educate around IEnumerable usage for many years now so this is a renewed effort to help get more junior developers understanding how they work. As a bonus, if you're interested in working with the code that you see in this article you can clone it down from GitHub by visiting this link. A Companion Video https://www.youtube.com/watch?v=RR7Cq0iwNYo Simple IEnumerable Example Let's consider the following code example that will…
Working with strings is probably one of the earliest things we get to do as C# developers. In fact, if you consider that most of us start with the "Hello, World!" example, you're being exposed to the string type right away. But as you continue to use strings, you'll quickly find that you want to work with strings that span multiple lines and how we define multiline strings might be a tricky topic for beginners. No sweat! In this article, we'll look at some simple code examples that demonstrate how to define multiline strings. I'll also link over to GitHub where you can see this code committed and pushed up to a public repository. Finally, the last example contains a special bonus that I think you'll like (even if it's a slightly more advanced topic). Read until the end! The…
In C# 9.0 we received access to a great quality of life type called the record. You can read more about that from Microsoft here. Record types allowed us as dotnet programmers to skip a lot of boiler plate code, thereby saving us time and making code more readable. Wins all around! Before record types, we might have simple data transfer objects (called DTOs) that would look something like the following: public sealed class MyData { public MyData( string value1, int value2) { Value1 = value1; Value2 = value2; } publc string Value1 { get; } publc int Value2 { get; } } And for a simple class with two properties... I think we can all agree that the verbosity here is just over the top. With the record type that we were given access to, we can now write…
(This article is intended to be a spiritual successor to this previous entry, and now includes Tasks!) Even if you're new to C#, you've probably come across at least one of Tasks, Threads, or BackgroundWorkers. With a bit of additional time, it's likely you've seen all three in your journey. They're all ways to run concurrent code in C# and each has its own set of pros and cons. In this article, we will explore how each one operates at a high level. It's worth noting that in most modern .NET applications and libraries you'll see things converging to Tasks. The Approach I've gone ahead and created a test application that you can find here. Because this is in source control, it's possible/likely that it will diverge from what we see in this article, so I just wanted to offer…
I love dependency injection frameworks ever since I started using them. Specifically, I'm obsessed with using Autofac and I have a hard time developing applications unless I can use a solid DI framework like Autofac! I've recently been working with Xamarin and found that I wanted to use dependency injection, but some of the framework doesn't support this well out of the box. I' was adamant to get something going though, so I wanted to show you my way to make this work. Disclaimer: In its current state, this is certainly a bit of a hack. I'll explain why I've taken this approach though! In your Android projects for Xamarin, any class that inherits from Activity is responsible for being created by the framework. This means where we'd usually have the luxury of passing in dependencies via a constructor and…
I've been writing a little bit about Autofac and why it's rad, but today I want to talk about Autofac modules. In my previous post on this, I talk about one of drawbacks to the constructor dependency pattern is that at some point in your application, generally in the entry point, you get allllll of this spaghetti code that is the setup for your code base. Essentially, we've balanced having nice clean testable classes with having a really messy spot in the code. But it's only ONE spot and the rest of your code is nice. So it's a decent trade off. But we can do better than that, can't we? What are Autofac Modules? We can use Autofac modules to organize some of the code that we have in our entry point into logical groupings. So an Autofac module…
Why Consider Using Autofac With Unity3D? I think using a dependency injection framework is really valuable when you're building a complex application, and in my opinion, a game built in Unity is a great example of this. Using Autofac with Unity3D doesn't need to be a special case. I wrote a primer for using Autofac, and in it I discuss reasons why it's valuable and some of the reasons you'd consider switching to using a dependency container framework. Now it doesn't need to be Autofac, but I love the API and the usability, so that's my weapon of choice. Building a game can result in many complex systems working together. Not only that, if you intend to build many games it's a great opportunity to refactor code into different libraries for re-usability. If we're practicing writing good code using constructor…
