https://refactoring.guru/design-patterns
https://sourcemaking.com/s

Can have a base class that you instantiate. It will inherit nothing, but it will have "lazy" methods that point to all the other classes you need.

E.g you can have a reddit instance. this instance can define a comment/redditor/submission method that point to those classes by returning the method directly. These methods take the same vars as the classes they point to.

This is a shortcut and prevents polluting the front facing class with a lot of inhertiances.

Alternatively, for methods that don't need any additional variables, or are ok with the defaults, you can define this as a instance variable in the __init__ method.

Either way, you're providing a facade/api for the methods behind the scenes, without needing multiple inheritance on the front facing class.

The classes behind the scenes can have mixins to extend their functionality, and can have a base class that they all inherit from (PRAWBase)


When structuring the project:

1. Have a front facing class that is instantiated and where everything is done from.

2. This class should not have multiple inheritance

3. Have a final backend class that is responsible for the front end instance - it should be relatively simple, and selt a private variable for the front end instance that will be passed in.

3. The front facing class should provide a facade/api to the backend classes. These backend classes can use mixins (multiple mixins if necessary) to obtain extra functionality and should inherit from the backend class, making sure to pass 'self' in as an argument. This self will be set in the backend class so any future classes that dependo on it can access this same instance.

These backend classes (that have __init__) can use Super().__init__()

5. The front end class can either set an instance attribute (when you don't need to pass any attributes to these backend classes - they do not have __init__ set) or it can define a method that returns an instance of one of the backend classes that need instantiating and variables passing back.

The front end class should set the docstrings appropiately for these backend classes - either repeating the documentation or referencing the backend class documentation.


Remember:

Front end class
This should (at some point) pass 'self' back to the final backend class
This backend class should assign this to an instance variable (self.instance)
Backend classes can either be module functions (that depend on the final backend class - these should do some actual work)
Or the backend classes can be mixins that provide additional functionality to the other backend classes. 
All the backend classes can access self.instance

Some ideas for backend classes:

Final backend class can be called MODULEbase 
You could have a class that creates objects
    this could 


to do - go through mixins in praw and write down what each one does
map this logically to show how they can be seperated and organised to write a module using them.


Break down your structure into different interfaces. Each class should represent an object not a state of an object. Any properties that your object has that are unique to that object can be defined as a method/property in that same class.
Any shared functionality that more than one object might have should go in mixins that you inherit from. This allows you to share that functionality across different objects.

E.g reddit.Submission() - this is a subnission class and provides the interface to interact with submissions. This class represents a submission, it inherits from the base object (as expected), it also inherits several mixins. One of them is UserContentMixin which provides methods for comments and submissions. This mixin itself is just a combination of 7 other mixins, e.g EditableMixin, SavableMixin etc. This submission class can edit, it can save etc. so it can get this functionality from this mixin. This is also shared with comments which can do the same thing. It's a logical way of grouping things together.