Ok, I admit it
Ok, I admit it. I have been having those egocentric-trip-kinda sessions when I thought I was on the top of the berg. There was nothing more to learn than new APIs and some optimization tricks. Boy was I wrong.
For a long time I thought programmers world wide had to deal with structural difficulities without any real remedy. Classes were responsible for a wide range of ... well, responsibilities. Small changes to a design had full blown impact on the entire application. Somehow, I thought the only way to deal with it was to create an extensive design blueprint of the system beforehand, shortly after the application contracts were made, and then to discretely assume that no changes should be made to the contract. This is seldom how it works in practice. Even if the contractors have their mind set out for some purpose for the application, they might not understand what they really want until later, or make a comment on some functionality during their demo-run of the application. That something that really brings down the whole application for maintainance for several days, weeks.
I read an awesome book the other week. I wish I read it the first thing after I learned about the language structures. It was about software patterns (Head First - Design Patterns) and how to refactor your code following some simple OO guide lines. While the book doesn't solve all your problems (I wish it took care of my bills too), it certainly sends you off into another dimension if you're completely new of patterns and how to use them. The first chapter really opened my eyes wide open. It adressed problems I had been tormented with by simply favoring composition before inheritence. I think that was the one statement which set my mind wandering into this whole world of concepts and ideas. The first pattern introduced was the Strategy Pattern. So elegant, and so usable. So reusable.
I can't possibly sum up all the things you learn in that book, but I proudly and loudly say: I recommend it to every OO programmer!
The book is easy to read, packed with descriptive images and take on a new approach for learning. It's not one of those dull dense manuals with cryptic and fancy word picking, but rather an educative and sound book which puts you into the shoes of a developer facing a problem, or a range of problems. It lets you follow through developer discussions to allow several options to be presented and weighing them off each and another.
Today I am feeling fresher than ever. I am still having those egocentric-top of the world-god thingey feelings that happen from time to time, but I do so with respect that I know that still have alot to learn. I untapped a source of fresh material to dig into, and I keep searching the net for more resources every day to add on to my knowledge about architectural programming. Using and recognizing patterns in software development is a great feat which may allow your code to be more flexible, more maintainable and easy to use, both for yourself and other developers touching your code.
I think there is a problem with most text books and software teachers. Most of them teach you how to use inheritence and other mechanisms, but send the student off in a dark alley where she is facing every problem with an inhertience chain. While software text books often tells you how to write code, patterns tell you how to code! There's a distinct difference there I think, and it's worth noting.
Patterns are one thing, design principles' another. Still I think they are closely related. Patterns tend to make use of good design principles, and if you practice using them, you're going to make use of design principles without even noticing. Your brain gets rewired. Understanding what the design principles mean enforces your understanding in patterns. Understanding patterns gives you an arsenal of tools for common problems. Armed with a huge set of tools, you feel like you are GOD-top of the world-crazy. Nothing will stop you now.
Just be sure not to get pattern fever. Patterns are your tools, not the application you are building.