koobas.hobune.stream
OOP architexture analysis
Hello Unity friends ,
I have finished creating a camera that is implemented using a rigid Body rather than a character controller. Because I am about to release the source code on GitHub I will need some suggestions in terms of general OOP architexture of the camera.
More specifically there are three classes :
FPMovementController (that handles all the player moves)
Camera controller (that handles camera rotation and general camera actions)
CameraHeadBob (handles the camera headbob action).
1) FPMovementController is assigned to the parent gameobject and has a simple dependency with the CameraHeadBob class
2) CameraController is assigned to the child of the parent object and is not dependant from the other scripts
3) CameraHeadBod is assigned to the child and has a dependency with the FPMovementController.
What I would like to ask is weather this software architecture is good enough or can be further updated to match the norms of OPP programming. Also is it better to break the movements of the player to different classes (Jumping , running , etc ) even if more classes and dependencies, associations will arise ?
What is a bit strange is that you seem to have a two way dependency between FPMovementController and your CameraHeadBob class. But, why? Shouldn't the head bob just be driven by the FPMovementController? When you have a strongly typed two way relation ship between two classes they both can only come in pairs as each requires the other one.
So are you sure you need this two way coupling between your classes?. Also what exactly is that coupling used for? You may replace the strong coupling with a loose one by using an interface to communicate. Also keep in mind components are modules. It's highly adviced that each module works on it's own. Dependencies are fine but if they should provide a general solution you should make it possible to either remove some of the dependencies if they aren't needed or allow the user to replace it with a different implementation.
If the classes are meant to maybe serve as baseclass for the user so he can extend the functionality of it. Make sure you made the right things virtual / protected / private. As we don't have the slightest clue about how your code looks like this is all we can suggest by poking around in the dark.
Well the coupling is somewhat needed for the specific design. The specific coupling between the classes was made cause both of them wanting to address fields from each class so a specific behaviour can be accomplished.
However I would be really interesting hearing more about the interface you suggest to serve as a bridge between the two classes, maybe an general example would fit , cause I can really find a positive result from following this pattern.
You can also check the code here is this repo (under construction). https://github.com/Pan$$anonymous$$ig/First-Person-Unity-Camera
Thank you in advance for your time.
