Got back on the Book-reading bandwagon the past few days, this time with a technical slant:
Pattern Hatching: Design Patterns Applied
This book is sort of a meta-meta-patterns book, that is it's a book about a book about patterns. You see, computer software is a science of building abstractions; at the lowest level, computers execute a series of instructions, one after another, at blazing speed. If you group these instructions together from start to finish with one purpose, you have an algorithm. If you factor-out common parts of several agorithms, you have subroutines, functions, or procedures. At this point, you're two "levels of abstraction" away from the way the computer actually works.
The human brain can only hold so much information, and for a programmer to write a program, he needs to keep a significant amount of the program in his head at one time. So, like physicists or cosmologists trying to understand the universe, we must develop more and more elaborate metaphors for the actual subject matter at hand.
The great revolution in metaphors after the subroutines and functions were Objects, giving rise to the term Object-Oriented Programming. Objects combine data and the procedures that operate upon it such that the programmer can dispense with writing bare arrays, maps, and functions and deal with bigger building blocks like "Car", "Plane", "Guidance system". Object Orientation is wonderful, because it lets you deal with a whole system without overloading your poor little brain. However, we're getting pretty high up the ladder of abstraction (now at level 3 or more), so it requires a bit more finesse than regular procedure calls and algorithms. You have to get your mind to think in a different way than you learned programming Pascal back at college.
Enter Design Patterns. As people amassed a decade or more of Object-Oriented programming, they began to notice patterns emerge in the way they put objects together. When solving a similar problem, they found they could apply prior structures of objects. This is like other forms of engineering or craftsmanship: Eventually, you learn to make jigs and forms so that your work is repeatable. So, Design patterns are level 4.
The Design Patterns book came-about in 1994, and now 10 years later, one of the original authors writes this book about how to apply the patterns, some of the pitfalls thereof, and the thought processes of high-level systems designers. The book is a quick, easy read, and I'd highly recommend it for someone like me who's been using patterns for years and who'd appreciate an even more in-depth discussion of nuances of them. Still, it's helpful to have the original Design Patterns for reference.
Pattern Hatching: Design Patterns Applied
This book is sort of a meta-meta-patterns book, that is it's a book about a book about patterns. You see, computer software is a science of building abstractions; at the lowest level, computers execute a series of instructions, one after another, at blazing speed. If you group these instructions together from start to finish with one purpose, you have an algorithm. If you factor-out common parts of several agorithms, you have subroutines, functions, or procedures. At this point, you're two "levels of abstraction" away from the way the computer actually works.
The human brain can only hold so much information, and for a programmer to write a program, he needs to keep a significant amount of the program in his head at one time. So, like physicists or cosmologists trying to understand the universe, we must develop more and more elaborate metaphors for the actual subject matter at hand.
The great revolution in metaphors after the subroutines and functions were Objects, giving rise to the term Object-Oriented Programming. Objects combine data and the procedures that operate upon it such that the programmer can dispense with writing bare arrays, maps, and functions and deal with bigger building blocks like "Car", "Plane", "Guidance system". Object Orientation is wonderful, because it lets you deal with a whole system without overloading your poor little brain. However, we're getting pretty high up the ladder of abstraction (now at level 3 or more), so it requires a bit more finesse than regular procedure calls and algorithms. You have to get your mind to think in a different way than you learned programming Pascal back at college.
Enter Design Patterns. As people amassed a decade or more of Object-Oriented programming, they began to notice patterns emerge in the way they put objects together. When solving a similar problem, they found they could apply prior structures of objects. This is like other forms of engineering or craftsmanship: Eventually, you learn to make jigs and forms so that your work is repeatable. So, Design patterns are level 4.
The Design Patterns book came-about in 1994, and now 10 years later, one of the original authors writes this book about how to apply the patterns, some of the pitfalls thereof, and the thought processes of high-level systems designers. The book is a quick, easy read, and I'd highly recommend it for someone like me who's been using patterns for years and who'd appreciate an even more in-depth discussion of nuances of them. Still, it's helpful to have the original Design Patterns for reference.
Comments
Post a Comment