Type de base de données demande: théorie de la conception orientée objet?

Question

J'ai travaillé pendant très longtemps à la conception de bases de données et, de nos jours, je travaille aussi en C #. OO a du sens pour moi, mais je ne pense pas avoir une bonne connaissance de la théorie profonde de la conception OO.

Dans les bases de données, il existe de nombreuses théories sur la conception de la structure d’une base de données, la notion principale étant la normalisation. La normalisation dirige directement la structure d'une base de données et, dans une certaine mesure, indique comment organiser les entités dans une base de données.

Existe-t-il des concepts similaires pour concevoir la structure d’un programme orienté objet?

Ce que je recherche, c’est un ou plusieurs principes théoriques sous-jacents qui guident naturellement le développeur dans le "correct". conception pour la solution à un problème donné.

Où puis-je chercher pour en savoir plus?
Y a-t-il un travail que je devrais lire?

Mise à jour:

Merci à tous pour leurs réponses. Ce que je lis semble dire qu'il n'y a pas de "grande théorie du design OO", mais il existe toute une série de principes importants, qui sont largement illustrés par les modèles de conception.

Merci encore pour vos réponses:)

Answer 1

Faites attention à la littérature sur les modèles de conception.

Il existe plusieurs grandes espèces de définitions de classe. Les classes pour les objets persistants (qui ressemblent aux lignes dans les tables relationnelles) et les collections (qui sont comme les tables elles-mêmes) sont une chose.

Certains des " bande de quatre " les modèles de conception sont plus applicables aux objets d'application actifs et moins applicables aux objets persistants. Si vous vous battez pour quelque chose comme Abstract Factory , il vous manquera quelques points clés de la conception orientée objet tels qu'ils s'appliquent aux objets persistants.

Le mentor des objets Qu'est-ce que la conception orientée objet? a beaucoup à vous besoin de savoir pour passer de la conception relationnelle à la conception OO.

La normalisation, BTW, n’est pas un principe de conception général qui s’applique toujours aux bases de données relationnelles. La normalisation s'applique lorsque vous avez des transactions de mise à jour, afin d'éviter les anomalies de mise à jour. C'est un hack car les bases de données relationnelles sont des choses passives; vous devez soit ajouter un traitement (comme des méthodes dans une classe), soit passer un tas de règles (normalisation). Dans le monde de l'entrepôt de données, où les mises à jour sont rares (ou inexistantes), les règles de normalisation standard ne sont pas aussi pertinentes.

Par conséquent, il n'y a pas de "normaliser comme ceci" pour les modèles de données objet.

Dans OO Design, la règle la plus importante pour la conception d'objets persistants est le principe de responsabilité unique. .

Si vous concevez vos classes de manière à rester fidèles aux objets du monde réel, et , vous leur attribuez des responsabilités de manière très ciblée, vous serez satisfait de votre modèle d'objet. Vous pourrez le mapper sur une base de données relationnelle relativement peu complexe.

Il s'avère que lorsque vous examinez les choses du point de vue de la responsabilité, vous constatez que les règles 2NF et 3NF vont de pair avec une affectation rationnelle des responsabilités. Les clés uniques comptent toujours. Et les données dérivées deviennent la responsabilité d'une fonction de méthode et non d'un attribut persistant.

Answer 2

Le livre "Design Patterns" est votre prochaine étape.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley -Professionnel / dp / 0201633612

Mais vous n’avez pas à utiliser une approche orientée objet pour tout. Ne soyez pas religieux à ce sujet. Si une approche plus procédurale vous semble plus restrictive, optez pour cela. Les nouveaux venus chez OO ont tendance à attendre depuis longtemps.

Answer 3

Je pense que le développement de logiciels agiles, les principes, les modèles et les pratiques sont assez bon.

Il fournit de nombreuses informations détaillées sur les principes OO énumérés dans ici :

• Les principes de la conception orientée objet et de la gestion de la dépendance
• SRP - Le principe de responsabilité unique
• OCP - Le principe d'ouverture fermée
• LSP - Le principe de substitution de Liskov
• DIP - Principe d'inversion de dépendance
• ISP - Le principe de séparation des interfaces
• REP - Principe d'équivalence de la réutilisation et de la réutilisation
• CCP - Le principe de fermeture commun
• CRP - Le principe commun de réutilisation
• ADP - Principe des dépendances acycliques
• SDP - Principe des dépendances stables
• SAP - Le principe des abstractions stables

Answer 4

Si vous avez l'habitude de créer des bases de données normalisées, la conception orientée objet devrait vous venir naturellement. Vos structures de classe ressembleront beaucoup à votre structure de données, à l’exception évidente que les tables d’association se transforment en listes et que les tables de recherche se transforment en énumérations au sein de vos classes.

Dans l’ensemble, je dirais que vous feriez bien mieux de vous lancer dans la conception OO avec une expérience dans les bases de données relationnelles que d’aller dans le sens opposé.

Answer 5

Si vous voulez vraiment vous familiariser avec O-O, jouez avec Smalltalk . ST est un langage pur OO, et il est parfaitement compréhensible. Une fois que vous avez surmonté le paradigme, vous avez appris OO, car vous ne pouvez pas vraiment faire du Smalltalk sans lui. C’est ainsi que j’ai appris pour la première fois OO.

Answer 6

Vérifiez les résultats de this . Apprenez de chaque question.

Answer 7

J'ai vraiment aimé les premiers modèles de conception , qui est très abordable, et l'excellent Heuristique de conception orientée objet par Arthur J. Riel

Answer 8

Ce site répertorie 101 titres ... modèles de conception, refactoring et autres. .. Jetez-y un coup d'œil .. Ce sera un bon point de départ ...

Answer 9

Optez pour la pensée objet par David West. Une lecture intéressante ..
Vous êtes du côté obscur, bien que… comme l'indique le livre;) La pensée de la base de données a été la malédiction des programmeurs OO partout. Ils sont les extrémités opposées d'un spectre. Par exemple

• La pensée de base de données valorise les attributions de données par rapport à tout le reste. normalisation et création de types en fonction de leur intégration dans le schéma de base de données ou le diagramme ER. La pensée OO crée des types basés sur le comportement et la collaboration et ne reconnaît pas les attributs de données. tout important.
• Les bases de données proviennent des scientifiques qui attachent de l'importance à la formalisation et à la méthode par-dessus tout. OO provient des personnes qui utilisent des méthodes heuristiques et des règles empiriques et qui valorisent l’individualité et les interactions sociales au cours d’un processus rigoureux.

Le point de vue d’un programmeur COBOL peut écrire des programmes COBOL même après être passé à un langage OO. Découvrez un livre comme Thinking in Java pour la première section, qui détaille invariablement les principes de OO (Apprentice) .. Continuez avec Object Thinking (compagnon) et en temps voulu .. un maître.

Answer 10

Modélisez vos objets en gardant à l'esprit des objets du monde réel.

Nous développons actuellement un logiciel d'automatisation pour les machines. Une de ces machines possède deux ports de chargement pour l’alimentation en matières premières, alors que toutes les autres n’en ont qu’un. Jusqu'ici, dans tous les modules, nous avions les informations des ports (paramètres actuels, numéro de lot qui lui est attribué, etc.) en tant que membres de la classe représentant la machine.

Nous avons décidé de créer une nouvelle classe contenant les informations des ports et d'ajouter deux membres LoadPort à cette classe MachineXY. Si nous avions déjà pensé à cela, nous aurions fait de même pour toutes ces machines à port unique ...

Answer 11

Vous devriez regarder UML, qui est un processus complet attribué à OOD.

Je vous conseillerais de vous procurer un livre (ou un couple), car la théorie est assez large, la plupart des gens choisissent les techniques les plus appropriées au projet en question.

Answer 12

Commencez à lire sur les modèles de conception, d'après Martin Fowler. :)

C’est l’utilisation la plus pratique de la POO.

Answer 13

Je suppose que vous voulez dire OO dans le monde des bases de données.

Les bases de données orientées objet qui stockent des objets n’en ont jamais vraiment capturé un; Le mappage ORM ou Object-Relational est le terme utilisé pour décrire le logiciel qui effectue ce mappage. Idéalement, cela vous donne le meilleur des deux mondes, où les développeurs peuvent interagir avec les objets. Dans la base de données, tout est stocké dans des tables relationnelles pouvant être optimisées.

Answer 14

dans argot DBA: la conception orientée objet n’est rien d’autre que des données correctement normalisées derrière des interfaces de fonctionnement sûres, une signification sûre, examinez les opérations, pas les données directement