Je souhaite modéliser un site Web de marchand simple, avec un visiteur, un compte, un client et un administrateur.
Un visiteur peut avoir un panier.
Un visiteur peut devenir client s'il crée ou fournit des informations d'identification.
Un client et un administrateur sont un compte avec des informations d'identification. J'ai essayé une interface de compte, mais les méthodes de gestion de compte doivent être mis en œuvre à la fois au client et à l'administrateur, et je ne veux pas dupliquer ce code. J'ai vu que la mise en œuvre par défaut des méthodes d'interface existe dans Java 8. Mais existe-t-il une autre façon d'atteindre cela sans ce piratage?
3 Réponses :
Vous aurez peut-être besoin d'une méthode abstraite pour infrastructurer la classe
Vous devez reconsidérer la conception et favoriser la composition sur l'héritage.
Une règle simple - Comment identifier si vous devez utiliser l'une ou l'autre: l'héritage répond-il à la question Est client et compte? Non. Le client est un utilisateur qui peut avoir et un compte. est client un visiteur? Oui, il peut être. Vous devez donc étendre votre client de visiteur et ajouter un compte en tant que membre de la classe. Vous pouvez ajouter une interface pour le rendre encore meilleur en termes de solide : et rendre votre client et admin pour le mettre en œuvre si Vous souhaitez toujours éviter les getters et les configurateurs de comptes de duplication - il suffit d'étendre l'administrateur à partir du client et de remplacer getbasket () - Thow notimplementaedException ()
Une interface Authentrable authentique ne permettrait pas d'accéder directement au compte, mais plutôt des actions sur un compte et le compte reste encapsulé dans la mise en œuvre.
Tom pourrait avoir raison. Dans ce cas, des actions avec le compte devraient être mises en œuvre dans la méthode des services publics pour éviter la duplication.
Non seulement la duplication, mais également la protection des informations stockées dans l'instance , comme les informations d'identification. Donner que d'autres classes peuvent entraîner une fuite de sécurité.
Les informations d'identification ne doivent pas être stockées ouvertes même dans des bases de données. Ils devraient être cryptés. Mais vous avez raison, cela pourrait être un problème de toute façon.
Java n'a pas de héritage multiple comme Python. Ceci est fait.
Vous pouvez modifier par exemple si vous souhaitez vous déconnecter, vous devez dire
`Customer.getaBount (). Déconnexion (); C'est une bonne pratique car vous ne dupliquez pas la mise en œuvre du compte et que vous souhaitiez également la déférence entre certaines informations d'identification. De cette façon, vous devez simplement créer une nouvelle classe CompteImpl . compte de la classe en interface. Et créer une classe avec nom 'comptaimpl' qui implémente compte . Dans chaque classe que vous souhaitez définir des méthodes de gestion de compte tels que admin ou client , vous devez avoir un champ de compte interface et initiez-le avec CompteImpl classe. quelque chose comme ceci:
Java n'a pas de héritage multiple.
Le client n'est pas un compte. Le client peut avoir un compte cependant.
Vous voudrez peut-être envisager la composition (peut-être avec la décoration) à la place. Renvoie les champs des instances de visiteur et de compte si nécessaire ou juste directement. IMHO, héritage / personnalisation n'est pas vraiment approprié pour l'agrégation. Je l'ai fait de cette façon plusieurs fois et cela devient généralement désordonné.
En général, vous devriez Préférer la composition sur l'héritage . L'héritage n'est qu'un mécanisme pour la réutilisation du code, et sans doute, ce n'est pas un très bon mécanisme. Il existe d'autres moyens de réutiliser le code, généralement en créant davantage d'objets pour représenter les parties réutilisables des choses. (Séparément de Héritage de la mise en œuvre Il y a aussi Héritage de l'API , qui en Java est implémentée à l'aide d'interfaces. Vous pouvez et doit généralement mettre en œuvre plusieurs interfaces chaque fois que votre objet remplit le contrat de ces interfaces .)
Dans les mots simples de la réponse de Josh, en maintenant une méthode qui renvoie le niveau d'autorisation à un compte (ou ce qu'il peut accéder, par exemple
candeleaccount ougetpermissions ) et avoir les sous-classes modifier cela afin de vous permettre de définir un comportement de niveau supérieur autour de celui-ci. En outre, cela peut même conduire à l'élimination du concretAdministrator /Classes Classes et laissez-vous une abstraction autour de toute forme d'utilisateur