Je parlais avec un programmeur de mien à propos de l'héritage et de son utilisation dans la conception de modèles. Il est un grand promoteur et je suis un peu plus tiède. La plupart du temps parce que j'ai tendance à concevoir des systèmes de bas en haut: base de données -> Application -> Présentation (honnêtement, je ne suis pas une grande partie d'un gars front-end, donc je quitte souvent la présentation entièrement à quelqu'un d'autre). Je trouve que les systèmes de base de données relationnels ne supportent pas l'héritage sans beaucoup de relations de 1 à 1 à d'autres tables.
Si je concevez à partir d'un point de vue conceptuel, un administrateur est un utilisateur est une personne. À partir de la base de données UP, un administrateur est un utilisateur avec Userype = "Administrator". Rapprocher ces approches me semble difficile, et donc je n'utilise donc que l'héritage avec des objets non persistants.
Quel est le problème avec ma pensée? Pourquoi l'héritage est-il un tel aspect célébré de OO s'il a ces incompatibilités inhérentes aux structures relationnelles traditionnelles? Ou, est-ce que c'est moi qui ne correspond pas correctement à la héritage des données relationnelles? Y a-t-il des conseils qui pourraient préciser cela pour moi?
Désolé pour la question de Rambling et merci d'avance pour vos réponses. Si vous incluez le code dans votre réponse, c # est ma "langue maternelle".
11 Réponses :
Il existe de nombreuses façons d'exprimer ce type de relation dans C #. Les bases de données relationnelles sont tout simplement plus limitées (ce qui peut être un avantage ainsi qu'un inconvénient). Lorsque vous concevez une hiérarchie d'objet qui va être persistée dans une base de données, je constate qu'il est généralement plus facile de commencer par un schéma de base de données, car pratiquement n'importe quel schéma de base de données peut être facilement mappé sur les relations d'objet, alors que l'inverse n'est pas nécessairement le cas.
Dans ce cas particulier, vous pouvez modéliser l'administrateur avec la composition. Votre table des administrateurs fournirait tout état d'administrateur supplémentaire plus la clé de l'utilisateur approprié. Les utilisateurs FK seraient également vos administrateurs PK.
Il existe différents types d'héritage. Les développeurs peuvent penser en termes d'interfaces et de comportements.
Dans votre monde Qu'est-ce que cela signifie d'avoir un "Usertype" d'administrateur? P>
La sémantique que vous êtes impliquant que certains code quelque part considèrent que Usertype et autorise les actions pour les utilisateurs avec ce type. Donc peut-être qu'un administrateur peut créer d'autres utilisateurs? P>
auquel cas un développeur peut avoir un utilisateur de classe P> et un administrateur de classe avec une capacité supplémentaire class Administrator() extends User { createUser() {...}; approvePurchase() {...} }
C'était juste un exemple. N'hésitez pas à remplacer par Milkman: employé vs Employeeype = "Milkman"
Je pense que ça fait peu de différence. Mon affirmation est que si le modèle d'objet nécessite une héritage, il est très probable que les membres hiérarchiy diffèrent également dans leurs données. Cartographie de la hiérarchie à une table ou de nombreux nombreux est un détail de mise en œuvre d'une perspective OO.
Ceci a été publiquement appelé la héritage de schéma - la plupart des bases de données relationnelles ne prennent pas en charge le schéma héritage. Bien qu'une telle caractéristique puisse être ajoutée en théorie pour réduire le conflit avec OOP, les promoteurs relationnels sont moins susceptibles de croire à l'utilité des taxonomies hiérarchiques et de la sous-dactylographie, car ils ont tendance à afficher des taxonomies ou des systèmes de classification inspirés de manière plus puissante et flexible. que les arbres. Les défenseurs de OO soulignent que les modèles d'héritage / de sous-typing ne doivent pas nécessairement être limités aux arbres (même s'il s'agit d'une limitation de nombreuses langues populaires de OO tels que Java), mais des solutions OO non arborées sont considérées comme plus difficiles à formuler que la variation fondée. Les techniques de gestion de thème sur le thème ont préféré par relation relationnelle. Au moins, ils diffèrent des techniques couramment utilisées dans l'algèbre relationnelle.
Voir aussi: Data Agile , C2 Wiki
Et ce mot est: idiot. Je rigole.
Vous devriez lire le Modèles d'architecture d'applications d'entreprise . Il vous montrera comment les modèles d'héritage peuvent et doivent être exprimés des structures relationnelles.
Il y a un Tutoriel sur ce type de chose ici.
Le golfe entre le paradigme relationnel et le paradigme de OO est souvent discuté.
Fondamentalement, pour fournir un mappage entre les RDBM et OO, vous devez sacrifier certaines capacités de les systèmes . Vous devez décider quel côté votre compromis est plus lourdement pondéré.
Les deux paradigmes sont très puissants et utiles. Mais en essayant de cartographier entre eux transparent de manière transparente un problème non résolu.
Oui, l'héritage n'est probablement pas le bon outil lorsque vous mappiez vers et depuis la base de données.
Héritage est beaucoup plus utile lorsque vous développez des cadres, où vous avez différents types d'objets qui se comportent différemment, mais ils ont toujours des pièces en commun.
Par exemple, vous pouvez avoir des "messages" différents passés entre un serveur et un autre. Chaque message a sa propre logique, de sorte que vous avez besoin de classes différentes (pour éviter une énorme déclaration de commutation), mais il y a des parties communes, comme le fait que chaque message a besoin de savoir comment sérialiser / désérialiser elle-même dans un flux (qui est un Méthode Toutes les sous-classes du message doivent remplacer). Aussi, avoir tous les messages héritez que le message vous permettra d'avoir une liste et d'y aller un à un et d'appeler leur méthode Serialize, par exemple.
Mais si tout ce que vous faites est la logique d'affaires / dB typique, l'héritage sera probablement dans votre chemin.
Quelle ... Umm complet et total ... je veux dire que je suis respectueusement en désaccord. Il existe de nombreux cadres ORM qui vous permettent de ma cartographie de la hiérarchie de votre objet aux SGBDM relativement sans douleur en utilisant diverses stratégies. Et la seule raison pour laquelle l'héritage «se tenir dans la voie de la logique des affaires» est s'il est conçu par des codeurs inepte (aucune infraction; ce n'est pas dirigé contre vous personnellement). Vous pensez, je ne dis pas que POOP devrait toujours être utilisé dans des applications métier - mais cela ne "est pas certainement" debout ".
Daniel a un point, car l'héritage est une liaison plus forte entre deux classes (définitions de lignes) qu'un pointeur (clé étrangère). Une clé étrangère est essentiellement un pointeur. Il s'agit donc de la composition par rapport à l'héritage, où la composition est l'option la plus flexible.
Pourquoi l'héritage est-il un tel aspect célébré de OO s'il a ces incompatibilités inhérentes à structures relationnelles traditionnelles?
C'est une citation curieuse - pourquoi dites-vous que les structures relationnelles sont "traditionnelles"? Ils sont la norme dans une SGBDM, par nature, mais j'ai vu très peu de bibliothèques relationnelles dans le contexte d'une langue non-dB.
La raison pour laquelle OO est populaire est parce qu'il s'agissait d'une amélioration significative sur le modèle de procédure dominant. En utilisant l'héritage, le code pourrait être rendu plus fiable (par type de vérification de type), plus facilement modifiable (par le biais de spécialisations de la méthode) et plus testable (à travers des comportements faciles). Comparé à un modèle de procédure, OO est beaucoup plus facile à développer un logiciel de haute qualité avec.
Il y a bien sûr des difficultés dans la cartographie entre les modèles OO et relationnels. Ceci s'appelle "inadéquation relationnelle", a été nommé "Le Vietnam de l'informatique" . Il existe différentes stratégies pour stocker des données OO dans une base de données relationnelle, mais aucune n'est parfaite - les plus populaires dans l'utilisation moderne sont des cadres basés sur le Modèle d'enregistrement actif .
"C'est une citation curieuse - pourquoi dites-vous que les structures relationnelles sont" traditionnelles "?" Je suppose que je pourrais qualifier ma déclaration davantage pour inclure "Logiciels de la ligne d'entreprise". J'oublie que tout le monde ne fait pas des applications qui se connectent aux bases de données :)
Sans oublier que l'OOP est plus âgée que le modèle relationnel.
Les schémas de base de données relationnels normalisés ne soutiennent vraiment pas le polymorphisme à moins que vous ne soyez en dehors de ce qui est généralement considéré comme des «meilleures pratiques» dans le monde du DBA. Ce n'est pas un nouveau problème de quelque manière que ce soit et le problème lui-même a été résolu mille fois de différentes manières.
Le problème réel est mis en place lorsque vous commencez à travailler avec les données - si vous travaillez avec des jeux de données, vous allez continuer à faire des difficultés à essayer de mettre en œuvre une sorte de polymorphisme. Si toutefois que vous mappiez un ensemble d'entités de domaine sur votre modèle relationnel, vous trouverez de nombreux outils pour vous aider à surmonter les limitations du schéma de base de données relationnelle.
Puisque vous êtes un développeur C #, vous devriez probablement commencer en examinant les 2 projets suivants, dont l'un est livré avec le dernier service pack .NET.
Cadre d'entité ADO.NET:
http://msdn.microsoft.com/en-us/library /bb386876.aspx
NHibernate:
Votre exemple spécifique d'un administrateur étant un utilisateur avec un utilisateur de "administrateur" est un excellent exemple du "Héritage de la table unique" motif. Ceci est mis en œuvre dans certains des principaux orateurs. Particulièrement "rails activerecord" et hibernate.
Je dirais que le modèle d'héritage dans la question est imparfait. C'est trop littéral ou basé dans le monde réel. Oui, on pourrait faire valoir que je suis un administrateur dans le monde réel et donc un administrateur est une personne . Cependant, la conception et l'héritage des objets devraient être davantage basés sur des comportements exprimés et partagés dans l'espace de code. J'irais plus l'itinéraire qu'un utilisateur a un rôle. L'administrateur est un rôle ou une instance d'un rôle défini à un certain État. Un utilisateur n'est pas une personne (votre travail de lot peut avoir besoin d'un compte d'utilisateur par exemple).
Je recommande de lire l'objet en pensant à David West pour une bonne introduction à la conception de l'objet. Il ne couvre pas la relation de la relation objet cependant, mais les gens ont déjà donné de nombreux liens vers des ressources sur ce sujet.
Beaucoup de programmes n'utilisent pas de SGBDM.
Administrateur est un utilisateur est une personne (look, ma - pas d'héritage) fonctionne absolument grand jusqu'à un point où l'utilisateur doit avoir un utilisateur / mot de passe / conseil / aucune propriété que la personne ne dispose pas et que l'administrateur a besoin d'avoir encore plus de choses spécifiques. . Comment concevez-vous cela dans votre base de données? Même table avec beaucoup de colonnes nullables? Tables séparées liées par (oh noes) un à un? Devinez quoi, les deux approches peuvent être mappées comme des stratégies d'héritage :-)