OOP as if you meant it
Learn how messaging makes your object-oriented code easier to read and maintain.
Have you ever heard, objects are communicating by messages? I had heard this a long time ago - and never have been able to make sense of it. But why bother? Just calling functions on objects gets the job done, doesn't it. That's how I programmed until a couple of years ago, at least. However my dismay was growing every day. I found it hard to derive classes/objects from requirements. And despite all my best OO-intentions peppered with Clean Code principles my code was hard to read.
So I started to think about whether this was all my fault, and how to try harder to become a good OO-programmer. But then I realized: This wasn't just my problem. Almost every developer I met suffered from the same symptoms. So maybe the true cause of this wasn't our collective dumbness. Maybe the true cause lay in the paradigm.
And that's what I'm believing today. Mainstream object-orientation is more of a problem than a solution, because it's lacking an essential, no, the essential aspect of object-orientation how its inventor Alan Kay meant it to be. This essential aspect is messaging. Yes, the way of how objects are communicating makes a big difference. And glossing this over by just saying "it's like calling a function" has done great harm.
In this little book I´m trying to show you what I think, messaging means and how object-orientation was intended to be.
I'd be happy if you gave messaging a second chance. I'm sure you'll reap benefits from putting it back into the center of your object-oriented programming practice. Your code will become easier to write, read, and change, since it will more closely resemble the requirements and your solution strategy.
Learn how messaging makes your object-oriented code easier to read and maintain.
Have you ever heard, objects are communicating by messages? I had heard this a long time ago - and never have been able to make sense of it. But why bother? Just calling functions on objects gets the job done, doesn't it. That's how I programmed until a couple of years ago, at least. However my dismay was growing every day. I found it hard to derive classes/objects from requirements. And despite all my best OO-intentions peppered with Clean Code principles my code was hard to read.
So I started to think about whether this was all my fault, and how to try harder to become a good OO-programmer. But then I realized: This wasn't just my problem. Almost every developer I met suffered from the same symptoms. So maybe the true cause of this wasn't our collective dumbness. Maybe the true cause lay in the paradigm.
And that's what I'm believing today. Mainstream object-orientation is more of a problem than a solution, because it's lacking an essential, no, the essential aspect of object-orientation how its inventor Alan Kay meant it to be. This essential aspect is messaging. Yes, the way of how objects are communicating makes a big difference. And glossing this over by just saying "it's like calling a function" has done great harm.
In this little book I´m trying to show you what I think, messaging means and how object-orientation was intended to be.
I'd be happy if you gave messaging a second chance. I'm sure you'll reap benefits from putting it back into the center of your object-oriented programming practice. Your code will become easier to write, read, and change, since it will more closely resemble the requirements and your solution strategy.
