News for hackers. Stuff that matters.

A comment on Pretending OOP Never Happened. Parent comment

Re:Pretending OOP Never Happened by AnimalMuppet on Friday May 15, 2020 @12:58PM (#23194429)
OOP had another advantage over procedural: Often in procedural programming, you'd pass around a pointer to some data structure. If the data structure got messed up (put in an inconsistent state, say), you had no idea what code was responsible. With OOP, you look at the class's member functions, which is a much smaller set.
[ Parent | on HN ]
Re:Pretending OOP Never Happened by zozbot234 on Friday May 15, 2020 @01:05PM (#23194535)
> If the data structure got messed up (put in an inconsistent state, say), you had no idea what code was responsible. With OOP, you look at the class's member functions, which is a much smaller set.

Yes this is correct. But data abstraction and encapsulation are found in all object-based code; they're not specific or related to OOP.

[ Parent | on HN ]
Re:Pretending OOP Never Happened by AnimalMuppet on Friday May 15, 2020 @01:26PM (#23194784)
I'm not sure I understand. In your view, what is the difference between "object-based code" and OOP?
[ Parent | on HN ]
Re:Pretending OOP Never Happened by kingdomcome50 on Saturday May 16, 2020 @12:20AM (#23200465)
Simply using objects in the code doesn't mean one is practicing OOP any more than using functions means one is practicing FP.

That is, it is more about the "how" than the "what".

[ Parent | on HN ]
Re:Pretending OOP Never Happened by beeforpork on Friday May 15, 2020 @01:36PM (#23194912)
How is there a smaller set because of OOP? Just filter the functions by parameter type to restrict which function may access your pointer.
[ Parent | on HN ]
Re:Pretending OOP Never Happened by Jtsummers on Friday May 15, 2020 @01:48PM (#23195054)
OOP encourages modifying an object's state via its member functions (if you use data hiding/encapsulation as part of your OOP definition). This means that users of class instances shouldn't be able to put it into a bad state, unless the member functions are able to put it in a bad state.

This lets you isolate where your contract/invariant violations are more easily. Once addressed in the member functions, either it fixes it in the callers, or their use is now invalid and becomes a compile or runtime error.

[ Parent | on HN ]
Re:Pretending OOP Never Happened by Konohamaru on Friday May 22, 2020 @02:21AM (#23269183)
It seems like there is a whole subject buried in this comment.
[ Parent | on HN ]