1

Topic: Balance between storage of variables in fields of a class and beauty of the code.

There is a long sausage  the code which operates with contexts,  and arrays (common example) At a rewriting in with ++ the code by mind it is necessary to envelop each essence in with ++ object and to operate with it, but we lower the given approach. I want to break the code into small methods till 5-10 lines, no more. Obviously, there are many entering and quitting variables. It is possible to register all proceeding variables in fields of a class and to work with them. Or evidently to receive at an output from function all values in not which type of structure. In the first variant suffers both readership of the code, and connectivity. The second variant is much more elegant, perfectly we test but the sensation is added that it not the approach and can be made OOP somehow differently. And as though you made?

2

Re: Balance between storage of variables in fields of a class and beauty of the code.

SO _> I want to break the code into small methods till 5-10 lines, no more. What ultimate goal? If the purpose - visually to make more readably as variant, to break into units: void main () {int width; int height;...//open input file {...}//setup demuxer {...}//setup decoder {...}//process file {...}//close files and buffers {...}//error handling {...}} And so - quite to itself normal C-shnyj the code for a sample.

3

Re: Balance between storage of variables in fields of a class and beauty of the code.

Hello, DiPaolo, you wrote: SO _>> I want to break the code into small methods till 5-10 lines, no more. DP> what ultimate goal? If the purpose - visually to make more readably as variant, to break into units:... DP> And so - quite to itself normal C-shnyj the code for a sample. The purpose - to envelop about the code in with ++ a jacket. I do not love some sausage. And, it would be desirable to manage small efforts and not to mold on With ++ to a class on everyone About type.

4

Re: Balance between storage of variables in fields of a class and beauty of the code.

Well then  a variant: class FileDecoder {public: int openFile (); int processFile (); int done (); int dumpOutputLog (); private: int openInputFile (); int openOutputFile (); int setupDemuxer (); int setupDecoder (); int closeDemuxer (); int closeDecoder (); private: FILE *video_dst_file = NULL; FILE *audio_dst_file = NULL; uint8_t *video_dst_data [4] = {NULL}; int video_dst_linesize [4]; int video_dst_bufsize;...} void main () {int width; int height;... FileDecoder decoder (...); decoder.open (inputFile); decoder.processFile (); decoder.dumpOutputLog ();}

5

Re: Balance between storage of variables in fields of a class and beauty of the code.

Hello, DiPaolo, you wrote: DP> Well then  a variant: DP> DP> class FileDecoder DP> FILE *video_dst_file = NULL; DP> FILE *audio_dst_file = NULL; DP> uint8_t *video_dst_data [4] = {NULL}; DP> int video_dst_linesize [4]; DP> int video_dst_bufsize; DP>... DP>} DP> Yes, it is a variant - when all variables of all functions are stored as a class field. Quickly and untidily.

6

Re: Balance between storage of variables in fields of a class and beauty of the code.

Hello, SomeOne_TT, you wrote: SO _> I want to break the code into small methods till 5-10 lines, no more. SO _>... SO _> and as though you made? I would not break the code into methods till 5-10 lines. Would look at sausage, and on circumstances made the decision what to carry out, and that and to leave sausage. Struggle against Cyclomatic complexity - rather harmful . One long method happens on the order easier to understand, develop and accompany, than the same, but cut on tens slices. That to two described alternatives each of them is in own way awful. In the second variant, by the way, it  - the smallest problem (OOP - too , and too rather harmful).

7

Re: Balance between storage of variables in fields of a class and beauty of the code.

Hello, Voblin, you wrote: V> That to two described alternatives each of them is in own way awful. In the second variant, by the way, it  - the smallest problem (OOP - too , and too rather harmful). It agree, the example on With is perfectly read, however to test it more difficult, than feature set. Well, for want of something better, we assume sausage as a basis. I thank Voblin, DiPaolo.

8

Re: Balance between storage of variables in fields of a class and beauty of the code.

Hello, SomeOne_TT, you wrote: SO _>) evidently to receive at an output from function all values in not which type of structure. SO _> the second variant is much more elegant, is perfectly tested but the sensation is added, SO _> that it not the approach and can be made OOP somehow differently. Yes, it not OOP, it . That it is better, it is possible to clarify in

9

Re: Balance between storage of variables in fields of a class and beauty of the code.

Hello, SomeOne_TT, you wrote: SO _> the Second variant is much more elegant, is perfectly tested but the sensation is added, SO _> that it not the approach and can be made OOP somehow differently. SO _> And as though you made? Would try to make a combination of two approaches. With the big emphasis on the second approach. After some experience the understanding came that OOP line not panacea, and it is not necessary to do OOP only for the sake of that was OOP. Accordingly a logic maximum on short simple functions without  effects. At which one input and one output, as an input and an output can be structures. Which are perfectly tested and repeatedly used. And on those cases when it does not work (for example if so to do it is necessary to transfer to a fig of parameters in function) - to use classes. And to try to observe balance. The main criterion - to write as less as possible the code. And that thus also  it was possible though the main functional. And that tests too were not . Well and if also performance is necessary maximum, would start to sacrifice than or, probably would reduce percent of functions without  effects in favor of methods. But anyway would split up for small pieces the logic.

10

Re: Balance between storage of variables in fields of a class and beauty of the code.

Hello, SomeOne_TT, you wrote: SO _> And as though you made? In general it was possible to cut sausage on pieces, in fields of a class it is stored nothing, a key role fulfilled unique_ptr with self-made  that allowed to be restricted to local variables.