My first attempt at Object-oriented programming, an attempt at a class Complex, I was using constructors, fields, and methods in a class without even understanding the concept of a class. I did a bad job, but it worked.
Well, in a "Complex" class you don't really get that much better anyways. More often than not a Complex class is really just used as a data structure that provides a few operations on it. I guess if you went for an OO representation of Complex numbers you could switch to using a trigonometric representation rather than an arithmetic one, but in the cases you'd need to do that you'd probably want to be explicit about it anyways.
That's why I believe that things like numbers, geometric shapes etc which are all inherently data structures are bad examples for OO.
I'm not sure why you think those things are bad examples for OO. I'm also not sure why you refer to them as "inherently data structures." Aren't most concrete classes just data structures with some operations defined? That's kind of the definition of a class, isn't it? (Optional) data with supplied operations?
FILE* is a great example of OO methodology applied in C.
While you could choose to see a "BigNum" as a data structure to be manipulated, encapsulating the idea in a class allows much-easier-to-grok code and that is one of OO's major benefits.
I have to agree that the ubiquitous shape family usually introduced as an example to beginners isn't a shining light in the darkness, nevertheless, there is some merit to the abstract idea of shape in a graphics library, which is doubtless why so many graphics libraries codify it.
The power of OO lies mainly in abstraction. The control flow is supposed to be determined by objects communicating with each other. Data structures don't communicate with anything, they just hold data. You can't really abstract anything from it, so they're not good examples for OO programming. Now I'm not saying that there aren't any merits to putting them in a class, it's just not particularly "object oriented".
I believe that things like numbers, geometric shapes etc which are all inherently data structures are bad examples for OO
Yes and no: these things are all value-sematic types. They represent globally unique values, mathematical concepts, and do not represent physical objects. Because of that, many OOP concepts do not apply or apply poorly. On the other hand, VSTs are fundamental to C++ (and other programming), and learning the difference between value and state, between equivalence and equality, between externalizable and in-process values, etc, is just as important as learning the difference between composition and aggregation.
Object = {
subclass = function()
local class = {}
class.functiontable = {}
class.def = function(name,method) class.functiontable[name] = method end
class.create = function ()
local self = {}
for name,method in pairs(class.functiontable) do
self[name] = function(...) return method(self,...) end
end
return self
end
returnclass
end
}
List = Object.subclass()
List.def("add", function(self, value) self.value = value end)
l = List.create()
l.add(3)
print(l.value)
When I got this far, I read a little further in my book and found out about metatables. Damn.
That was sort of what I was getting at: I felt like a genius, advancing my code from nested if-else to a switch statement, while I clearly had a long way to go.
I think part of the confusion was the mixture of PHP and HTML syntax. I simplified the example, but the actual code will probably have had a lot of table-layout data in the echo statement [which, later on, I learned was completely stupid as well].