Overall code logistics. What would be the best (advised) way of interrelating my class objects? Should I pass references around as member variables (the way I did with my Tetris class, it has pointers to screenBuffer and playingField objects) and make most of the game functionality internal to my objects or make them as independent of one another as possible, bringing all together in my program's main function by accessing each object when needed (essentially pulling some of the programs functionality out of my objects)?

I don't feel like an authoritative source enough to answer this one specifically, but if you want my opinion, I'm going to say make them separate. That way, because the objects don't overlap, you have more control at the upper level to do with them what you want. If you want to change how these objects interact, you can change the upper level without messing with the internal representation. If you need a new way for them to interact, you can just make a new method, and then you can keep the old way too, if you want, much easier.

I'm using the this keyword a lot. It sure clutters the code a little bit. I'll go ahead and not use it at all. I wonder if this is ok.

Yeah, that should be okay. The this keyword is generally to avoid confusion for data member names. So if you had, for example:

class foo {
    private:
        int x;
    public:
    void bar() {
        int x = 0;
        x = 5; // the function version of x
        this->x = 5; // the data member "x"
    }
};

If you don't have any data members the same name as other variables in your function, you should be good. this is unnecessary in that case.

Most of these classes don't have anything private. Should I use structures instead?

Private data members don't usually have anything to do with structures, so I'm not sure I understand the question correctly. However, I will say that structures are not a replacement for private data members. I think you misunderstand how the OOP model works.

Generally, private data members are reserved for data that no one else needs to see or access. Only the class will access these members via its own methods. If for some reason you need to access or manipulate these members, you need to make a public interface for them, that is, make special methods tasked with adjusting those private data members.

If I'm understanding you right by "Should I use structures instead?", meaning should you copy your data members to a special structure to pass around, the answer is no. Just pass the object itself around, and let other functions use the public interface you defined for it instead.

I should probably split this code into multiple files, one for each class definition.

This isn't necessary, per say, but yes, it would probably be good to do eventually.

Overall code logistics. What would be the best (advised) way of interrelating my class objects? Should I pass references around as member variables (the way I did with my Tetris class, it has pointers to screenBuffer and playingField objects) and make most of the game functionality internal to my objects or make them as independent of one another as possible, bringing all together in my program's main function by accessing each object when needed (essentially pulling some of the programs functionality out of my objects)?

I don't feel like an authoritative source enough to answer this one specifically, but if you want my opinion, I'm going to say make them separate. That way, because the objects don't overlap, you have more control at the upper level to do with them what you want. If you want to change how these objects interact, you can change the upper level without messing with the internal representation. If you need a new way for them to interact, you can just make a new method, and then you can keep the old way too, if you want, much easier.

I'm using the this keyword a lot. It sure clutters the code a little bit. I'll go ahead and not use it at all. I wonder if this is ok.

Yeah, that should be okay. The this keyword is generally to avoid confusion for data member names. So if you had, for example:

class foo {
    private:
        int x;
    public:
    void bar() {
        int x = 0;
        x = 5; // the function version of x
        this->x = 5; // the data member "x"
    }
};

If you don't have any data members the same name as other variables in your function, you should be good. this is unnecessary in that case.

Most of these classes don't have anything private. Should I use structures instead?

Private data members don't usually have anything to do with structures, so I'm not sure I understand the question correctly. However, I will say that structures are not a replacement for private data members. I think you misunderstand how the OOP model works.

Generally, private data members are reserved for data that no one else needs to see or access. Only the class will access these members via its own methods. If for some reason you need to access or manipulate these members, you need to make a public interface for them, that is, make special methods tasked with adjusting those private data members.

If I'm understanding you right by "Should I use structures instead?", meaning should you copy your data members to a special structure to pass around, the answer is no. Just pass the object itself around, and let other functions use the public interface you defined for it instead.

I should probably split this code into multiple files, one for each class definition.

This isn't necessary, per say, but yes, it would probably be good to do eventually.

• Overall code logistics. What would be the best (advised) way of interrelating my class objects? Should I pass references around as member variables (the way I did with my Tetris class, it has pointers to screenBuffer and playingField objects) and make most of the game functionality internal to my objects or make them as independent of one another as possible, bringing all together in my program's main function by accessing each object when needed (essentially pulling some of the programs functionality out of my objects)?

• I'm using the this keyword a lot. It sure clutters the code a little bit. I'll go ahead and not use it at all. I wonder if this is ok.

• Most of these classes don't have anything private. Should I use structures instead?

Private data members don't usually have anything to do with structures, so I'm not sure I understand the question correctly. However, I will say that structures are not a replacement for private data members. I think you misunderstand how the oop model works.

• I should probably split this code into multiple files, one for each class definition.

Overall code logistics. What would be the best (advised) way of interrelating my class objects? Should I pass references around as member variables (the way I did with my Tetris class, it has pointers to screenBuffer and playingField objects) and make most of the game functionality internal to my objects or make them as independent of one another as possible, bringing all together in my program's main function by accessing each object when needed (essentially pulling some of the programs functionality out of my objects)?

I'm using the this keyword a lot. It sure clutters the code a little bit. I'll go ahead and not use it at all. I wonder if this is ok.

Most of these classes don't have anything private. Should I use structures instead?

Private data members don't usually have anything to do with structures, so I'm not sure I understand the question correctly. However, I will say that structures are not a replacement for private data members. I think you misunderstand how the OOP model works.

I should probably split this code into multiple files, one for each class definition.