Manager Objects versus Sticking everything in cWorld

[worktycho]

Continuing on from the discussion here:https://github.com/mc-server/MCServer/co...nt-5293605

One of the main advantages of managers is it makes dependency management and dependency injection a lot easier. At the moment almost everything requires that you include cWorld as almost everything uses it. With managers it would be easier to just pass in the managers the object uses making the interfaces smaller and possibly using standard interface rather than having a separate interface class for every interface as each one has its own set of methods it needs and doesn't need. eg the BlockHandlers do not need to know about the Generator Queue.

[bearbin]

But - plugins need to have a consistent way of accessing the world data through one class.

[worktycho]

Yes but the world could provide methods to access the managers which plugins could use. The point is that if any part of MCServer wants to send a chat message or Access a block it has to link in everything. This is more of a problem for tools, for example a significant problem with creating a generator server is all the methods that access blocks and Hooks through cWorld. This makes it difficult to intercept calls that need to be forwarded to the main server.

[xoft]

We can have Interfaces, and the cWorld would implement those interfaces. This is different from the Managers, because Interfaces are "direct content" of the class, while Managers are separate classes.

The main point against Managers is that it makes calling stuff difficult - you need to remember that there's a manager for this and a manager for that and do World->GetThisManager()->DoThis() and World->GetThatManager()->DoThat().
With 50 managers this will become really chaotic.

[worktycho]

Only it woulnt be 50 managers it would be about 5-10. And 5-10 managers is alot less messy then 50-100 interfaces as the interfaces can't be reused. At least with managers we'ed only have one interface per logical group of functions. Without managers we've got one interface class for every interface between components or we end up with interfaces like managers but all implemented by one object. With manager like interfaces we have the non-world coupled code using managers and everything else using the world object.

---

Also in the decoupled code like the block handlers it's no worse than the current situation as its aoready using manager like interfaces. Youd just pass the managers in.

[FakeTruth]

Could you give an (elaborate) example of how these managers work (internally)? I am not very familiar with this design pattern.

[worktycho]

At the moment all of the broadcast methods are in cWorld and then call appropriate methods in chunkMap or the clientHandles. Im proprosing that we create a set of classes which are returned by methods on cWorld which would then contain a loigical group of methods (such as the broadcast methods) which would then forward them on. So we would have a class dedicated to routing broadcasts to the correct place. We could then look at possably moving implemention into these methods to reduce the monolithic ChunkMap implementation.

[FakeTruth]

That sounds similar to the entity component system.
I'm not sure if "manager" is the right name for such classes since they don't really manage anything. Instead, they forward methods to other objects.

On the one hand I like splitting the huge classes into more dedicated smaller classes, but on the other hand the functions in these huge classes make sense to be in them. Moving functions out of cWorld and into manager classes does not make much sense to me.

[worktycho]

I agree about manager not being the right name, its just what xoft was calling them. My main issue with cWorld is that there it causes a lot of link dependencies between components making it harder to reuse components in tools. Alos because the linux makefile uses incremental compelition the dependecies increase compile time. eg touch cPig and you have to rebuild the SimulatorManager.

[xoft]

Okay, let's give it a try, I'd recommend waiting for @tigerw to finish his messaging fixes (he's almost done with them) and then try this approach for the messaging. Or do you have any other area in mind?