Linked by Thom Holwerda on Mon 3rd Sep 2012 20:46 UTC, submitted by MOS6510
General Development I like this one: "By definition, a program is an entity that is run by the computer. It talks directly to the CPU and the OS. Code that does not talk directly to the CPU and the OS, but is instead run by some other program that does talk directly to the CPU and the OS, is not a program; it's a script." Here's the other eleven.
Permalink for comment 533744
To read all comments associated with this story, please click here.
RE: OOPs
by ndrw on Tue 4th Sep 2012 01:49 UTC in reply to "OOPs"
ndrw
Member since:
2009-06-30

I remember being utterly confused after reading books on OOP back in '90s. Authors often bundled other concepts with OOP, making it almost impossible to figure out what all the fuss is about.

In particular, OOP has nothing to do with:
- types or access modifiers - that's encapsulation,
- inheritance/mixins - that's code reuse,
- any particular coding style - that's plumbing,
- patterns - that's cooking recipes.
They are all useful techniques, it's just they have nothing to do with OOP.

Object oriented programming is really about having a bunch of objects (separable entities "living their own lives") communicating with each other. It's really as simple as that, yet very few OO programs or frameworks fit this definition.

For example, in another post I mentioned Kay's "setters are evil" rule. Why? For the same reason any mutation is evil. Calling a setter means taking control out of a target object and placing it in the calling one. So the target object is no longer a separate entity and becomes just a dumb storage of fields others may fiddle with - a data structure. This puts the calling object in business of coordinating changes and ensuring consistency of the target object state, which requires a lot more knowledge than just the API.

Reply Parent Score: 6