What Makes Good Code? – Should Every Class Have An Interface? Pt 1

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…

5 Comments

Should My Method Do This? Should My Class?

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.…

0 Comments

ProjectXyz: Enforcing Interfaces (Part 2)

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…

2 Comments

ProjectXyz: Why I Started a Side Project (Part 1)

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…

3 Comments

Dependency Injected Singletons… What?

Background Previously I wrote a bit about singletons. I'm not afraid to say that I think singletons have a time and a place... Okay, I'm afraid to say it, but it's actually how I feel :) After learning more and more about inversion of control design patterns and programming by interfaces, I started to notice just how inflexible singletons are. When you consider using a singleton, you should be considering both the pros and cons without jumping right into it. Here's an example of my approach for mixing singletons, programming by interfaces, and a bit of inversion of control. The Setup I'm actually surprised you got this far. I'm sure you're probably just sticking around to see how messed up this could possibly be. I'm actually proud that this little pattern has worked out so well when I've used it,…

0 Comments

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…

0 Comments

Interfaces: Why You Should Be Using Them In Your Code

Background As a developer, there's often a point when you're tasked to build something that's a key part of the architecture of your software. Maybe it's not a key component to the all of the application, but it's pretty foundational at least for a part of the application. Often we put our thinking caps on, plan a bit of what we're about to code, and then dive right into it. If you do TDD, you might go start coding your tests but regardless of your approach, you're likely going to start coding some classes pretty soon and forget completely about the use of an interface. You shouldn't.   Start With Interfaces In my opinion, if you're writing code that's part of your application's foundation, you should start with interfaces. If you're already rolling your eyes and whining to yourself that…

0 Comments

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,…

3 Comments

End of content

No more pages to load