Essayer de séparer du code dans un modèle de serveur client où le client n'est pas fiable et avec une duplication minimale

Question

Je travaille sur un jeu client/serveur (C# .NET) où je ne veux pas faire confiance au client mon code d'application côté serveur, mais je veux partager des objets. Par exemple, imaginez que vous ayez une fente pour arme à droite et un sac à dos pour transporter des objets supplémentaires. Maintenant, il y a beaucoup de code côté serveur qui contrôlera quels éléments peuvent aller dans quels emplacements et quand vous balancez votre main droite ce qui se passe. Je ne veux pas mettre ce code dans mon client pour diverses raisons, mais je trouve souvent que si je génère une classe côté client et une classe côté serveur pour chacun d'entre eux, je vois beaucoup de duplication dans les données et une certaine duplication dans les méthodes. Je dois aussi convertir 1 classe en l'autre.

Un autre exemple est pour les objets dans le jeu. Les objets ont des capacités 'Utiliser' (comme Utiliser une touche, ou Utiliser une torche) et des propriétés comme Nom et Poids. Alors, quand je crée la classe Item Je préfère faire 1 classe comme ceci:

Public Class Item 
{ 

    int Weight; 

    string Name; 

    void Use() { //Do something interesting but not public to the client } 

} 

Finalement, des copies de cet objet sont sérialisés et envoyés au client ou serveur de l'autre que des modifications sont apportées. Si une classe partielle pouvait couvrir des projets qui seraient très prometteurs (au pire, ils ne le font pas). Je ne pense pas que le sous-classement se sent ici (comme ServerItem : Item) compte tenu de la sérialisation/désérialisation. Je vais en jouer avec les méthodes d'extension et voir quelles sont les implications pour le sous-classement, mais si quelqu'un a des idées ou si je manque quelque chose d'évident s'il vous plaît faites le moi savoir.

Answer 1

Vous voulez vraiment séparer les données du comportement, et avoir juste des classes de données partageables légères, puis (sur le serveur) avoir des classes centrées sur le serveur qui utilisent des données pour déterminer le comportement. (Essayez de regarder quelques bagouts design - peut-être « décorateur »)

Un exemple léger de ce que vous voudrez peut-être est:

// lightweight data class thats shared 
public class Item 
{ 
    public int Weight { get; set; } 
    public string Name { get; set; } 
} 

// decorator pattern class that adds behaviour 
public class ServerItem 
{ 
    private Item item; 
    public ServerItem(Item item) 
    { 
     this.item = item; 
    } 

    public void Use() 
    { 
     // do something with item; 
    } 
} 

ServerItem currentServerItem = new ServerItem(currentItem);