On Thursday, 14 November 2013 at 10:51:31 UTC, Paulo Pinto wrote:
On Thursday, 14 November 2013 at 10:01:34 UTC, Jacob Carlborg
wrote:
On 2013-11-14 10:37, Don wrote:
I just can't escape the feeling that class-based runtime
polyphorphism
is almost never an ideal solution, and that most of the
benefits and
success of OOP languages comes from things other than OOP
itself. And I
think it's because OOP is philosophically nonsense -- in the
real world,
similarities between things are everywhere, but almost none
of them are
is-A relationships.
I think the most useful parts of OOP is encapsulation and have
the data and methods in the same place.
Actually no different than using ADT (Abstract Data Types)
popularized by modular languages like Modula-2, with the added
benefit of type extension and polymorphism.
Just because OOP has objects in the name, it doesn't need to be
real objects, but concepts actually.
The main problem was that OOP productivity was oversold hype,
in the same vein as web 2.0, cloud computing, agile and
whatever might come next. People need to sell books and
certifications.
And that the early OO design approaches focused too much in
implementation inheritance instead of interfaces and delegation.
--
Paulo
I agree that encapsulation and having logic and data in the same
place is a nice feature of OOP. Also, OOP is a tool that helps to
create an architecture or an infrastructure like
Data-Controller-Components, which is quite useful. However, it
happens again and again that a program gets tangled with
inter-dependencies. No matter how careful the planning is, as in
"this component (class) doesn't need to know anything about
XYZ.". Sooner or later there will be a case where this is no
longer doable. There are valid solutions like proxies etc. but
still it somehow doesn't feel right.
At the moment I'm using a mixture where I use structs and ranges
for tasks that can be performed independently, like for example a
filter that removes comments from a text file. There is no need
to put that behavior into a class. In other words it's a "blind"
component, that doesn't need to see anything else but the
incoming text. Being "blind", it can be reused out of the box.
OOP is still useful for having a central data pool (resources)
that can be accessed from anywhere by any component - if needs be
- delegating tasks etc.
This said, I sometimes have to implement an initially "blind"
component (struct, range) as an internal class to get the
references that exist within the class that uses it. This, or
pass the data to the component (bah!). Either way, it creates
dependencies. I tend to blame myself (bad planning, insufficient
understanding of the matter), but I wonder whether it is possible
at all to have a reasonably complex program without
inter-dependencies of some sort, FP or OOP. Is there, in reality,
only a certain amount of really independent components, whereas
the bulk of the program is invariably inter-dependent to varying
degrees?
