My Struggles in Object Oriented Programming

Object Oriented Programming is a paradigm. If you don't like the corporate-speak of the first statement, then consider it a framework, or way of thinking. I was not formally trained in programming, and therefore, object oriented programming has always been a challenge for me to understand. In college (circa 1999-2003), I learned about several programming languages, like C, Visual Basic, and Java; but because I was not a programming major, the concept of object oriented design alluded me. I worked entirely within the procedural oriented programming paradigm, which is basically just a bunch of functions, interacting together, to solve a problem: brute force.

As time has gone by, I've realized that I love programming. I don't just love the mechanism of writing methods/functions to solve a problem. I love solving problems in a way that is reusable, eloquent, and highly valuable.

My first interactions with any sort of object oriented design came with PHP. Now, don't get me wrong; PHP is not truly object oriented, but it's pretty close, and the PHP-hardcores out there design with object oriented concepts in mind.

I programmed for years in PHP, occassionaly encountering concepts in OOP, but remained consistent in my procedural oriented programming paradigm. Then one day, I decided I'd "learn" C#. It was all over.

C# is entirely object oriented, and it's quite difficult to design quality applications without understanding OOP.

Along the way, I've come to realize that the tools that I gained in college allow me to solve problems in a brute force fashion, but there are better tools available these days for almost any problem I'm trying to solve.

The purpose of this blog is to share the tools and concepts I've found in the effort to help people like me, who are total computer nerds, but are not the super genius type who do this sort of stuff in their sleep.