PDA

View Full Version : onion stlye of coding



manav
04-17-2008, 06:00 AM
int add(int a, int b) { return a+b; }
int addThem(int a, int b) { return add(a,b); }
int addition(int a, int b) { return addThem(a,b); }
// ...
int main()
{
return addition(-5, 5);
}




i am sick of this onion style of coding :(
can someone please give me a little comment on this, possibly giving reasons, why it can be useful?

matsp
04-17-2008, 06:04 AM
Well, obviously your simplified example is very silly, and if the compiler doesn't optimize it, the above code is a complete waste of CPU time (and in this example, makes the code harder to read, which is not to anyones benefit).

But there are reasons why you want to encapsulate and isolate different portions of code in various portions of source file. Most often you see this sort of thing in C++ rather than C, where things are going from one class to another, without actually doing anything with the data passed around - just passing it along to the next level in.

--
Mats

manav
04-17-2008, 06:18 AM
Well, obviously your simplified example is very silly, and if the compiler doesn't optimize it, the above code is a complete waste of CPU time (and in this example, makes the code harder to read, which is not to anyones benefit).
thanks Mats! yeah i know the example seems silly, but i have literally the same situation, where a function in one class, calls other function in other class, which calls another function in another class ... and so on!
my gut feeling says, that, this is natural in case of object oriented programming.

but i am unable to justify. why and how it is better?

Elysia
04-17-2008, 06:31 AM
It's better in sense that code won't be duplicated and depending on how well the functions are designed, it could potentially increase encapsulation.
Plus it makes it more readable instead of writing "x, y, z" you call a function saying "dothis", so you know exactly what it does.

matsp
04-17-2008, 06:34 AM
Well, it is a case of isolation - you call the next level class to solve the problem, and do not need to know what it does in your class. But it can be silly at times. If the functions are available to the compiler to inline, then the cost in CPU performance will be low, but it still gets hard to understand the code.

--
Mats

vart
04-17-2008, 06:36 AM
Each class has his functions

For example I could have
1. object that reads/write to/from socket
2. wrapper for the object above - that concatenates/splits messages that are too long
3. Actual message processor - that generates the message string based on the data to be sent
4. Some object that contains the data

So my 4 level object has a small string to be sent - it passes this string to the layer 3 object to construct a message
That object does nothing - just passes it to layer 2 Splitter
Splitter does nothing - just passes the string to Socket Writer

seems to be a litte overworked, but in the scenario, when data are long and not in the string format - each object provides its own processing of the data... So if the result is broken - looking on the type of the corruption we could figure out which obiect is responsible for it...

Also In the schema it is easy to replace socket with some other transport - because we only replace one small object and not the 10000 lines long monster
etc

manav
04-17-2008, 06:42 AM
a side note:
i noticed that i misspelled "style", so i edited it, now it shows corrected in my post, but out side it's not changed! :(

Mario F.
04-17-2008, 07:53 AM
That type of code usually shows up on heavily maintained code with few established rules. The next generation of maintainers feels there ought to be a better name for some function and encapsulate the original one, thus not breaking the old code and allowing themselves to use their own naming style/convention/whatever.

It's debatable if it has any advantages. Formally, a function that does nothing but encapsulate another function is a waste of resources and should be avoided. However, it's sometimes important when new strict naming conventions, for instance, are in place and old code must not be broken. It's also usually done in conjunction with namespaces (in the C++ world).

If however there is no reason for it, then it's bad practice across board. Bad practice because it makes the code harder to maintain (imagine having to add/delete an argument of the original function); Bad practice because it uses system resources; Bad practice because more than one function does the exact same thing, when we must strive to keep a 1:1 ratio between functions and functionality.

indigo0086
04-17-2008, 07:57 AM
I had sml this semester and these types of things were more useful when you have heavy recursive programs and didn't want to clog up the main recursion with local functions or anonymous functions.

Perspective
04-17-2008, 09:26 AM
thanks Mats! yeah i know the example seems silly, but i have literally the same situation, where a function in one class, calls other function in other class, which calls another function in another class ... and so on!
my gut feeling says, that, this is natural in case of object oriented programming.

but i am unable to justify. why and how it is better?


It's not always better, it can be a sign of feature envy which would suggest a flaw in the underlying design of your class structure.

In general though, having functionality in modular components makes it easier to reuse and maintain.

maxorator
04-17-2008, 09:53 AM
Whining about styles is a stupid thing to do.

For example this style...

int bla(int blabla)
{
//bla
}
...annoys me a bit but that doesn't mean I should whine.

People like different styles, there's nothing you can do about it. Onion style is perfectly OK for me.

Now make sure the next topic you make won't be named "Why do people like olives?".

abachler
04-17-2008, 10:09 AM
"Why do people like olives?".

Cuz they are so damned tasty of course :D Nothing beats a nice bowl of steamed Brussel sprouts with a garnish of diced garlic, green and black olives saute'd in butter.

guesst
04-17-2008, 11:27 AM
I see how that would be onion style, but when I saw it I was thinking about when you use a function's return value as the call for another function, like:

pook(foo(bar(), 5, tool()),6);

I've seen it. I've done it.

maxorator
04-17-2008, 12:00 PM
Cuz they are so damned tasty of course :D Nothing beats a nice bowl of steamed Brussel sprouts with a garnish of diced garlic, green and black olives saute'd in butter.
Yeah, I like olives too. :D

whiteflags
04-17-2008, 05:35 PM
Meh, well, that's just how you write the function call.

quz( bar( foo(), 42 ), 24 ); is just the "use it or lose it" idea of calling a function for its' return value. You could also "store it or ignore it" which might make things more legible for some.

I interpret "onion style" as delegating work, which is always useful in my experience. For example, using some methods internally for similar types of work is helpful, rather than resorting to something perhaps tedious or difficult to maintain.


double account::make_deposit ( double howmuch )
{
return m_balance += howmuch;
}

double account::make_withdrawal ( double howmuch )
{
return howmuch <= getBalance( ) ?
make_deposit( -howmuch ) : -1.0 /** error **/ ;
}

Why not recycle, eh?

manav
04-18-2008, 03:40 AM
For example this style...

int bla(int blabla)
{
//bla
}...annoys me a bit but that doesn't mean I should whine.

what's wrong about that style? can you explain a bit?


Now make sure the next topic you make won't be named "Why do people like olives?".
no, i suppose my next thread should be:
Are programmers still Human?

citizen, what is recycle?

maxorator
04-18-2008, 05:06 AM
what's wrong about that style? can you explain a bit?
There's nothing wrong with it, it just seems a bit too discursive for me.

If you don't like something, that simply means you don't like it. It does not mean there's anything wrong with it.


no, i suppose my next thread should be:
Are programmers still Human?
They are people. But that doesn't mean they like the same things as you do. People are different, accept that.

manav
04-18-2008, 05:41 AM
If you don't like something, that simply means you don't like it. It does not mean there's anything wrong with it.
actually in my case too, i did not say it was wrong, i asked why it is better, and i just explained that i could not justify it.


They are people. But that doesn't mean they like the same things as you do. People are different, accept that.
i accept that.
also even if they like the same thing as i do, they still may not like to share it with me anyway, since, for the most of it, they came to this board for an entirely different purpose!

and about the coding styles, it's better that, i stop saying anything!

whiteflags
04-18-2008, 05:47 AM
In this context - recycle: v. to use again.

Mario F.
04-18-2008, 07:35 AM
and about the coding styles, it's better that, i stop saying anything!

You shouldn't manav. Just ignore him. Don't be afraid to ask anything even if some people in here are currently thinking too much of themselves to take the time and lay down an answer that doesn't involve calling you an ignorant.

They are just forgetting that a little while ago they were the ones doing the questions and, more often than not, just like you, they didn't understand enough of the programming language to judge the relative value of these questions.

Personally, the simple fact you are worried with coding styles, the presentational aspects of your code, and basic coding strategies, reveals to me you are in the right path. Ask away and try to filter what good answers you get and just ignore the rest of the self conceited noise. (An advise I not always follow, but wish I did.)

medievalelks
04-18-2008, 08:13 AM
thanks Mats! yeah i know the example seems silly, but i have literally the same situation, where a function in one class, calls other function in other class, which calls another function in another class ... and so on!


Um, yes. That's how structured programming works. The alternative is one monolithic function that does everything.

maxorator
04-18-2008, 08:16 AM
They are just forgetting that a little while ago they were the ones doing the questions and, more often than not, just like you, they didn't understand enough of the programming language to judge the relative value of these questions.
True. But shouldn't people learn from others' mistakes? :D

Personally, the simple fact you are worried with coding styles, the presentational aspects of your code, and basic coding strategies, reveals to me you are in the right path. Ask away and try to filter what good answers you get and just ignore the rest of the self conceited noise. (An advise I not always follow, but wish I did.)
Worried about what coding style to use is a good thing. Worried about what coding styles other people use is not so good anymore. :p

matsp
04-18-2008, 09:10 AM
Um, yes. That's how structured programming works. The alternative is one monolithic function that does everything.

There is of course a balance to be struck between making tiny functions that do almost nothing but call another function, and a huge function with thousands of lines in it. Functions should do something - not necessarily that much either, but there should be some work other than just calling another function [in most cases].

In C++ you often find that a class calls a function in another class, which calls a function in another class, and so on. If all levels of calls here "do nothing but call the next level", one must ask if all these class levels are needed.

--
Mats

medievalelks
04-18-2008, 10:04 AM
There is of course a balance to be struck between making tiny functions that do almost nothing but call another function, and a huge function with thousands of lines in it. Functions should do something - not necessarily that much either, but there should be some work other than just calling another function [in most cases].

In C++ you often find that a class calls a function in another class, which calls a function in another class, and so on. If all levels of calls here "do nothing but call the next level", one must ask if all these class levels are needed.


I agree with you here. If you've read Fowler's "Refactoring", he calls this particular one "Remove Middle Man".

"Refactoring" is a must read for anyone doing OO programming.