(Fixe)
Voyons d'abord ce qu'est MVP (Model View Presenter).
Pourquoi est-il nécessaire? La réponse la plus simple est de construire une architecture pratique et extensible.
Cela vaut la peine de comprendre pourquoi vous devez diviser l'interaction en trois classes différentes. Tout d'abord, la séparation des tâches, suivant les principes de SOLID. Deuxièmement, pour une interaction facile avec les serveurs pour la synchronisation des données.
Examinons de plus près les responsabilités de l'exemple
PlayerView.cs - représente en particulier la classe MonoBehaviour
using UnityEngine; public class PlayerView : MonoBehaviour { }
PlayerModel.cs - Représente une classe de données
public class PlayerModel { }
Presenter.cs - représente une classe de connectivité entre le modèle et la vue
public class PlayerPresenter { private PlayerView _playerView; private PlayerModel _playerModel public PlayerController(PlayerView view, PlayerModel model) { _playerView = view; _playerModel = model; } }
C'est tout le schéma.
Voyons maintenant pourquoi tout cela est nécessaire.
Nous ajoutons PlayerView.cs en tant que composant à notre lecteur Prefab .
Les classes restantes sont créées dans une classe de contrôle. Par exemple, créez une classe de contrôle.
Créez un objet vide sur la scène et suspendez le composant GameManager
GameManager.cs
public class GameManager : MonoBehaviour { public GameObject _playerPrefab; private PlayerPresenter _playerController; private PlayerModel _playerModel; public void Start(){ _playerModel = new PlayerModel(); var playerObject = Instantiate(_playerPrefab, Vector3.zero,Quaternion.identity); var playerView = playerObject.GetComponent<Playerview>(); _playerPresenter = new PlayerPresenter(playerView, _playermodel) } }
Eh bien, maintenant au début du jeu, nous allons créer un joueur. Mais quelle est la prochaine étape?
En fait, c'est un mécanicien fantastique. Eh bien, par exemple, développons le modèle Player en ajoutant de la santé.
PlayerModel.cs
public class PlayerModel { public event Action Death; public event Action<float> ChangedHealth; private float _maxHp = 100; private float _currentHp; public PlayerModel(){ _currentHp = maxHp; } public void SetNewHealth(float damage) { _currentHp -= damage; if(_currentHp > 0) ChangedHealth?.Invoke(_currentHp); else Death?.Invoke(); } }
Maintenant, notre joueur a Santé et deux événements pour changer la santé et la mort. Autrement dit, le modèle - représente la concentration de toutes les données du joueur et décide quoi faire lorsque des données changent.
Développez maintenant le Playercontroller afin que nous puissions interagir avec les données
PlayerPresenter.cs
public class PlayerPresenter { private PlayerView _playerView; private PlayerModel _playerModel public PlayerPresenter(PlayerView view, PlayerModel model) { _playerView = view; _playerModel = model; } public void Enable() { _playerModel.Death += Death; _playerModel.ChangedHealth += ChangeHealth; } private void ChangeHealth(float health){ _playerView.Changehealth(health); } private void Death(){ _playerView.Death(); Disable(); } public void Disable() { _playerModel.Death -= Death; _playerModel.ChangedHealth -= ChangeHealth; } }
Par conséquent, développons et PlayerView
PlayerView.cs
public class PlayerView : MonoBehaviour { public void Changehealth(float health) {
Par conséquent, nous avons obtenu une architecture extrêmement pratique pour créer une unité (ou tout autre objet), qui peut être développée par n'importe quel mécanicien. Besoin de mana? Ou du mouvement? Ajoutez du mana flottant, position Vector3 au modèle.
Quelle devrait être la conclusion? N'interférez pas avec View data (MonoBehaviour) avec de simples erreurs de calcul.
Le présentateur dans notre cas est situé au-dessus du niveau de PlayerView et PlayerModel et surveille si quelque chose change et réagit aux changements. Dans le même temps, PlayerController peut également surveiller les événements d'affichage, tels que les collisions ou les déclencheurs.