Content that is all about software design and engineering! Find examples of code often written in C# along with tutorials.
I asked on LinkedIn about whether or not people would be interested in a video stream that focused on programming, and I had some positive feedback. In order to test the waters, I decided I'd start with some system-design stuff given that I'm going through a bunch of practice with distributed systems. This is a bit of a change up from distributed systems in that this is interactions between co-located systems in a game framework I'm creating. Here's the video! https://www.youtube.com/watch?v=04rFmvFEeDw&ab_channel=DevLeader In the video stream, what I'm trying to accomplish is finding a way to share information from particular domains to be used in another domain. Domain in this sense is a functional area of the code base in question. I mean, that's the gist of it :) The complicated parts are: How do I keep domain information from leaking…
A Quick Brain-Dump on API Desgin I'll keep this one pretty brief as I haven't totally nailed down my thoughts on this. I still thought it was worth a quick little post: When you're creating a brand new API to expose some functionality of a system, should you design it with a strong focus on how the internals work? Should you ignore how internals work and make it as easy to consume as possible? Or is there an obvious balance? I find myself trying to answer this question without ever explicitly asking it. Any time I'm looking to extend or connect systems, this is likely to come up. Most Recently... Most recently I started trying to look at creating an API over AMQP to connect my game back-end to a Unity 3D front-end. I had been developing the back-end for…
What's An Interface? I mentioned in the first post of this series that I'll likely be referring to C# in most of these posts. I think the concept of an interface in C# extends to other languages--sometimes by a different name--so the discussion here may still be applicable. Some examples in C++, Java, and Python to get you going for comparisons. From MSDN: An interface contains definitions for a group of related functionalities that a class or a struct can implement. By using interfaces, you can, for example, include behavior from multiple sources in a class. That capability is important in C# because the language doesn't support multiple inheritance of classes. In addition, you must use an interface if you want to simulate inheritance for structs, because they can't actually inherit from another struct or class. It's also important to note…
Whose Job Is It? I wanted to share my experience that I had working on a recent project. If you've been programming for a while, you've definitely heard of the single responsibility principle. If you're new to programming, maybe this is news. The principle states: That every class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class You could extend this concept to apply to not only classes, but methods as well. Should you have that one method that is entirely responsible for creating a database connection, connecting to a web service, downloading data, updating the database, uploading some data, and then doing some user interface rendering? What would you even call that?! The idea is really this: break down your code into separate pieces of functionality.…
Enforcing Interfaces This is my second installment of the series related to my small side project that I started. I mentioned in the first post that one of the things I wanted to try out with this project is coding by interfaces. There's an article over at CodeProject that I once read (I'm struggling to dig it up now, arrrrrghh) that really gave me a different perspective about using interfaces when I program. Ever since then I've been a changed man. Seriously. The main message behind the article was along the lines of: Have your classes implement your interface, and to be certain nobody is going to come by and muck around with your class's API, make sure they can't knowingly make an instance of the class. One of the easiest ways to do this (and bear with me here, I'm…
ProjectXyz Alright, I'll admit it... Even for a placeholder name on a side project it's pretty terrible, right? Well, my apologies. So, if you made it to this post you might be wondering what ProjectXyz is and why I started it up. From a high level, I started working on ProjectXyz so that I could have a hobby programming project to tinker with and I figured I'd blog about my adventures in bringing it all together. I plan on making this a mini-series documenting some of the things I'm learning or experimenting with, so this will serve as the intro to the series. Before we get too far, here's the link to the GitHub site: https://github.com/ncosentino/ProjectXyz Why Have a Side Project? Here's the main thing I want to talk about in part 1 of this series: Why should you have a…
Refactoring: Some Background If you're a seasoned programmer you know all about refactoring. If you're relatively new to programming, you probably have heard of refactoring but don't have that much experience actually doing it. After all, it's easier to just rewrite things from scratch instead of trying to make a huge design change part way through, right? In any mature software project, it's often the case where you'll get to a point where your code base in its current state cannot properly sustain large changes going forward. It's not really anyone's fault--it's totally natural. It's impossible to plan absolutely everything that comes up, so it's probable that at some point at least part of your software project will face refactoring. In my real life example, I was tasked with refactoring a software project that has a single owner. I'm close…
Yield: A Little Background The yield keyword in C# is pretty cool. Being used within an iterator, yield lets a function return an item as well as control of execution to the caller and upon next iteration resume where it left off. Neat, right? MSDN documentation lists these limitations surrounding the use of the yield keyword: Unsafe blocks are not allowed. Parameters to the method, operator, or accessor cannot be ref or out. A yield return statement cannot be located anywhere inside a try-catch block. It can be located in a try block if the try block is followed by a finally block. A yield break statement may be located in a try block or a catch block but not a finally block. So what does this have to do with API specifications? A whole lot really, especially if you're dealing…
Background From an object oriented programming perspective, an application programming interface (API) is often referred to as the way other developers can interact with the public members of your class(es) and interface(s). Of course, API can be used to describe how one interacts with a web service (or other types of services), but for this discussion I'm limiting the scope to that of interfaces and classes. Limiting the definition of API to public members (or the equivalent of C#'s "public" in other languages) is omitting one huge part of what it encompasses. The purpose of this post is to clarify, in my opinion, why I think forgetting about the non-public API can lead to bad framework and API designs. API And The Audience I've written before about what I think makes a good API, and I had some comments on Code…
Background The very first thing I want to say is that I don’t think singletons are inherently bad–even if it means I am cast away from the rest of the programming world. There’s a time and a place for the singleton. It’s really common for people to get caught up with their perspective on something that they outright refuse to acknowledge the other side of it. I’d also like to point out that if you have a strong opinion on something and you find that other people also have a strongly opposing opinion on the same thing, there’s probably good take away points from either side. In this post though, I’m going to focus on why singletons are “bad”, because for me it means acknowledging one of the two main perspectives–that they are the best thing since cat videos met…