One thing that is often missed when considering objects is that they don't have to contain code.
Objects contribute to "strong typing" which reduces bugs and makes them easier to find, and "data objects" (objects without code, designed solely to store data) can extend this to a much lower level inside your code.
Simple code additions can also help with hold the data in a strict format whilst formatting it in different ways for different uses.
And by making classes readonly you can implement immutability which can also reduce bugs.
Finally, use of "final" should be discussed as a way to distinguish between polymorphism base-classes which can be extended (e.g. animal, mammal) , and end-classes which can't (e.g. Tabby Domestic Cat).
One thing that is often missed when considering objects is that they don't have to contain code.
Objects contribute to "strong typing" which reduces bugs and makes them easier to find, and "data objects" (objects without code, designed solely to store data) can extend this to a much lower level inside your code.
Simple code additions can also help with hold the data in a strict format whilst formatting it in different ways for different uses.
And by making classes readonly you can implement immutability which can also reduce bugs.
Finally, use of "final" should be discussed as a way to distinguish between polymorphism base-classes which can be extended (e.g. animal, mammal) , and end-classes which can't (e.g. Tabby Domestic Cat).
In fact to be even clearer, animal and mammal should probably be abstract classes, and Tabby Domestic Cat a final class.
Nostalgic to read this! @Ashish Pratap Singh what is your perspective on how oops should be reflected on in the vibe coding era.
Nostalgic to read this! @Ashish Pratap Singh what is your perspective on how oops should be reflected on in the vibe coding era.