Why not separating functions and data with nested structs?

Question

I often think about avoiding "forgetting member variables" in toString-methods, initialisation lists,... Further I often see logic of the object itself (data usage and manipulation) mixed up with pure data-care (initialisation, get/set, constructor for copy,rval-copy,bla).

If it comes to really big classes with a lot of methods and member variables it gets pretty confusing.

So what's the reason, why programmers do not put all the variables together in one nested struct that does only do data care and extracting the buisiness-logic?

I'd imagine

class NestedStructTesting
{
public:
    typedef struct TData
    {
    private:
        int var1;
        float var2;
    public:

        int getVar1(){return var1;};
        void setvar1(int value){var1 = value;};
        int getVar2(){return var2;};
        void setvar2(int value){var2 = value;};     

        TData()
        {
            var1 = 0;
            var2 = 0;
        }
    };
    TData Data;


    NestedStructTesting(void)
        : Data()
    {
    };


};

maybe with an outside-call like: NestedStructTesting st; st.Data.setvar1()

( I don't have any experience using it in big projects, as I didn't build up one, yet )

It doesn't really buy you anything. You just have to type `st.Data` everywhere that you would have written `st`. — Barmar, Oct 24 '14 at 14:53

score 0 · Answer 1 · edited May 23 '17 at 12:15

Because if you're in that case then you most likely need to create another class to divide the huge amount of work your big class is doing. And in that case you will also most likely put that inner class in its own .hpp/.cpp file.

You can use inner classes if you think that the logic of the classes are close to each other enough that they are best located in the same files or just because you fill like it's cleaner in your overall design.

AFAIK there is only one limitation with nested classes which is that you cannot forward declare them in every case.

More generally, except if you have an MVC-like pattern you will not want to separate data from logic but you will rather want to group little pieces of data with their corresponding little piece of logic, that's one of the most simple and efficient way to do OOP. In fact outside of a framework design, a lot of developers chose a separation unit which is not necessarily the nature/type of the code(data/logic/other) but its size, for better and for worse :)

score 0 · Accepted Answer · answered Oct 24 '14 at 17:14

That pattern already exists, it is called PIMPL idiom, and it hides all the class data.

With it, you can separate public methods from the private methods and data, which exists only inside the .cpp.

As an example, all the Qt framework is build with this idiom, so you will never ever (maybe exagerating, but you get the point) see any private class variable in the hundreds of header files they provide, just public (and virtual protected) methods.

Other benefits of the PIMPL idiom is that it simplifies the binary compatibility, makes the class interface clearer (by removing the private and non-virtual protected members from the header file), reduces the compiling time (by removing #includes from the header files) and separates the interface from the implementation (by hiding the implementation dependant variables and methods, which usually are private)

thanks, no I know what to search for, to get more information about experience :) — TheTrowser, Oct 25 '14 at 20:15

Why not separating functions and data with nested structs?

2 Answers2