Sounds like the open/closed principle of SOLID development. "Objects should be open to extension but closed to modification". This basically means that users of your code shouldn't have to modify your classes to add functionality. It should be done through inheriance and adding new types. http://en.wikipedia.org/wiki/Open/closed_principle
I had the same thought when I saw that. There seems to be a trend to seal and lock down classes preventing any kind of extension. It sort of misses one of the main benefits of OOP and I know what I'm doing.
Thanks for demystifying prototypes.
For me it's hard to think that you can have an object without defining its class. However it seems the right approach. We're speaking about Object orientation, not Class orientation so why bother with classes
A better solution is "Just don't couple the two pieces of code!"
It takes a fair amount of work to design a good class where one can easily apply the open-closed principle. And one should where it's needed. But tying together two completely unrelated parts of your code base with such a class just because the two pieces of code are almost identical is the wrong approach. Then going ahead and designing it for the open-closed principle merely adds complexity.
Extending `object` was necessary until 2.7 when it became the default and old style classes were removed entirely in 3. So I think while the GP comment recently learned they don’t need to extend `object` anymore, they are/were familiar with new style vs old style classes.
It's called encapsulation/abstraction. You're not supposed to know the internal state of a class, and you shouldn't care if it's changing. The fact that you're complaining about that means you're not using those provided classes correctly. It's like complaining that a car isn't driving properly on ice. And that's because it wasn't meant to drive on ice, but rather on non-slippery surfaces.
Perhaps you shouldn't try to pigeon-hole classes that were made for normal OO usage into your functional tastes.
This is pretty much what I mean. Essentially I'm proposing that the "base class" shouldn't support anything other than close(). You could have objects which don't support read()/write(), but custom verbs with different semantics appropriate to their type. Tape drives (and only tape drives) could support a rewind(), etc.
SOLID applies only to OOP. Not using classes trivially satisfies the requirements of every letter. Hell, most design patters are trivial if you use functional programming.
The congruence with the rest of the language. It makes it so that creating a new class isn't declarative, but also just another message sent to the ecosystem of objects.
By "classes are open" you mean that you can add methods to classes at will by just implementing a func with the right receiver?
In that case they're not truly open: Go does not allow you to declare methods on receivers from other packages, which means you can't extend anything which wasn't written by you. Which makes open classes almost useless.
reply