Recent

Author Topic: OOP, the wrong path?  (Read 29416 times)

CristoferMartins

  • New Member
  • *
  • Posts: 21
  • Looking foward in Lazarus :D
OOP, the wrong path?
« on: September 26, 2011, 12:08:08 am »
When i start programming i feels like OOP was great. After that, OOP starts to show me his dark side.
I Start to put everything in classes, making code reusable even in situations whos don't need that, applyng patterns and such.
But at all i feels like something was wrong, then i search for it.

I have found some interesting posts on Net:

http://reocities.com/tablizer/oopbad.htm
http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/
http://www.infoq.com/news/2010/07/objects-smalltalk-erlang
http://blog.jot.fm/2010/08/26/ten-things-i-hate-about-object-oriented-programming/

Then, what you think about it?

typo

  • Hero Member
  • *****
  • Posts: 3051
Re: OOP, the wrong path?
« Reply #1 on: September 26, 2011, 12:17:54 am »
You can't share your code without OOP. It is a standard. Of course, if you can solve a problem with a simple routine. OOP is not necessary.

Rails

  • Guest
Re: OOP, the wrong path?
« Reply #2 on: September 26, 2011, 01:08:56 am »
Professor Nicklaus Wirth, the father of Pascal, the Modulas, and Oberon on OOP. Underlining added for emphasis.

"Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy. It is maintained for commercial reasons only. Object-oriented programming (OOP) solidly rests on the principles and concepts of traditional procedural programming (PP). OOP has not added a single novel concept, but it emphasizes two concepts much more strongly that was done with procedural programming. The fist such concept is that of the procedure bound to a composite variable called object. (The binding of the procedure is the justification for it being called a method). The means for this binding is the procedure variable (or record field), available in languages since the mid 1970s. The second concept is that of constructing a new data type (called subclass) by extending a given type (the superclass).

 It is worthwhile to note that along with the OOP paradigm came an entirely new terminology with the purpose of mystifying the roots of OOP. Thus, whereas you used to be able to activate a procedure by calling it, one now sends a message to the method. A new type is no longer built by extending a given type, but by defining a subclass which inherits its superclass. An interesting phenomenon is that many people learned for the first time about the important notions of data type, of encapsulation, and (perhaps) of information hiding when introduced to OOP. This alone would have made the introduction to OOP worthwhile, even if one didn't actually make use of its essence later on.

 Nevertheless, I consider OOP as an aspect of programming in the large; that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming. Static modularization is the first step towards OOP. It is much easier to understand and master than full OOP, it's sufficient in most cases for writing good software, and is sadly neglected in most common languages (with the exception of Ada).
 

 In a way, OOP falls short of its promises. Our ultimate goal is extensible programming (EP). By this, we mean the construction of hierarchies of modules, each module adding new functionality to the system. EP implies that the addition of a module is possible without any change in the existing modules. They need not even be recompiled. New modules not only add new procedures, but - more importantly - also new (extended) data types. We have demonstrated the practicality and economy of this approach with the design of the Oberon System."


Personally, I think OOP is highly overrated, especially for someone like myself, a single individual writing a program that will see zero enterprise use. For me, procedural programming provides all the tools I need. I only use OOP where I am forced to because of an event driven GUI.

How does sharing code require OOP? 

typo

  • Hero Member
  • *****
  • Posts: 3051
Re: OOP, the wrong path?
« Reply #3 on: September 26, 2011, 01:37:13 am »
Well, if you need to add something to a previously written OOP code, you need it. Subclassing a component, for example.

User137

  • Hero Member
  • *****
  • Posts: 1791
    • Nxpascal home
Re: OOP, the wrong path?
« Reply #4 on: September 26, 2011, 04:52:45 am »
I usually try to use both classes and records. There is a vague line on what should be record, but i guess it's about amount of instances. If you have to make 100+ objects instances of 1 class you're propably better off making it a record for performances sake. Every object takes some extra memory in addition to its variables, just reference alone being 4 bytes (more with 64-bit compiler?).

Leledumbo

  • Hero Member
  • *****
  • Posts: 8757
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: OOP, the wrong path?
« Reply #5 on: September 26, 2011, 06:40:40 am »
Quote
I Start to put everything in classes, making code reusable even in situations whos don't need that, applyng patterns and such.
Actually, this is a two sided sword. You may think that now the code shouldn't be made reusable, but one day when you need it, you'll realize that it should be made reusable. Yes, reusability sometimes are overthought, the designer thinks too far from the current needs. There's nothing wrong with that, the wrong comes when you pick the wrong the decision for a particular problem.

Zoran

  • Hero Member
  • *****
  • Posts: 1830
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: OOP, the wrong path?
« Reply #6 on: September 26, 2011, 08:39:27 am »
Static modularization is the first step towards OOP. It is much easier to understand and master than full OOP, it's sufficient in most cases for writing good software, and is sadly neglected in most common languages (with the exception of Ada).

What is "static modularization"?

m.vincent

  • New Member
  • *
  • Posts: 17
Re: OOP, the wrong path?
« Reply #7 on: September 26, 2011, 01:56:32 pm »
There are some benefits with OOP - I particularly like encapsulation, knowing that the data you are acting on is the right data. Coupled with encapsulation I like properties, setters and getters.

I recently wrote some code which needed to do some processing of real world data, not unlike audio.  There was the potential for many streams of data and values from a previous block of data from the stream, had to be carried over to the next.

As the number of streams was unknown at design time having a list of processing objects was easy and each object kept data from one block to the next. Easy.

I know this could be done with an array of records, but the added benefit of a class/object tips the balance in my opinion.

Inheritance can save time and code.  I'm developing an application that processes audio like streams of data.  There are a number of digital filters that can be applied to the data and each of these needs to have parameters set.  There are a number of parameters common to all the filters.

When designing the forms on which you enter the parameters it would have been easy to have a base form with the common parameter edit fields, then inherit from the base for each specific filters paraeters.  Sadly I didn't.  Now when I make a code or GUI change that affects the common area I have to make the same change in 6 different forms. Sigh. 

This is code re-use.  I doubt I'll resuse the forms in another application (its possible, but unlikely), but, if I had done it right, I would be sharing code within the same application.

Anyway, that's my take on it.

Regards,

Mike

ssamayoa

  • Full Member
  • ***
  • Posts: 163
Re: OOP, the wrong path?
« Reply #8 on: September 28, 2011, 01:37:12 am »
Interesting reading.

I only can add my own experience:

My first exposure to OOP was early 90s with Turbo Pascal 6.

It was very hard for me to shift paradigm from procedurar programming. At that time I was an experienced Cobol developer, also Clipper one.

But when I "get it" I didn't known how can I survived without OOP before.

Someone said in this thread that procedural is ok for him but he is forgetting that the TurboVision then VCL then LCL is OOP and he, even if isn't doing OOP, is comsuming OOP artifacts.

Now I'm doing OOP in Java and JavaScript. Yes, you read correctly: JavaScript. Using OOP allow me to stick to DRY most of the time. For example, I wrote a ExtJS form with a trigger field (an edit text box with a button) in which if you click the button it opens a lookup window. First time I wrote all the code where I needed, Second time I copied from fist one since, lazy me, I thought I will not need such functionallity again. Thrid time I realized that 1st time code has a bug which was already in 2nd place. I make the code a component and refactor old code so I not only got a cleaner implementation but also allowed me to reuse the component in other places, even extend the same component in other two cases. So OOP, when you "get it" no matter if is Java, C++, OP, etc. pays so is not overvaluated even if you are the "lone developer" (aka "lone ranger").

Regards.

diehard

  • Newbie
  • Posts: 2
Re: OOP, the wrong path?
« Reply #9 on: September 28, 2011, 07:47:27 am »
I've been hearing arguments against OOP for almost as long as I've been using it. Mostly they're fielded by people who 1) don't really "get it," and/ or 2) have gotten comfortable with procedural/ structural programming and are too set in their ways to learn anything else.  Often these are people who either 1) aren't programmers, or 2) IMHO, shouldn't be programmers, because they lack the desire to learn and improve.

It's like someone who has gotten proficient with the bow and arrow saying "guns suck" because they keep shooting themselves in the foot.

One of the things I like about Object Pascal and C++ is the fact that they are not pure object-oriented languages.  Unlike Java (for instance), not everything has to be encapsulated in a class.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8757
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: OOP, the wrong path?
« Reply #10 on: September 28, 2011, 08:45:45 am »
Quote
Unlike Java (for instance), not everything has to be encapsulated in a class.
Yeah, but Java itself isn't purely object oriented as well. Its primitive types, even when used as the class counterpart, pass everything by value instead of reference as any other classes. Even if it doesn't, Java is still not a pure object oriented language. The only one I've ever found is Smalltalk ;)

JD

  • Hero Member
  • *****
  • Posts: 1848
Re: OOP, the wrong path?
« Reply #11 on: September 28, 2011, 10:46:45 am »
Quote
I Start to put everything in classes, making code reusable even in situations whos don't need that, applyng patterns and such.
Actually, this is a two sided sword. You may think that now the code shouldn't be made reusable, but one day when you need it, you'll realize that it should be made reusable. Yes, reusability sometimes are overthought, the designer thinks too far from the current needs.

I learned this the hard way believe me. Now I think much harder about code reuse and encapsulation.
Windows - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe),
Linux Mint - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe)

mORMot; Zeos 8; SQLite, PostgreSQL & MariaDB; VirtualTreeView

ssamayoa

  • Full Member
  • ***
  • Posts: 163
Re: OOP, the wrong path?
« Reply #12 on: September 28, 2011, 05:26:29 pm »
Quote
Yeah, but Java itself isn't purely object oriented as well.

I would like to see what makes a language "pure OO" and what not.

Quote
Its primitive types, even when used as the class counterpart, pass everything by value instead of reference as any other classes.

That was intentional which should force developers to write more encapsulated code an avoid side effects changing referenced values.

At the beggining I missed params passing by reference because I was to accostumed to OP but after a while I "get it" and dont need it anymore.

Regards.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8757
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: OOP, the wrong path?
« Reply #13 on: September 29, 2011, 03:55:15 am »
Quote
I would like to see what makes a language "pure OO" and what not.
As many languages that claims they're pure OO: everything is object, even loops, branches, blocks of code, etc.
Quote
That was intentional which should force developers to write more encapsulated code an avoid side effects changing referenced values.

At the beggining I missed params passing by reference because I was to accostumed to OP but after a while I "get it" and dont need it anymore.
Well, there are cases when it's required like returning more than one value, it's a little overcomplicated to encapsulate a single integer in a class.

ssamayoa

  • Full Member
  • ***
  • Posts: 163
Re: OOP, the wrong path?
« Reply #14 on: September 29, 2011, 04:26:30 am »
Quote

Well, there are cases when it's required like returning more than one value,


If you need more than a one value in a function call something is wrong with your design or what you need to return is an object.

Quote

it's a little overcomplicated to encapsulate a single integer in a class.


I dont understand what you mean.

Regards.

 

TinyPortal © 2005-2018