This is a good topic. Sometimes I think of OOP as if the objects are descriptors and the behaviors are events. Or even in terms of nouns and verbs (actor-action). It gets a little murky when you don't apply the concept in terms of creating an app. For example using a js library like Angular, creating components that rely on import/export and so forth. Then it really becomes clear because the use case demonstrates what the benefits of OOP really are. What do you think?
That's pretty interesting since you are highlighting the multifaceted aspect of OOP: it can be used in a lot of way (and I only showed the basics ones), but oftentimes libraries and frameworks are kind of enforcing a specific one. I think it's a good thing to do when creating a library/framework since handling all the possible use cases is impossible, and it's also a benefit when you are using the library/framework since it's guiding your thoughts to create uniformised code.
This is a good topic. Sometimes I think of OOP as if the objects are descriptors and the behaviors are events. Or even in terms of nouns and verbs (actor-action). It gets a little murky when you don't apply the concept in terms of creating an app. For example using a js library like Angular, creating components that rely on import/export and so forth. Then it really becomes clear because the use case demonstrates what the benefits of OOP really are. What do you think?
That's pretty interesting since you are highlighting the multifaceted aspect of OOP: it can be used in a lot of way (and I only showed the basics ones), but oftentimes libraries and frameworks are kind of enforcing a specific one. I think it's a good thing to do when creating a library/framework since handling all the possible use cases is impossible, and it's also a benefit when you are using the library/framework since it's guiding your thoughts to create uniformised code.
You are right. Well said!