Singleton Design Pattern – How To Structure Your Singletons
Several examples in C# for how you can structure code to meet the singleton design pattern. Check it out before using singletons next!
0 Comments
July 24, 2013
Example: Getting Data Back From An EventHandler
Background I previously wrote about why I like to use events here and here. I figured it would be appropriate to illustrate a simple case where you can delegate decisions between functionally separate parts of code (say, between an application layer and a presentation layer). If you're well versed in C# and .NET, this might put you to sleep. If you have no idea what I'm talking about, hopefully this will help. By the end of this, hopefully you'll have a better idea for how you can use an EventHandler to pass data/state back through an invoked event... And don't forget to check out the code! The Scenario Let's assume we have a layered application, which is usually my go to. I might have three layers: one for data persistence, one for my business logic and one for interacting with…
July 23, 2013
Keep Your Fields Private
Background A recent discussion about this spurred a bit of a debate. Ever since I can remember, I've always been told to keep fields private. If you want to expose them any more than private you should use a property. Of course, I was defending my stance on this and figured I should see what other people were saying. I turned to the trusty Stack Overflow (SO) for some answers. Argument For: Control One of the major categories of arguments for keeping fields private has to do with control. Some great points brought up by SO posters included that properties allow you to easily add verification to your data storage. With a field inside of your class, your control is over how this variable is manipulated is constrained to the class. As soon as you expose something outside of the class,…
July 22, 2013
Quick Reading List – Weekly Article Dump – July 19th 2013
Here's a quick reading update for articles I've shared on social media over the past week. Topics include leadership, small business, and your career.
July 19, 2013
Potential Future Readings?
Based on this survey over at Code Project, I feel like I might have some reading to do. Let Us C: Seems to be at the top of people's lists. As the name implies, it's for the C programming language. My only concern is it might be too specific to C and not provide enough carry over to other languages. Definitely something I'll investigate. Code Complete: This book has amazing reviews. It looks to cover all the fundamental parts of programming, so this one might be top of my list. Java: How To Program: I actually wasn't overly impressed with the few reviews I read about this book. Especially after having it sized up against Code Complete. It might have to take the back burner for now. C++: How To Program: Even fewer useful reviews for this. Considering it's C++,…
July 18, 2013
Why Events? Decoupling.
Background Previously, I wrote about how events provide you with flexibility in your code. If you take on an event-based paradigm, you can view your system as a group of components that have events execute when certain conditions are met, and less of a procedural view where X always must occur after Y. But what else do events let us do? Decouple your architecture! We all know decoupling is a beautiful thing, so let's see how it's done. How Events Decouple Your Code So the big question then is, how? I'd like to start by providing framing an example architecture. If we assume that we have code that is decoupled by major functionality, we might have some sort of layered architecture. This could mean that we have three layers: presentation, application, and data. These layers would be responsible for…
July 17, 2013
Interfaces: Why You Should Be Using Them In Your Code
Leverage interfaces when creating an application to create a clean and robust API. Practice decoupling your code from concrete classes by using interfaces!
July 16, 2013
Why Events? Flexibility.
Before we talk about events... Let's consider that there are many different approaches to developing software. In my opinion, the opposite ends of the spectrum end up being: Knowing how the whole system looks, feels, and operates before coding a single line. Having an idea of what the user wants and coding to make it happen. Although I'm generalizing a lot here, it's sort of like the battle between Waterfall and Agile. Okay, great. So what am I rambling on about here? Well, in the first case, you know all the ins and outs of the system. You can structure your system so that almost no matter how complex it is, you can ensure that method A is always run immediately after method B which is etc... The design is completely controlled. You have a spec for how all the…
July 15, 2013
What Makes a Good API?
Background My position at work allows me a bit of freedom in how I code and more importantly, influence how others code. I was recently having a conversation with a colleague about what I think makes a good API, from a high level. The context of our discussion was pertaining to developing a C# based API, but this really applies to any object oriented API. I had two key points that I wanted to address, and while they're not the only important things, I believe they're often overlooked. The first thing is how people will use your API, so how they will call methods and use the results. The second point was about how people will implement your API should they want to extend your work and implement their own classes. Here's what I was trying to drive home: Usage: As a programmer,…
July 13, 2013
