PART 11: Object Trek: The Search for OOP
"A Brief History of Code", by Rudedog Hawkins
PART 11: Object Trek: The Search for OOP
In the early 1990s, a group of four software developers got the bright idea that they alone could figure out a working theory about how to apply these object concepts in some sort of structured way. Their efforts to develop a theory did not meet with immediate success, which was no big surprise. They were a David trying to slay a Goliath, which they could not see. Many experts had no doubt approached this problem over the previous 30+ years, including the very same people who had first conceptualized them.
Their initial mistake and major stumbling block was looking for some sort of definable structure where in fact there was none to be found, at least not of the sort they had sought. But early on, they did make one crucial realization as to how to fit it all together. “Keep It Simple, Stupid.” When they could not find any structure or methodology, they kept true to that mantra. They decided to go back to the roots of how software objects began, which meant imitating life, imitating the human brain. Once again, they began to look for patterns; trying to define and impose what they figured would evolve from an arbitrary structure to into a coherent one. It still didn’t quite fit. It still looked like leftover hash, without any rhyme or reason.
And so, they began to look for ideas outside of the computer industry. This was not an act of desperation, but rather what some would call almost divine inspiration. There are many branches of arts and sciences that are seemingly unconnected with one another. One thing that binds these disciplines together is the mathematics. In many cases, the identical mathematics even crosses into other disciplines. For example, the same formula that calculates interest on a bank deposit is also used to calculate population growth of bacteria in a Petri dish. It didn’t take long before their search bore fruit.
Legend has it they were sitting in a bar looking over a book about Modular Architecture Design and Construction, and became fascinated with the concepts. They initially loved the abstraction of it all. The proverbial light bulb was lit. Imagine the toy blocks called Lego’s. Most any toy block can fit and work with most any other piece. Why? It works because each piece of Lego’s has a standardized interface for interlocking with other Lego’s.
Of course the book was far more sophisticated than Lego’s, but the ideas for their legendary book that came a short time later were born. Building modules could be made so that they contained sub-modules, sub-modules that served one or more purposes. They realized that what an object was made of could be far more useful than what it was made from. They discovered that how an object was designed could hold greater significance over how it was made. In OOP terminology, this mindset is phrased like the following.
“Favor composition over inheritance.”
In Lego’s terms you could look at it this way. You could snap any two pieces together to form a greater whole that still conformed to the original design description. That sounds like reusable code. There was no requirement that you had to connect a blue piece to only another blue piece. That sounds like polymorphism. You really were not even required to use two pieces of the same material. As long as the two pieces met a certain shape and size specification, they could work together. That sounds like abstract type descriptions.
The more complex architectural elements had additional components that defined the way that elements interacted. They drew parallels to most of the major Object Oriented concepts known at that time. They saw Polymorphism, Inheritance, Classes and Typing, and even methods and message passing.
The modular architectural concepts could have been categorized into categories that represented Structural, Creational, and Behavioral traits. There were some elements that formed that support and structure of the final building. Factories existed to create the custom modular elements based upon a set of specifications. Once elements left the factory, they could have their uses significantly modified before or after installation, thereby entirely altering the behavior of an element.
The parallels to Object Programming were undeniable. Their final book had also laid out the groundwork for some rules of use of the modular elements based upon certain design objectives. The brainstorm was set, in motion, and a short time later their landmark book was released, “Design Patterns: Elements of Reusable Object-Oriented Software”.
The book's authors were Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch. The authors are often referred to as the Gang of Four, or GoF, for short. The book provides code examples of 23 basic Design Patterns, and lays out some ground rules and goals on how Object-Oriented software should be written. They defined the OOP mindset.
Unless you are a collector, a purist, a C programmer, or someone who just simply likes torture, I would not recommend the book to any new developer. It was originally targeted at the highly experienced C programmer, and remains so to this day. As it was written nearly 20 years prior to this writing, many will find the examples to be quite outdated. There are many contemporary texts that use code examples in the .NET languages in common use today, particularly C#.
Now that a set of ground rules and design philosophy were laid out, converts from Procedure-Driven code were jumping onto the bandwagon like it was a new religion. Object-Oriented Programming is widely used today, but still misunderstood by many. It has created a new rivalry in some circles.
Procedure-Driven code has not faded in the least. Many databases in wide use today are relational databases, which were designed during the golden era of computer growth long before OOP became anything more than a curios piece of software abstraction. In fact, it is making a comeback under the guise of structural programming. Some say that the future of programming just might be that type of structure.
Rudy =8^D
PART 11: Object Trek: The Search for OOP
In the early 1990s, a group of four software developers got the bright idea that they alone could figure out a working theory about how to apply these object concepts in some sort of structured way. Their efforts to develop a theory did not meet with immediate success, which was no big surprise. They were a David trying to slay a Goliath, which they could not see. Many experts had no doubt approached this problem over the previous 30+ years, including the very same people who had first conceptualized them.
Their initial mistake and major stumbling block was looking for some sort of definable structure where in fact there was none to be found, at least not of the sort they had sought. But early on, they did make one crucial realization as to how to fit it all together. “Keep It Simple, Stupid.” When they could not find any structure or methodology, they kept true to that mantra. They decided to go back to the roots of how software objects began, which meant imitating life, imitating the human brain. Once again, they began to look for patterns; trying to define and impose what they figured would evolve from an arbitrary structure to into a coherent one. It still didn’t quite fit. It still looked like leftover hash, without any rhyme or reason.
And so, they began to look for ideas outside of the computer industry. This was not an act of desperation, but rather what some would call almost divine inspiration. There are many branches of arts and sciences that are seemingly unconnected with one another. One thing that binds these disciplines together is the mathematics. In many cases, the identical mathematics even crosses into other disciplines. For example, the same formula that calculates interest on a bank deposit is also used to calculate population growth of bacteria in a Petri dish. It didn’t take long before their search bore fruit.
Legend has it they were sitting in a bar looking over a book about Modular Architecture Design and Construction, and became fascinated with the concepts. They initially loved the abstraction of it all. The proverbial light bulb was lit. Imagine the toy blocks called Lego’s. Most any toy block can fit and work with most any other piece. Why? It works because each piece of Lego’s has a standardized interface for interlocking with other Lego’s.
Of course the book was far more sophisticated than Lego’s, but the ideas for their legendary book that came a short time later were born. Building modules could be made so that they contained sub-modules, sub-modules that served one or more purposes. They realized that what an object was made of could be far more useful than what it was made from. They discovered that how an object was designed could hold greater significance over how it was made. In OOP terminology, this mindset is phrased like the following.
“Favor composition over inheritance.”
In Lego’s terms you could look at it this way. You could snap any two pieces together to form a greater whole that still conformed to the original design description. That sounds like reusable code. There was no requirement that you had to connect a blue piece to only another blue piece. That sounds like polymorphism. You really were not even required to use two pieces of the same material. As long as the two pieces met a certain shape and size specification, they could work together. That sounds like abstract type descriptions.
The more complex architectural elements had additional components that defined the way that elements interacted. They drew parallels to most of the major Object Oriented concepts known at that time. They saw Polymorphism, Inheritance, Classes and Typing, and even methods and message passing.
The modular architectural concepts could have been categorized into categories that represented Structural, Creational, and Behavioral traits. There were some elements that formed that support and structure of the final building. Factories existed to create the custom modular elements based upon a set of specifications. Once elements left the factory, they could have their uses significantly modified before or after installation, thereby entirely altering the behavior of an element.
The parallels to Object Programming were undeniable. Their final book had also laid out the groundwork for some rules of use of the modular elements based upon certain design objectives. The brainstorm was set, in motion, and a short time later their landmark book was released, “Design Patterns: Elements of Reusable Object-Oriented Software”.
The book's authors were Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch. The authors are often referred to as the Gang of Four, or GoF, for short. The book provides code examples of 23 basic Design Patterns, and lays out some ground rules and goals on how Object-Oriented software should be written. They defined the OOP mindset.
Unless you are a collector, a purist, a C programmer, or someone who just simply likes torture, I would not recommend the book to any new developer. It was originally targeted at the highly experienced C programmer, and remains so to this day. As it was written nearly 20 years prior to this writing, many will find the examples to be quite outdated. There are many contemporary texts that use code examples in the .NET languages in common use today, particularly C#.
Now that a set of ground rules and design philosophy were laid out, converts from Procedure-Driven code were jumping onto the bandwagon like it was a new religion. Object-Oriented Programming is widely used today, but still misunderstood by many. It has created a new rivalry in some circles.
Procedure-Driven code has not faded in the least. Many databases in wide use today are relational databases, which were designed during the golden era of computer growth long before OOP became anything more than a curios piece of software abstraction. In fact, it is making a comeback under the guise of structural programming. Some say that the future of programming just might be that type of structure.
Rudy =8^D
Interesting blog. I will continue to follow it.
ReplyDelete