What’s Going on Here?
Object-oriented programming concepts are almost universally problematic for new programmers (including myself). It’s easy enough to find information about these concepts, but my understanding of them always feels incomplete. If you search the Internet you’ll find lots of guidelines to correctly structure and write object-oriented code. There are also various concepts that are important to understand like abstraction, and encapsulation, etc. You’ve probably heard them all by now. If you haven’t heard of these concepts, then get a book on object-oriented programming. My goal is not to explain what’s already been explained elsewhere in great detail. My goal is to try to offer my perspectives on what I learn in order to help programmers on the same path avoid long periods of confusion and frustration. One of the things I hope to do here is analyze my own projects and show why I make specific design choices, what concepts and guidelines do I consider when making my choices, and what my alternative choices are and why I didn’t choose them.
Some guidelines that are particularly prevalent are the “SOLID principles”. It’s likely that you’ve heard of SOLID, as it’s indiscriminately tossed (like a hot potato) to new programmers when they have questions about good object-oriented practices. However, SOLID is not a technique, it’s a goal. You achieve the goal by using good object-oriented analysis and design techniques that are, regrettably, often not explained in conjunction with SOLID. Explaining SOLID without explaining the techniques, is like explaining electricity by turning on a light. The problem with SOLID and other neatly-packaged guidelines is that they give you the illusion that you’ve learned something. They leave novice programmers with a goal and no map or means to achieve it, or worse, they give novices misappropriated confidence. I have frustratingly experienced both.
I’d dislike it if readers of this blog believe they have an answer to anything. I’d prefer it if readers find new questions to ask, and hopefully desire to learn more from someone who actually knows what they’re talking about (I’m suggesting you accept what I write as another perspective, but you should read books written by smart people).
If we don’t know which questions to ask, we’ll never get the answers we’re looking for. Answers, however, always come with new questions. It’s a side effect; the nature of the beast (it’s anything in life, really). Designing and implementing software is a continuously reflective process, and we should always be asking questions about our goals, design choices, implementation choices, and our own knowledge so that we may continue to learn.