« « Refactoring: Real world benefits of soaking it in

JavaScript Patterns – Chapters 1 and 2 » »

An introduction to design patterns — trying again

Posted by on Jul 16, 2014 in Blog | No Comments

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 think it’s interesting to note that design patterns occupy the middle ground between figuring out custom solutions to coding problems with no structure, and using a framework like Rails, which lays out your app. I think this will be especially useful when working on complex JavaScript systems, as I often do, where I’m not really sure how to organize how big functions relate to each other. Some of this is addressed as part of refactoring, but there’s a bigger piece, which I think is covered well here.

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.

Patterns can also be used to help you figure out what you want to protect, and what you want to allow other users to use/modify. I’ve done this in JavaScript before, but sticking mainly to one particular pattern, so I really like the idea of branching out. I also would like to better understand the reasons why I use that pattern over another one.

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.

« « Refactoring: Real world benefits of soaking it in

JavaScript Patterns – Chapters 1 and 2 » »