4 ms·

Agreed. I think the problem with OOP (at least in most common implementations) is that objects (and/or classes) just do too much. They serve as complex data typ

by dsego 13y ago

Agreed. I think the problem with OOP (at least in most common implementations) is that objects (and/or classes) just do too much. They serve as complex data types, records, code modules, contracts, callback containers, etc. It's hard to grasp disparate concepts when you keep calling them the same name. Even harder to construct and explain more advanced stuff layered on top, such as various design patterns that actually make those objects useful.

RyanZAG 13y ago
You can make good arguments in either direction - either having a single generic type (a class) that fits all of these concepts, or having specific types for each of those concepts. Having just a generic type gives the language some useful simplicity as the single 'class' container can fulfill all of those needs yet not need the user to remember all the caveats of each specific type as the 'class' concept is generic enough to fit to almost anything. Having specific types is very good for teaching the different concepts at a higher level as well as documenting what is intended for future readers of the code (as long as they also understand all of the concepts involved). Convention over configuration, really. I personally prefer the more generic types as they don't try to lock you in to the authors specific biases and requirements - that's what frameworks are for.
hernan604 13y ago
Classes do too much if you dont have Roles. When you have Roles, you can build a class with Roles. like lego. Then you can have specific roles and build a class with Roles. If your OO doesnt support Classes, Roles, Types and method modifieds and functional programming, its outdated. Seems like your outdated OO needs a metaclass system, up-to-date like Moose from perl.
- memracom 13y ago
  Just about any OO system can do this using interfaces, abstract base classes, mixins, traits etc. Yes it is a good way to approach design rather than building unique behavior from scratch over and over. But you don't need to go anywhere near PERL to accomplish this.
pointernil 13y ago
Agree. I find it quite interesting how the concept of classes resp. objects has been adapted and moved away from what they really were let's say in Smalltalk (message processing entities) ... and I think this "progress" was not for better regarding the clarity of the concept. I think this progress has to do with "type systems" and additionally with the very powerful tools c++ f.e. added to the tool box. The more powerful the toolbox the harder it is to truly grasp it, it seams which steepens the learning curve considerably unless only the very rudimentary "features" of oop are used, as it happens mostly in commercial 9-5 software development.
- tezka 13y ago
  Have you programmed in Smalltalk? Classes tend to do a lot more (well everything that can be done) compared to C++. Smalltalk has a clean design for the core parts so these hang together pretty well. Nonetheless, inheritance hierarchies are deep and there are many fat classes. So small size in itself is usually not a virtue, clarity in role is on the other hand.

by dsego 13y ago

RyanZAG 13y ago

You can make good arguments in either direction - either having a single generic type (a class) that fits all of these concepts, or having specific types for each of those concepts. Having just a generic type gives the language some useful simplicity as the single 'class' container can fulfill all of those needs yet not need the user to remember all the caveats of each specific type as the 'class' concept is generic enough to fit to almost anything. Having specific types is very good for teaching the different concepts at a higher level as well as documenting what is intended for future readers of the code (as long as they also understand all of the concepts involved). Convention over configuration, really. I personally prefer the more generic types as they don't try to lock you in to the authors specific biases and requirements - that's what frameworks are for.

hernan604 13y ago

Classes do too much if you dont have Roles. When you have Roles, you can build a class with Roles. like lego. Then you can have specific roles and build a class with Roles. If your OO doesnt support Classes, Roles, Types and method modifieds and functional programming, its outdated. Seems like your outdated OO needs a metaclass system, up-to-date like Moose from perl.

memracom 13y ago
Just about any OO system can do this using interfaces, abstract base classes, mixins, traits etc. Yes it is a good way to approach design rather than building unique behavior from scratch over and over. But you don't need to go anywhere near PERL to accomplish this.

pointernil 13y ago

Agree. I find it quite interesting how the concept of classes resp. objects has been adapted and moved away from what they really were let's say in Smalltalk (message processing entities) ... and I think this "progress" was not for better regarding the clarity of the concept. I think this progress has to do with "type systems" and additionally with the very powerful tools c++ f.e. added to the tool box. The more powerful the toolbox the harder it is to truly grasp it, it seams which steepens the learning curve considerably unless only the very rudimentary "features" of oop are used, as it happens mostly in commercial 9-5 software development.

tezka 13y ago
Have you programmed in Smalltalk? Classes tend to do a lot more (well everything that can be done) compared to C++. Smalltalk has a clean design for the core parts so these hang together pretty well. Nonetheless, inheritance hierarchies are deep and there are many fat classes. So small size in itself is usually not a virtue, clarity in role is on the other hand.