Content related to programming, coding, and software development. Check out tutorials and examples!
Python & C# - Background Let's clear the air. Using Python and C# together isn't anything new. If you've used one of these languages and at least heard of the other, then you've probably heard of IronPython. IronPython lets you use both C# and Python together. Pretty legit. If you haven't tried it out yet, hopefully your brain is starting to whir and fizzle thinking about the possibilities. My development experiences is primarily in C# and before that it was VB .NET (So I'm pretty attached to the whole .NET framework... We're basically best friends at this point). However, pretty early in my career (my first co-op at Engenuity Corporation, really) I was introduced to Python. I had never really used a dynamic or implicitly typed language, so it was quite an adventure and learning experience. Unfortunately, aside from my…
Background If you've poked through my previous postings, you'll probably notice that I love using events when I program. If I can find a reason to use an event, I probably will. I think they're a great tool that can really help you with designing your architectures, but there are certainly some common problems people run into when they use events. The one I want to address today has to do with memory leaks. That's right. I said it. Memory leaks in your .NET application. Just because it's a managed language doesn't mean your code can't be leaking memory! And now that I've got your attention, let's see how events might be causing some leakage in your application. (There is source that you can download and run. Check the summary section at the end!) Instance-Scope Event Handlers One of the…
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…
Everyone always says singletons are bad, but I don't think they are inherently evil. What are some of the major issues with singletons?
Background I’m sure what I’m about to talk about here doesn’t just relate to programming–it relates to any team-based project where everyone works on a small portion of the big picture. My experiences are primarily geared toward writing code in teams, so try to find parallels in your own work/experiences if you’re not a programmer. Anyway, enough of that. When someone puts a lot of effort into something, they’ll often take great pride in the finished product. Of course, it’s great that they do! They’ve slaved away at something at work for days, weeks, or months, and it’s finally working/implemented. Other people are using it and it’s doing its job as expected. Awesome! What kinds of things could possibly go sour here? If you have experience working in teams to complete a project, you might have some ideas. Ownership You…
An example in C# about how to create a singleton with support for dependency injection or inversion of control (IOC).
BackgroundI've previously discussed the differences between the BackgroundWorker and Thread classes, but I figured it would be useful to touch on some code. I'd like to share the pattern I commonly use when creating threads in C# and discuss some of the highlights.The Single ThreadI like to use this design when I have a single thread I need to run and in the context of my object responsible for running the thread, I do mean having a single thread. Of course, you could have your object in control of multiple threads as long as you repeat this design pattern for each of them.Here's the interface that I'll be using for all of the examples: internal interface IThreadRunner { #region Exposed Members void Start(); void Stop(); #endregion }Behold! internal class SingleThreadRunner : IThreadRunner { #region Fields private readonly object _threadLock; private…
Background There are two classes available in the .NET framework that sometimes have some confusion around them: The Thread and the BackgroundWorker. They're both used to do some heavy lifting for you on a separate thread of execution (so you can keep on keepin' on), so why do we have two different things to accomplish the same end result Enter The Thread Class The Thread class is available in the System.Threading namespace. Surprising, right? It's the basic unit for spawning off work to be done. Threads let you provide them with a name, which could be one advantage to using them. A thread can either operate as "background" which means it will be killed when the application exists, or not as background, which will actually keep the application alive until the thread is killed off. An instance of the…
Background This probably sounds really nit-picky or OCD, but I think it's an issue worth addressing. Excessive nesting of logic within code can make things nightmarish to read. Even a few of years ago I never thought anything of this. I mean, how much could it really affect someone reading it? He/she must be a complete newb to not be able to read my logic. Fast forward to a co-op placement where this was more closely moderated by my managers, and I began to pay more attention to it... Why? Alright, so all that you know so far about my opinion on this is that excessive nesting bothers me. So far, my mission is accomplished. Everything else is just extra. The first issue with excessive nesting is that it actually makes logic hard to follow. If you're doing code reviews…
Several examples in C# for how you can structure code to meet the singleton design pattern. Check it out before using singletons next!
