In my client application I have two major components:

  • Core: wrapper that handles everything about running the actual application

  • NetworkClient: A layer that takes care of communicating (receiving/sending packets) with the server.

What I am not sure about is the way the NetworkClient should serve information to the Core process of the application. The core process has an event queue that is executed in update() calls. My initial idea is to have something like this:

  1. NetworkClient receives a snapshot of the state changes
  2. Takes that snapshot
  3. Chops it down to event objects for the Core process to handle.

The problem I see with that, isn't the NetworkClient class too dependent on the Core class? The opposite is not an issue however because, there can be a different client (UDP, TCP, etc) that works with the Core class.

So from a design point of view, is there a reason I might not want the NetworkClient class to be written for the specific implementation of the Core class?

1 Answer 1


Writing a NetworkClient specifically for the Core class does cause a dependency.

Alternatively you can create an integration layer that abstracts the interaction of the two. For the sake of argument, call it a Service. The Service is neither implemented in the Core or NetworkClient. Typically the Service has knowledge of transporting a resource (e.g. some state) from one place to another, using a specified mechanism (e.g. database, network, etc.) - "I know a guy who can do that for you". The Core is loosely coupled to the Service by subscribing to events that it emits. On the other hand, NetworkClient implements the means of transporting some "state" from one place to another, specifically over a network. The Service depends on the NetworkClient to achieve this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.