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

0 Comments

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

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

Why Events? Flexibility.

Background There are many different approaches to developing software, but 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 components work together. The problem? Well,…

1 Comment

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