4 ms·
> "Removing the difference between accessing an attribute (variable) and invoking a method is a solid OO principle. You, as a client of the API, should not care
by axod 16y ago
> "Removing the difference between accessing an attribute (variable) and invoking a method is a solid OO principle. You, as a client of the API, should not care how obj.foo is implemented."
I disagree. Code execution is not data access. They are very separate concepts.
- rue 16y agoInasmuch this conversation is subjective, I just do not think that statement is objectively true. It is a basic OO principle that the outside world is not privy to the inner workings of an object (or class if you prefer). Whether you like that or not is immaterial. You are free to avoid that aspect of OOP or the paradigm altogether.
- axod 16y agoI haven't studied OOP extensively in a strict setting, but I would have said that in the OO world, a property is completely separate to a method. For example, class flower property color property numberOfPetals method pluckPetal() method water() A property defines data about an object, and a method defines something you can 'do' with the object. Could you give some pointers to the OOP principle that blurs the line between these two?
- adambyrtek 16y agoIt's called the Uniform Access Principle, as I've already mentioned in a separate comment. Getting back to your example, it is not very useful without mentioning a language under examination. There is no single definition of OOP, and every language implements in a slightly different way. There are languages where UAP is enforced by the syntax (eg. Eiffel, Smalltalk, Ruby) and languages where it's a matter of convention. But even in the latter it's considered a good practice to keep properties private and encapsulate them with accessors. Some even have dedicated features that help with that (auto-properties in C#, properties in Python).
- masklinn 16y ago> I haven't studied OOP extensively in a strict setting, but I would have said that in the OO world, a property is completely separate to a method. There is absolutely no reason for that, and the grandparent of all things object-oriented (Smalltalk) very strongly disagrees with you: everything is a message, and there are no properties. > A property defines data about an object, and a method defines something you can 'do' with the object. A getter method is a property and a method. Properties are irrelevant, access should be uniform, the implementation details of an object (whether a "property" provides direct access to internal data or not) is of no concern to the user of the object. A property is nothing more than a method whose contract is "give me some data"
- axod 16y agoThat's a fine answer, and some people may find that a helpful way to organize programs. However, for me, and the CPU, we treat code execution differently to data access.
- philwelch 16y agoThere's OOP qua Smalltalk/Kay, and then there's OOP qua Java. You're describing OOP qua Java, which is an ugly type of OOP designed for certain performance advantages.
- axod 16y agoDon't be ridiculous. 1. It's not ugly 2. It's how CPUs work 3. It's how most people think
- philwelch 16y ago1. By ugly, I mean less mathematically elegant. In Ruby, you say "paul.foo" and get foo from Paul. How Paul gets foo for you is up to Paul. Simple. 2. If you want a programming language that maps closely to how CPU's work, Ruby's definitely not for you. Assembly and C are for you. 3. I can't speak for most people. What I can say is that I can think in C and I can think in Ruby, and it doesn't seem difficult for me.