0

In my code the following pattern is recurrent:

class Assembler {/*...*/}; //does something, in this case assembles a matrix
class AssemblerParam {/*...*/}; //contains the parameters needed to create 
                                //an object of the Assembler class
class AssemblerReader {/*...*/}; //reads a file and creates an 
                                 //object of AssemblerParam

I have realized this can be organized a lot better by nesting AssemblerParam and AssemblerReader inside Assembler (plus some advantages for generic programming)

class Assembler {
public:
    class Param { /*...*/ };
    class Reader{ /*...*/ };
private:
    Param parameters;
};

However, now the implementation of the methods of Assembler is a lot less readable for things like this

void Assembler::method() {
    parameters.mesh.method(parameters.member.method());
    //the code now is cluttered with the word "parameters"
}

Instead I would like my code to read:

void Assembler::method() {
    mesh.method(member.method()); //a lot more readable
}

Any solution?

Remark 1 Using inheritance like this

class AssemblerParam{/*...*/};
class Assembler : public AssemblerParam { /*...*/ };

would help on readability, but would pollute my namespace with classes SomethingParam.

1 Answers1

0

There can be no clean general solution to this problem; you must decide how to encapsulate things in a way that makes sense in the context of your project.

If mesh is used for things other than constructing the Assembler, it should probably be a member of Assembler. If constructing an Assembler requires so many parameters that the constructor is unreadable, then constructing the AssemblerParam would be just as difficult, so AssemblerParam doesn't solve that problem. There may be subsets of the parameter set that can be bundled into simple containers without complex methods, but that depends on the specifics of your case.

Beta
  • 96,650
  • 16
  • 149
  • 150
  • AssemblerReader builds AssemblerParam given a file name. I can also fill in the code AssemblerParam. It is to say, AssemblerParam unifies the way of creating an instance Assembler. – Daniel Alves Paladim Aug 25 '14 at 18:47
  • @DanielAlvesPaladim: Then why not have `AssemblerReader` build the `Assembler` directly? (I'm not sure what *"fill in the code AssemblerParam"* means.) – Beta Aug 26 '14 at 00:53