Rediscovering OOP
I remember writing Java Battleship in my freshman year of college. You know, it was your first big programming project that everyone has. That first project that you want to set yourself above everyone else in class. Simply coloring squares in a grid? Not for me sir, we are talking actual ovals with holes for the pegs. How about we go one step further and add a simple AI opponent? It's something I'm still proud of to this day, but not when I look at the code--
One thing I really thought was awesome, in the Computer Science program I graduated out of, was that our curriculum included not one, but two semesters of patterns in software development. When I came into my first job, that's all I could speak in-- command this, filter that, use the bridge pattern here, and pass a memento over there. Wow, my first job out of college and I was lucky enough to be the 'lead' designer on their next enterprise application. I went wild with patterns, everything in it's own layer which delegated to the next through a series of half a dozen interfaces. What a beautiful mess.
I thought patterns made my code the cleanest it could possibly be. The best part is that other new programmers to the project would follow the same patterns that I laid out before them; adding even more useless implementations to the application.
About 6 month later, I discovered AOP. What if I had gotten my hands on AOP when I started my last project? How easy would it have been to model customer and account relations? How easy would it have been to manage transactions on this method or that method? So I started investigating its ability to model what we were doing at work-- even started implementing some foundation components that were geared for use with AOP. I came back to my managers and coworkers with some examples and AOP articles I've read-- and this is where I hit a brick wall. "Who's going to maintain that? I don't understand pointcuts, can't we just do it this way?" I felt discouraged by the response I had gotten from others and tried to find some way to argue that we needed to adapt to the future, which I believed was AOP.
I started looking for methodologies like Agile development that would encourage new development with AOP. Consequently, I picked up a copy of Agile Software Development by Robert C. Martin. I know that Agile development promotes quick development and lighter code and documentation, it all sounds so good. Maybe this book would have the ammo I need to bring back to my department in order to encourage AOP? Starting from chapter one, it described the processes we should be doing in software development, the steps in managing the code we wrote. But, then I continued on into the chapters on object oriented principals and found myself second guessing every program I've written before. This wasn't the way I've modeled objects before! Single Responsibility, the Liskov Substitution Principle, compositional objects and delegation? As I read, I started to put things together in my mind, the same as I had done while reading about AOP. If I would have simply followed these few principals in the first place, maybe our application wouldn't have been so difficult to model in OO?
If I would have used the Single responsibility Principle here in the first place and delegated here, I wouldn't have all these other concerns to maintain in AOP. I'm not saying that I found the 'meaning of OOP', but pretty damn close. I backtracked through my other patterns books and bookmarked articles with a much higher degree of understanding at what we were trying to accomplish. I found some programmer's writings to be misdirected, while strengthening my opinion of others.
In a sense, I feel as though I missed out on something when I initially learned OOP (probably a fault of my own). I don't feel the strong need to seek out frameworks or patterns to do X or Y, I'm going back to basics-- good citizen principles, contracts, object inheritance, composition, delegation, etc. My code becomes unbelievable intrinsic and light, I'm no longer seeking patterns and frameworks as solutions but now realizing the solutions inherent to the language itself. "Keep it simple stupid," I said, and boy was I stupid.
One thing I really thought was awesome, in the Computer Science program I graduated out of, was that our curriculum included not one, but two semesters of patterns in software development. When I came into my first job, that's all I could speak in-- command this, filter that, use the bridge pattern here, and pass a memento over there. Wow, my first job out of college and I was lucky enough to be the 'lead' designer on their next enterprise application. I went wild with patterns, everything in it's own layer which delegated to the next through a series of half a dozen interfaces. What a beautiful mess.
I thought patterns made my code the cleanest it could possibly be. The best part is that other new programmers to the project would follow the same patterns that I laid out before them; adding even more useless implementations to the application.
About 6 month later, I discovered AOP. What if I had gotten my hands on AOP when I started my last project? How easy would it have been to model customer and account relations? How easy would it have been to manage transactions on this method or that method? So I started investigating its ability to model what we were doing at work-- even started implementing some foundation components that were geared for use with AOP. I came back to my managers and coworkers with some examples and AOP articles I've read-- and this is where I hit a brick wall. "Who's going to maintain that? I don't understand pointcuts, can't we just do it this way?" I felt discouraged by the response I had gotten from others and tried to find some way to argue that we needed to adapt to the future, which I believed was AOP.
I started looking for methodologies like Agile development that would encourage new development with AOP. Consequently, I picked up a copy of Agile Software Development by Robert C. Martin. I know that Agile development promotes quick development and lighter code and documentation, it all sounds so good. Maybe this book would have the ammo I need to bring back to my department in order to encourage AOP? Starting from chapter one, it described the processes we should be doing in software development, the steps in managing the code we wrote. But, then I continued on into the chapters on object oriented principals and found myself second guessing every program I've written before. This wasn't the way I've modeled objects before! Single Responsibility, the Liskov Substitution Principle, compositional objects and delegation? As I read, I started to put things together in my mind, the same as I had done while reading about AOP. If I would have simply followed these few principals in the first place, maybe our application wouldn't have been so difficult to model in OO?
If I would have used the Single responsibility Principle here in the first place and delegated here, I wouldn't have all these other concerns to maintain in AOP. I'm not saying that I found the 'meaning of OOP', but pretty damn close. I backtracked through my other patterns books and bookmarked articles with a much higher degree of understanding at what we were trying to accomplish. I found some programmer's writings to be misdirected, while strengthening my opinion of others.
In a sense, I feel as though I missed out on something when I initially learned OOP (probably a fault of my own). I don't feel the strong need to seek out frameworks or patterns to do X or Y, I'm going back to basics-- good citizen principles, contracts, object inheritance, composition, delegation, etc. My code becomes unbelievable intrinsic and light, I'm no longer seeking patterns and frameworks as solutions but now realizing the solutions inherent to the language itself. "Keep it simple stupid," I said, and boy was I stupid.
posted by Jacob Hookom at
10:07 AM
2 Comments:
This is funny because you had interviewed me once and schooled me on not knowing design patterns, so I didn't get the job because I wasn't experienced.
So I went and learned some design patterns. I've been ruined!
By
Anonymous, at 8:35 AM
heh, don't get me wrong, they are a great communication tool, but when your business model doesn't read like the business and instead like a series of pattern, then you are in trouble. i guess the best way to describe the development methodology is instead of starting with patterns of abstraction, start with the simplest solution, using agile methods, which end up leading to easy refactoring into more abstract pattern models later as the need to maintain or accommodate change grows.
By
Jacob Hookom, at 10:26 PM
Post a Comment
<< Home