I don't know if this took the longest for me to grasp, but it took a certain example. Way back in the 1990s when I was first learning object-oriented programming, it was hard for me to get a grasp of what an object really was. Every explanation of OO programming made objects out to be these things with almost mystical properties.
It was only when I encountered Perl's LWP module, which uses an object as an "agent" to make web requests, that I realized that an object could, in fact, be anything.
Any grouping of behaviors that arbitrarily decide are being done by "the same thing", hey, you're perfectly free to declare that's an object. It's all up to you.
The problems with all the previous explanations I encountered is that they all conflated what an object should be (in terms of sensible code organization) with what an object could be (in terms of language structure, which is to say, no limits).
I still think it would be great, when introducing OO, to show examples of silly decisions of how to break a problem up into objects, just to make this arbitrariness perfectly clear, and open the door to creative thinking about what objects could be.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't know if this took the longest for me to grasp, but it took a certain example. Way back in the 1990s when I was first learning object-oriented programming, it was hard for me to get a grasp of what an object really was. Every explanation of OO programming made objects out to be these things with almost mystical properties.
It was only when I encountered Perl's LWP module, which uses an object as an "agent" to make web requests, that I realized that an object could, in fact, be anything.
Any grouping of behaviors that arbitrarily decide are being done by "the same thing", hey, you're perfectly free to declare that's an object. It's all up to you.
The problems with all the previous explanations I encountered is that they all conflated what an object should be (in terms of sensible code organization) with what an object could be (in terms of language structure, which is to say, no limits).
I still think it would be great, when introducing OO, to show examples of silly decisions of how to break a problem up into objects, just to make this arbitrariness perfectly clear, and open the door to creative thinking about what objects could be.