This week, we leave Fowler’s Refactoring behind in favor of embarking on a journey exploring design patterns. As I understand it, when writing code, there are certain ways of structuring a program or application as a whole that are patterns on which we can base the design of code.
This is a topic that has come up before in my studies, but as I move forward writing my first object-oriented Ruby script, I’m understanding more about structure which I think makes the patterns more applicable.
For this week, we read the introduction to Design Patterns: Elements of Reusable Object-Oriented Software. Much denser than my experience with refactoring — this material took quite a long time to parse, and I have one of my longer question/discussion lists that came out of it.
I learned that problems I have with determining how much of my code to expose to a user are common to lots of applications with a public interface and private methods, and that there are different categories of design patterns to handle different use cases.
I was glad to see that each pattern is broken up by what the problem is where one might use it, how it might help and what the consequences are. Something I’m learning about all these new best practices I’m picking up is that there are tradeoffs, and not the ones I expected. In the past, I looked at time and getting to something on the screen as above all else, but I’m learning it is often better to do it right, and invest some time in the long-term work. Likewise, various solutions may make your code clearer, but longer. With testing, you are in some cases writing almost twice the code you might otherwise. I could go on. But the point is, every decision has positive and negative aspects, and those are worth considering.
The chapter talked a fair amount about tight coupling, that is, tying together bits of code, and how that can affect reusability. That’s reusability in terms of making changes to modify the current project, as well as modularizing it and using a similar system in a slightly different context. As I start to use OOP, I’ve noticed that things are starting to seem more tightly related than I’d like, so I know that is something to watch out for.
I have a lot of vocab questions, but a lot made sense that wouldn’t have a month ago, and thankfully, there are smart people around me I can ask those questions of. I like that I’m being challenged, and I take pleasure in the fact that there can be a structure to organizing code outside of a framework. This seems like a good next logical step, and this introduction laid the groundwork nicely for where I’m trying to head.