Printable View
Code: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?
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
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!Quote:
Originally Posted by matsp
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 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.
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
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
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! :(
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.
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.
Quote:
Originally Posted by manav
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.
Whining about styles is a stupid thing to do.
For example this style...
...annoys me a bit but that doesn't mean I should whine.Code:int bla(int blabla)
{
//bla
}
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?".
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.Quote:
Originally Posted by maxorator
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.
Yeah, I like olives too. :DQuote:
Originally Posted by abachler
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.
Why not recycle, eh?Code: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 **/ ;
}
what's wrong about that style? can you explain a bit?Quote:
Originally Posted by maxorator
no, i suppose my next thread should be:Quote:
Now make sure the next topic you make won't be named "Why do people like olives?".
Are programmers still Human?
citizen, what is recycle?
There's nothing wrong with it, it just seems a bit too discursive for me.Quote:
Originally Posted by manav
If you don't like something, that simply means you don't like it. It does not mean there's anything wrong with it.
They are people. But that doesn't mean they like the same things as you do. People are different, accept that.Quote:
Originally Posted by manav
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.Quote:
Originally Posted by maxorator
i accept that.Quote:
They are people. But that doesn't mean they like the same things as you do. People are different, 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!
In this context - recycle: v. to use again.
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.Quote:
Originally Posted by manav
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.)
Um, yes. That's how structured programming works. The alternative is one monolithic function that does everything.Quote:
Originally Posted by manav
True. But shouldn't people learn from others' mistakes? :DQuote:
Originally Posted by Mario F.
Worried about what coding style to use is a good thing. Worried about what coding styles other people use is not so good anymore. :pQuote:
Originally Posted by Mario F.
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].Quote:
Originally Posted by medievalelks
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
I agree with you here. If you've read Fowler's "Refactoring", he calls this particular one "Remove Middle Man".Quote:
Originally Posted by matsp
"Refactoring" is a must read for anyone doing OO programming.