La classe est meilleur?
Qui classe le design est mieux et pourquoi?
public class User
{
public String UserName;
public String Password;
public String FirstName;
public String LastName;
}
public class Employee : User
{
public String EmployeeId;
public String EmployeeCode;
public String DepartmentId;
}
public class Member : User
{
public String MemberId;
public String JoinDate;
public String ExpiryDate;
}
OU
public class User
{
public String UserId;
public String UserName;
public String Password;
public String FirstName;
public String LastName;
}
public class Employee
{
public User UserInfo;
public String EmployeeId;
public String EmployeeCode;
public String DepartmentId;
}
public class Member
{
public User UserInfo;
public String MemberId;
public String JoinDate;
public String ExpiryDate;
}
- Je pense que les gens avec des scores plus faibles ne devraient pas être en mesure de fermer aux questions des gens avec des scores plus élevés. C'était un mauvais appel.
Vous devez vous connecter pour publier un commentaire.
La question est tout simplement répondu en reconnaissant que l'héritage des modèles de type "EST-UN" de la relation, tandis que l'adhésion des modèles "A-UN" de la relation.
Laquelle est la bonne? C'est votre réponse.
employeeA unuserinfodans le contexte de ce domaine. Si vous trouvez que votreemployeea unpostcodetout simplement parce que l'userfait, mais pour les fins de l'entreprise d'unemployee, lepostcoden'est pas nécessaire (il est forcé par le contrat d'unuser) ensuite la composition peut être plus approprié que l'héritage dans un tel cas.Je n'aime pas soit une. Ce qui se passe quand quelqu'un est à la fois un membre ou un employé?
public class EmployedMember: Employee, Member, en supposant que votre langue prend en charge plusieurs ancêtres. Bien sûr, la difficulté commence lorsque les deux classes d'utilisationIdau lieu deEmployeeIdetMemberIdrespectivement...Posez-vous la question suivante:
En général, s'efforcer de modéliser la réalité de votre programme simule, sous les contraintes de la complexité du code et de l'efficacité.
Je ne pense pas que la composition est toujours mieux que de l'héritage (juste en général). Si des Employés et des Membres sont vraiment les Utilisateurs, et ils sont mutuellement exclusifs, alors la première conception est meilleure. Considérez le scénario où vous avez besoin d'accéder le nom d'utilisateur de l'Employé. À l'aide de la deuxième conception que vous auriez:
qui est mauvais (loi de Déméter), de sorte que vous vous refactoriser à:
qui nécessite une petite méthode de l'Employé à déléguer à l'Utilisateur de l'objet. Tous ce qui est évité par la première conception.
Belle question, bien que pour éviter les distractions sur droit et mal j'avais songer à demander les avantages et les inconvénients de chaque approche -- je pense que c'est ce que vous voulez dire par ce qui est meilleur ou pour le pire, et pourquoi. De toute façon ....
La Première Approche aka Héritage
Pour:
Contre:
La Deuxième Approche aka Composition
Pour:
Contre:
Des listes de ce genre + les questions Jon Limjap mentionnés va vous aider à prendre des décisions et d'obtenir commencé, vous pouvez trouver ce que le droit réponses doivent avoir été 😉
Vous pouvez aussi penser à l'Employé comme un rôle de l'internaute (Personne physique). Le rôle de l'Utilisateur peut changer dans le temps (l'utilisateur peut devenir chômeurs) ou un Utilisateur peut avoir plusieurs rôles en même temps.
L'héritage est beaucoup mieux quand il est réel "est une" relation, par exemple Pomme - Fruit. Mais soyez très prudent: Cercle Ellipse n'est pas réel "est une" relation, parce que cirlce moins de "liberté" que l'ellipse (cercle est un état de l'ellipse) - voir: Cercle Ellipse problème.
Les vraies questions sont:
Ceux-ci peuvent être de trois entités indépendantes ou non, et qui permettra de déterminer si votre première ou de la deuxième conception, ou si un autre complètement différent de la conception est en ordre.
Ni l'un est bon. Trop mutable état. Vous ne devriez pas être en mesure de construire une instance d'une classe qui n'est pas valide ou partiellement état initialisé.
Cela dit, la deuxième est mieux, parce qu'il favorise la composition au cours de l'héritage.
En indiquant votre exigence/spec pourrait les aider à trouver le "meilleur design".
Votre question est trop "sujet-pour-lecteur-interprétation" à l'heure actuelle.
Voici un scénario, vous devez penser:
Composition (2ème exemple) est préférable si le même Utilisateur peut être à la fois un Employé et un Membre. Pourquoi? Parce que, pour deux instances (des Employés et des Membres) qui représentent le même Utilisateur, si l'Utilisateur des modifications des données, vous n'avez pas à mettre à jour dans les deux endroits. Seule l'instance d'Utilisateur contient toutes les informations de l'Utilisateur, et lui seul doit être mis à jour. Depuis que la fois des Employés et des Membres des classes contiennent la même instance d'Utilisateur, ils seront automatiquement les deux contiennent les informations mises à jour.
Plus de trois options:
Ont la
Userclasse contiennent de l'information supplémentaire pour les employés et les membres, avec des champs non utilisés vide (IDd'un particulierUserindique si l'utilisateur est un employé, un membre, à la fois, ou quoi que ce soit).Ont un
Userclasse qui contient une référence à unISupplementalInfo, oùISupplementalInfoest héritée parISupplementalEmployeeInfo,ISupplementalMemberInfo, etc. Le Code qui est applicable à tous les utilisateurs peuvent travailler avecUserles objets de la classe, et le code qui avait unUserde référence pourrait avoir accès à un utilisateur des informations supplémentaires, mais cette approche permettrait d'éviter d'avoir à changerUsersi différentes combinaisons des informations supplémentaires sont requises à l'avenir.Comme ci-dessus, mais qui ont le
Userclasse contiennent une sorte de collection deISupplementalInfo. Cette approche aurait l'avantage de faciliter l'ajout de propriétés à un utilisateur (par exemple parce que l'unMemberai embauché). Lors de l'utilisation de l'approche précédente, on aurait à définir des classes différentes pour différentes combinaisons de propriétés; la transformation d'un "membre" dans un "membre+client" aurait besoin d'un code différent de tourner un "employé" dans un "salarié+client". L'inconvénient de cette approche est qu'il serait plus difficile de se prémunir contre redondants ou l'incohérence des attributs (en utilisant quelque chose comme unDictionary<Type, ISupplementalInfo>de détenir des informations supplémentaires qui pourraient travailler, mais semble un peu "encombrant").J'aurais tendance à privilégier la seconde approche, en ce qu'elle permet l'agrandissement de mieux que l'héritage direct. De travail avec une collection d'objets plutôt qu'un seul objet peut être légèrement pénible, mais cette approche peut être mieux que les autres pour gérer l'évolution des besoins.