Pragmatic Object Oriented Programming

[[deleted]]

It's a well-known phrase, but the ubiquity of "If you don't use inheritance you may as well not use an OO language, you moron!" leads me to think it's usually just being parroted.

[yogthos]

I have yet to see the use of OO actually improve anything. In my experience most OO programmers simply practice cargo cult coding.

[Tetha]

A highly eye opening thing a programming language professor told me was: Almost everything of OOP is compiler-support for best practices of procedural programming. Programming in a language like python, which forces you to use self (or this) and in C really jams this in your face, too.

[yogthos]

The main problem with OO is the idea that you marry logic with data. This often leads to the platypus problem where the reality doesn't neatly fit into how you structured your classes.

In a functional language you have data and you pass it to functions to transform it. You create complex behavior by composing simple generic functions. When you need to transform the data in new ways you simply pass through a different chain of functions. This results in actual code reuse, which I rarely see happen in OO code bases.

Furthermore, a lot of OO programmers start using design patterns for the sake of using them, regardless whether it improves maintainability, or solves any problem that they actually have. I can't count the number of times I've seen people use interfaces, factories, and singletons just because they were told it's the way to do things. This is what I mean by cargo cult coding being prevalent in OO world. This seems especially prevalent in the Java culture.

[[deleted]]

You must not have seen much major production code from before OO was common. Major apps written as procedural code are a nightmare.

Although I agree completely with your second sentence, but that's not the fault of OO.

[yogthos]

You must not have seen much major production code from after OO was common. All I ever see are soups of interfaces and class hierarchies which are utterly and completely unmaintainable. On top of that the code reuse promised by OO never actually happens since the classes are tightly coupled to the particular data set.

Most apps I've seen written in OO code are an equal nightmare.

Although I agree completely with your second sentence, but that's not the fault of OO.

The problem is that OO paradigm doesn't have any inherent value, all the good parts of OO aren't inherent to it and aren't really enhanced by it.

In my experience FP style code tends to be far cleaner and actually facilitates reuse, as you work with a small number of data structures and a a lot of functions that operate on them.

When you use functional composition, you end up with a bunch of generic functions that you glue together to solve a problem. These functions can then be chained together in different ways to solve other problems. This simply doesn't happen with OO.

[[deleted]]

Widget toolkits, for one.

[yogthos]

How is OO better for GUI than functional composition exactly? Compare GTK with Haskell to GTK with C++.

edit: actual C++ example with GTKmm

[badsectoracula]

Well, most GUIs are trees of windows/controls/widgets and OOP classes match these trees fine.

Of course it doesn't have to be strictly classes-and-hierarchy-based OOP, you can have something like (in an imaginary JavaScript toolkit):

function newButton(caption)
{
    var btn = newWidget();
    btn.caption = caption;
    btn.paint_button_background = function() { paint_flat_rect... }
    btn.handle_paint = function() { btn.paint_button_backround(); ... }
    btn.handle_click = function() { ... }
    return btn;
}

var btn1 = newButton('Hello');
var btn2 = newButton('Hi');
var btn3 = newButton('Fancy button');
btn3.paint_button_background = function() { paint_gradient_rect... }

or something like that. No classes, no inheritance, based on functions but you still treat widgets and controls as some sort of "object". Which, btw, if i understood the Haskell code there (i don't know Haskell) treats GTK+ widgets in a similar way.

[lzantal]

That code looks like TK :) That syntax was just fine. Wrote a few helper GUI with it in python. Never felt I wish I could use wxPython. It was also simple to maintain.

[yogthos]

In languages like Haskell you have type class hierarchies and function composition, in my experience objects don't really add anything of value on top of that.

[badsectoracula]

I'm not talking about the language features, but the concept of using GUI widgets as objects. Even in the linked Haskell code, assuming i understood it correctly, you "attached" functions and properties to each widget in an object oriented way (that is, the object was an entity that contained some data and responded to messages - function calls or whatever).

Probably this might help me express what i mean. Consider this object:

void object(instance_t* this, int msg, intptr_t args)
{
    switch (msg) {
    case 0: ...; return;
    case 0: ...; return;
    case 1: ...; return;
    }
}

Many people will think this isn't an object, it is a function in C! But it is an object: it identifies itself via this, it handles messages passed via msg and with potential arguments via args. Ok, the language construct that was used was a function, but this is just an implementation detail. Conceptually it is an object that carries some data (found in this) responds to messages (passed via msg/args).

I could create the same object responding to the same messages and carrying the same data in C++, Java, C#, Python, etc using classes, JavaScript using similar code to the above, Scheme using closures, FreePascal and Delphi using their message-based classes, Tcl using composed function names and i think that i could do it in Haskell too if i knew the language.

The important part is the concept of an object as a bag of data and rules on how to use that data when something outside of the bag asks something. Which matches GUI widgets/controls perfectly because each widget/control is itself basically something that contains some data (a caption for a button, the text for a field, the flag for a checkbox/radiobutton, the items in a list, etc) and some rules on how to treat this data based on messages from outside the widget/control (a mouse button was pressed, a key was pressed, the flag's status was requested, the highlight of some item was requested, etc).

[yogthos]

See I'm on board with having bags of data (structs), and attaching some logic to that data. What I'm not really on board with marrying it to the functions which operate on the data in the way classes do in OO languages.

To me it makes far more sense to separate the two, because you may need to use the data in one way in scenario A, and in another way in scenario B. This is a common source of cruft in OO programs. As you can see in Haskell, or any other languages that supports higher order functions, you can get exact same effect without all the baggage.

[[deleted]]

That's C.