View mode: basic / threaded / horizontal-split · Log in · Help
February 14, 2012
Anti-OOP... stupid?
Hello!

I've recently started to work with D, and I'll start a "bigger" 
project soon, using it. For a few days I've been thinking about 
the approach I'll take here, and since I don't /have/ to use full 
OOP in D, I was wondering... how crazy is it to not use full OP 
nowadays?

Naturally one would use objects, but since this isn't C#, or 
Java, not freaking everything has to be an object. The C style 
kinda feels more natural to me. (I know, I know, C naturally can 
do some OOP like stuff, etc... but you get the idea, mainly 
normal functions, some globals, yada, yada.)

What I want to know from you people... is that stupid? To even 
think about doing something like this? Basically mixing 
procedural and OOP? I know about the dangers, and disadvantages, 
but if those don't scare one away, would you consider it bad, if 
someone did this, on a larger project?

I'm looking forward to your answers.

Zero
February 14, 2012
Re: Anti-OOP... stupid?
IMO, what would be stupid is that everything has to be object 
oriented.

You have problems where OOP is good, and other where it isn't. 
Use the tool that fit what you want to accomplish.

Screwdriver are great, but are useless when you are dealing with 
a nail.

On Tuesday, 14 February 2012 at 22:00:44 UTC, Zero wrote:
> Hello!
>
> I've recently started to work with D, and I'll start a "bigger" 
> project soon, using it. For a few days I've been thinking about 
> the approach I'll take here, and since I don't /have/ to use 
> full OOP in D, I was wondering... how crazy is it to not use 
> full OP nowadays?
>
> Naturally one would use objects, but since this isn't C#, or 
> Java, not freaking everything has to be an object. The C style 
> kinda feels more natural to me. (I know, I know, C naturally 
> can do some OOP like stuff, etc... but you get the idea, mainly 
> normal functions, some globals, yada, yada.)
>
> What I want to know from you people... is that stupid? To even 
> think about doing something like this? Basically mixing 
> procedural and OOP? I know about the dangers, and 
> disadvantages, but if those don't scare one away, would you 
> consider it bad, if someone did this, on a larger project?
>
> I'm looking forward to your answers.
>
> Zero
February 14, 2012
Re: Anti-OOP... stupid?
On Tue, Feb 14, 2012 at 11:00:43PM +0100, Zero wrote:
> Hello!
> 
> I've recently started to work with D, and I'll start a "bigger"
> project soon, using it. For a few days I've been thinking about the
> approach I'll take here, and since I don't /have/ to use full OOP in
> D, I was wondering... how crazy is it to not use full OP nowadays?

I do that all the time. I guess that makes me crazy. :)


[...]
> What I want to know from you people... is that stupid? To even think
> about doing something like this? Basically mixing procedural and OOP?

D allows you to program in functional style, OOP, procedural style, or
any combination of them. There is a reason D was designed this way. :)


> I know about the dangers, and disadvantages, but if those don't scare
> one away, would you consider it bad, if someone did this, on a larger
> project?
[...]

OOP has its own share of dangers and disadvantages. Which, sadly, most
people don't talk about very much because they don't have the guts to go
against the current cool trendy bandwagon that everyone's jumping on.

Templates, for one thing, don't fit very well into the OO paradigm (ever
tried a virtual template function?), even though you *can* use it to
enhance an OO-based design. And D's templates are one of the best things
about D, ever.

Of course, many aspects of OO does help with large projects, so it's
usually a good idea to take advantage of that. But that doesn't mean you
*have* to use OO, or that it's "bad" to mix in procedural stuff when it
suits you.

I mean, if you take OO to the extreme, that would require excluding all
those evil procedural constructs like if statements and for loops, and
write everything in terms of invoking object methods...  like this
monstrosity:

class MyClass {
	void myMethod() {
		IntVariable i;
		ForLoopFactory.create(
			new IntSetter(i.address(), new Number(0)),
			new BooleanCondition(
				new LessThanComparator(i.address(),
					100)),
			new IntAdder(&i, 1),
			new IfStatement(
				new EqualComparator(i.address(),
					new Number(42)),
				new FunctionCaller(writeln.address(),
					new String("Found it!")),
			)
		).execute();
	}
}

which is, of course, completely ridiculous.

The bottom line is, use whatever tools work best for what you need to
do. If OO works well, use it. If procedural code works well, that use
it. If both works well in different cases, then use a mix of both
depending on the circumstances.

Trying to shoehorn everything into an object is stupid.


T

-- 
Государство делает вид, что платит нам зарплату, а мы делаем вид, что
работаем.
February 14, 2012
Re: Anti-OOP... stupid?
On 02/14/2012 11:00 PM, Zero wrote:
> Hello!
>
> I've recently started to work with D, and I'll start a "bigger" project
> soon, using it. For a few days I've been thinking about the approach
> I'll take here, and since I don't /have/ to use full OOP in D, I was
> wondering... how crazy is it to not use full OP nowadays?
>
> Naturally one would use objects, but since this isn't C#, or Java, not
> freaking everything has to be an object. The C style kinda feels more
> natural to me. (I know, I know, C naturally can do some OOP like stuff,
> etc... but you get the idea, mainly normal functions, some globals,
> yada, yada.)
>
> What I want to know from you people... is that stupid? To even think
> about doing something like this? Basically mixing procedural and OOP? I
> know about the dangers, and disadvantages, but if those don't scare one
> away, would you consider it bad, if someone did this, on a larger project?
>
> I'm looking forward to your answers.
>
> Zero

I think that is not stupid at all.

Approaching the problem the way that feels most natural is likely a good 
idea. As long as you actively keep in mind code quality measures such as 
extensibility and maintainability, everything should work out nicely. I 
encourage you to use the right abstractions. If something should be a 
free-standing function, use a free-standing function. If it is hard to 
force the involved objects into a hierarchy, use templates instead of/in 
combination with sub-typing and inheritance. If you want to parameterize 
a function on a few actions, consider using closures. If it is really 
clear how a well-designed class hierarchy would look like, use OOP. etc.

The basic achievement of OOP is that it can be used to replace 
procedural code of this general form:

void foo(ref S x){
    switch(x.kind){
        case KIND1:
            ...
            break;
        case KIND2:
            ...
            break;
        ...
    }
}

void bar(ref S x){
    switch(x.kind){
        case KIND1:
            ...
            break;
        ...
    }
}

This pattern emerges very often in practise, that is why OOP is useful. 
If you have anything that should work like that, using classes will do 
the job. Whether or not you apply OOP, make sure to keep stuff 
extensible. It does not hurt at all if your code base is more flexible 
than necessary.
February 14, 2012
Re: Anti-OOP... stupid?
On 02/14/2012 11:06 PM, deadalnix wrote:
> IMO, what would be stupid is that everything has to be object oriented.
>
> You have problems where OOP is good, and other where it isn't. Use the
> tool that fit what you want to accomplish.
>
> Screwdriver are great, but are useless when you are dealing with a nail.
>

Not exactly useless. Therefore it is hard to notice that they are not 
really fit for the job until having used a hammer. ;)
February 14, 2012
Re: Anti-OOP... stupid?
On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote:
> [...]
> It does not hurt at all if your code base is more flexible than
> necessary.
[...]

This needs to be taken in moderation, though.

I've had to work with code that was unnecessarily flexible. (I.e.,
over-engineered.) So flexible, in fact, that almost none of us knew how
to use it, and the code ended up deteriorating into a morass of hacks
attempting to bypass an overly-general framework that nobody understood.

One particularly bad example was that part of the system had a whole
hierarchy of database-access classes, intended to replace having to
write SQL directly. The problem was that it was so poorly documented,
and so difficult to understand, not to mention requiring a instantiating
a whole bunch of objects just to do something as simple as "SELECT *
FROM some_table;", that eventually people just resorted to writing a
function for executing SQL directly, thus bypassing the entire
over-engineered mess.

And that was only a small part of it. There were other beautifully
designed, fully OO, and fully generic classes, that accomplished
everything from the most trivial of tasks to the most advanced
high-level abstractions. Like the IPC mechanism, for which at one point
I had to write code to get through *six* layers of abstraction just to
call a single function. One layer of which involved fwrite(), fork(),
exec(), and fread(). Such was the result of the original code base being
much too flexible than it needed to be.


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson
February 14, 2012
Re: Anti-OOP... stupid?
On 15 February 2012 12:12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote:
>> [...]
>> It does not hurt at all if your code base is more flexible than
>> necessary.
> [...]
>
> This needs to be taken in moderation, though.
>
> I've had to work with code that was unnecessarily flexible. (I.e.,
> over-engineered.) So flexible, in fact, that almost none of us knew how
> to use it, and the code ended up deteriorating into a morass of hacks
> attempting to bypass an overly-general framework that nobody understood.
>
> One particularly bad example was that part of the system had a whole
> hierarchy of database-access classes, intended to replace having to
> write SQL directly. The problem was that it was so poorly documented,
> and so difficult to understand, not to mention requiring a instantiating
> a whole bunch of objects just to do something as simple as "SELECT *
> FROM some_table;", that eventually people just resorted to writing a
> function for executing SQL directly, thus bypassing the entire
> over-engineered mess.
>
> And that was only a small part of it. There were other beautifully
> designed, fully OO, and fully generic classes, that accomplished
> everything from the most trivial of tasks to the most advanced
> high-level abstractions. Like the IPC mechanism, for which at one point
> I had to write code to get through *six* layers of abstraction just to
> call a single function. One layer of which involved fwrite(), fork(),
> exec(), and fread(). Such was the result of the original code base being
> much too flexible than it needed to be.
>
>
> T
>
> --
> Why are you blatanly misspelling "blatant"? -- Branden Robinson

Basically, flexibility is good, but you have to make sure you are
actually writing a program, not a platform or framework, or worse a
COBOL. (COBOL being COmmon Business-Oriented Language, intended for
"business people" to use, and let programmers get back to writing
device drivers <.<)
February 14, 2012
Re: Anti-OOP... stupid?
On 02/15/2012 12:12 AM, H. S. Teoh wrote:
> On Tue, Feb 14, 2012 at 11:47:52PM +0100, Timon Gehr wrote:
>> [...]
>> It does not hurt at all if your code base is more flexible than
>> necessary.
> [...]
>
> This needs to be taken in moderation, though.
>
> I've had to work with code that was unnecessarily flexible. (I.e.,
> over-engineered.) So flexible, in fact, that almost none of us knew how
> to use it, and the code ended up deteriorating into a morass of hacks
> attempting to bypass an overly-general framework that nobody understood.
>
> One particularly bad example was that part of the system had a whole
> hierarchy of database-access classes, intended to replace having to
> write SQL directly. The problem was that it was so poorly documented,
> and so difficult to understand, not to mention requiring a instantiating
> a whole bunch of objects just to do something as simple as "SELECT *
> FROM some_table;", that eventually people just resorted to writing a
> function for executing SQL directly, thus bypassing the entire
> over-engineered mess.
>

Directly executing SQL is a much more flexible approach ;).

> And that was only a small part of it. There were other beautifully
> designed, fully OO, and fully generic classes, that accomplished
> everything from the most trivial of tasks to the most advanced
> high-level abstractions. Like the IPC mechanism, for which at one point
> I had to write code to get through *six* layers of abstraction just to
> call a single function. One layer of which involved fwrite(), fork(),
> exec(), and fread(). Such was the result of the original code base being
> much too flexible than it needed to be.
>
>
> T
>

For what I am concerned, flexible means *simple* to adapt, not that the 
existing code is so bloated and general that it does not need to be 
changed in order to implement a new functionality. In fact, I'd argue 
that such a design is inflexible: All new code is assumed to follow the 
bounds of the legacy code base.
February 14, 2012
Re: Anti-OOP... stupid?
H. S. Teoh:

> I mean, if you take OO to the extreme, that would require excluding all
> those evil procedural constructs like if statements and for loops, and
> write everything in terms of invoking object methods...  like this
> monstrosity:
> 
> class MyClass {
> 	void myMethod() {
> 		IntVariable i;
> 		ForLoopFactory.create(
> 			new IntSetter(i.address(), new Number(0)),
> 			new BooleanCondition(
> 				new LessThanComparator(i.address(),
> 					100)),
> 			new IntAdder(&i, 1),
> 			new IfStatement(
> 				new EqualComparator(i.address(),
> 					new Number(42)),
> 				new FunctionCaller(writeln.address(),
> 					new String("Found it!")),
> 			)
> 		).execute();
> 	}
> }
> 
> which is, of course, completely ridiculous.

Smalltalk is a language composed of a very small number of parts, where every thing is an object. So in a sense, you write code like that, with a better syntax.

Bye,
bearophile
February 15, 2012
Re: Anti-OOP... stupid?
On Tue, Feb 14, 2012 at 06:42:02PM -0500, bearophile wrote:
> H. S. Teoh:
> 
> > I mean, if you take OO to the extreme, that would require excluding all
> > those evil procedural constructs like if statements and for loops, and
> > write everything in terms of invoking object methods...  like this
> > monstrosity:
> > 
> > class MyClass {
> > 	void myMethod() {
> > 		IntVariable i;
> > 		ForLoopFactory.create(
> > 			new IntSetter(i.address(), new Number(0)),
> > 			new BooleanCondition(
> > 				new LessThanComparator(i.address(),
> > 					100)),
> > 			new IntAdder(&i, 1),
> > 			new IfStatement(
> > 				new EqualComparator(i.address(),
> > 					new Number(42)),
> > 				new FunctionCaller(writeln.address(),
> > 					new String("Found it!")),
> > 			)
> > 		).execute();
> > 	}
> > }
> > 
> > which is, of course, completely ridiculous.
> 
> Smalltalk is a language composed of a very small number of parts,
> where every thing is an object. So in a sense, you write code like
> that, with a better syntax.
[...]

True, but that doesn't mean that it's evil to not program in Smalltalk.
:-)


T

-- 
Don't modify spaghetti code unless you can eat the consequences.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home