How to design this architecture using proper OOP?

PLyczkowski

I guess one of the main principles of good architecture is to try to design in it such a way that object know the least about each other - this way you have the least amount of connections that can break.

So, let's say I have this simplified architecture: https://dl.dropboxusercontent.com/s/9tmbxdbfiblswle/shot_161105_133506.png In it, the Character Generator and the Location Generator only provide data to the Database Manager, which then puts that data into the Database - they don't have access to the Database themselves, so it's all clean and segregated.

But, what if the Generators need some info from the Database? For instance, if the Character Generator wants to set which year a character was born, it needs to know the current year, which is in the Database.

How should I organize this? Should the Database Manager always provide the relevant info to the Generators when it uses them? What if they need a lot of info, should I just cram in this info into arguments, like generate_character(current_year, current_location, all_characters, all_locations, difficulty_settings, player_gender, player race, etc, etc, etc)?

xananax

I'm not sure how to answer on the basis of a "simplified architecture". Specific needs have specific answers...But I'll try.

Generic answer

don't get caught in programming paradigms. Do what works. If you have a dependency between two objects, you have a dependency, and any fake independence you'll inject will just obfuscate the dependency and make it harder to deal with.

In other words, if your character generator needs something from your DB manager, you have a dependency. How to make them independent? Well, you could for example, have the generator send a message where it requests information, and you could have the database send a message with the requested information, and have the generator listen to those messages. They'd "look" independent. But both would be dependent on a message manager; furthermore, both the information request and the information dispatching would be pretty useless if you removed either of the generator or the db manager. This is obfuscation by indirection and all it does is add complexity, without benefit. Any other solution you'd find would be similarly overly complex for no good reason. If two objects depend on each other they depend on each other. Make it clear. Make it so you can't instantiate the dependent object without passing its dependency. Don't try to force independence.

If you only need this information when you generate an object and never again, then it is possible, of course, to pass all info as arguments, but then you have a duplication of information. You should always thrive to have a single source of truth. Duplication of data means:

possibility of data being unsynchronized (update all_characters in db, then need to update it in all instances that use that variable)
more memory usage (negligible for low amounts of data, but can get messy, specially if some of that data is references) -> more work for the GC

Gokudomatic

I suggest to not stick to strict OOP paradigm but rather to a couple of design patterns. In your case, if a generator needs information from the database, I'd recommend to use some kind of mediator pattern. This mediator will know both the generators and the database manager, but each generator knows only the mediator. And the db manager knows only the mediator too. And thanks to duck typing, you can give any kind of mediator as long as they have the right method signatures. It is important that the mediator has as little logic as possible, since it should only do communication between components. With that way you still have dependencies but it is kept to a bare minimum and it doesn't suffer from obfuscation by indirection since you know that it goes through the mediator. There's however a pitfall to avoid with this design pattern: don't transform the mediator into some kind of global mastermind with global variables. So, don't put variables in it (there's the context pattern for that) and don't put complex logic in it (otherwise you do it wrong). For instance, if you need a summary of one field about all characters in the database, I suggest to have a character manager for that. This manager will use the mediator to get information from the database manager and it will give back to the mediator since this one was called by the character generator to get the summary data. And don't make too big mediators, which is also a pitfall.