Question on Unity OOD best practices

I apologize in advance if this is a dumb question, but I have some design level questions about scripting in Unity. I am a computer science student, and I am used to working with objects and their relationships, but I am a little confused on the best practice for unity (specially c# scripting). For instance, if I were programming a game in java I would have a Player class which HAS a position, HAS hitpoints, HAS speed, etc. This is all standard class composition. I get a little tripped up though with Unity's format, as it seems to be that I can take two different directions. 1. A monobehaviour deriving Player class, which has other information like hitpoints and speed. 2. 2. A non-monobehaviour Player class with standard constructors and such, which HAS a GameObject member which is it's geometry/animation/etc.

With (1), we have access to Monobehaviour's vast array of methods and functionality, but in order to set up our Player we'd need to either use public variables or some sort of factory method constructor since void Start() takes no arguments, ie.

 public static PlayerObject getPlayerObj(param1, param2, param3, ..., paramN)
 {
    GameObject go = Instantiate(somePrefab) as GameObject;
    PlayerObject po = go.getComponent<PlayerObject>();
 
    po.p1 = param1;
    ...
    return po;
 }

For (2), we can use a constructor and do not need a factory method or "Inspector public variables" to initialize. We can also use MonoBehaviour.Instantiate to setup our gameobject member.

In both cases, we have a gameObject member which references the game object the player represents. The difference is in the initializing and also the ability to manage game objects. That is, in order to update, we need something attached to an object, not an object attached to a script. Sure we can have a "GameManager" mono script on an empty object which manually updates players but this seems... not as intended. It seems like the correct choice here is (1), but it's just different than Im used to in say java or c++ where the Player class would HAVE geometry and positional information.

I guess I just want to know what is the best way to most effectively use Unity's unique style of scripting-gameobject fusion to make games that are more complex than dropping a few values for public variables in the inspector? Is it Monobehaviours (which have update functions and can handle themselves) with other data initialized by factories, or non-Monobehaviours with gameobject members which need to manually update since there is no Monobehaviour script attached to that gameObject member (the gameobject is "attached" to the script instead, thus some higher Mono script would have to loop them in IT'S update function).

Thanks very much for any input, just trying to avoid the pain of doing this the wrong way.