Pourquoi les classes dérivent implicitement que l'objet de classe?

Question

Je n'ai aucun argument adverse pourquoi nous avons besoin que d'une seule classe universelle. Mais pourquoi ne pas nous avons deux classes universelles, disons un objet et une classe AntiObject. Dans la nature, et que nous trouvons dans la science le concept de la dualité - comme l'énergie et Dark Energy; Homme Femme; Plus moins; Multiplier et Diviser; Électrons & Protons; Intégration et Dérivation; et en théorie des ensembles. Il y a tant d'exemples de dualisme qu'il est une philosophie en soi. En soi, nous voyons la programmation anti-modèles qui nous permet d'effectuer des travaux contrairement à la façon dont nous utilisons les modèles de conception. Je ne suis pas sûr, mais l'utilité de ce concept de dualité réside peut-être dans la création d'éboueurs qui créent AntiObjects qui se combinent avec des objets libres ou en vrac pour se détruire, libérant ainsi la mémoire. Ou peut-être AntiObjects travailler avec les objets pour créer un langage de programmation automodifiant - qui nous permet de créer un code auto modification sécurité, font l'informatique évolutive en utilisant la programmation génétique, ne cachant du code pour éviter l'ingénierie inverse.

Nous appelons la programmation orientée objet. Est-ce un facteur limitant ou est-il quelque chose de fondamental qui me manque dans la compréhension de la formation des langages de programmation?

Answer 1

Ceci est seulement une réponse à répondre à la question dans le titre.

Les langages tels que Java ont toutes les classes provenant de l'objet pour deux raisons.

Tout d'abord, pour augmenter la quantité de polymorphisme disponible. Cela a été particulièrement nécessaire avant que les médicaments génériques ont été ajoutés à la langue. Sans objet, les classes de collecte serait impossible d'écrire de façon utile.

En second lieu, il existe de nombreuses méthodes que les classes sont censés avoir ou sont utiles, et ceux-ci sont recueillies dans l'objet. En veillant à ce que toutes les classes héritent de l'objet, toutes les classes implémenter la même interface minimale.

Comme mentionné dans un commentaire, C ++ ne dispose pas d'une classe comme objet. C ++ est à bien des égards typées, de sorte que les questions que je mentionne ci-dessus ne sont pas applicables. En outre, les modèles C de fournir beaucoup de polymorphisme et sont utilisés pour mettre en œuvre des collections.

Answer 2

Je pense que les couvertures de réponse acceptée à peu près la question initiale, mais je voudrais le compléter (si je peux me permettre) un peu en jetant (tout à fait informelle) quelques idées sur les questions secondaires.

D'un point de vue de l'héritage, rien n'empêche la hiérarchie des classes d'avoir plusieurs racines. Comme il a été souligné par d'autres peuples, C ++, ainsi que de nombreuses langues OO ne pas contrainte d'expressivité à une seule classe ancêtre racine.

Cependant, à partir d'un type théorétique point de vue (rappelons que l'héritage et le sous-typage ne sont pas la même chose, donc je suis probablement en train de sortir du cadre de la question principale ici), un seul " top » peut faire supertype beaucoup de sens (selon la théorie du type de cours). Par exemple, en OCaml, il y a un super-type commun à tous les objets (que ce soit des instances de classe, ou des objets immédiats), écrit < > pour indiquer que le type d'objet est vide, à savoir n'accepte aucun message. Cela semble en effet le plus type d'objet général, nous pouvons définir, puisque nous ne pouvons pas enlever quoi que ce soit de lui pour le rendre plus général. Par conséquent, dans cette conception de types d'objets, il y a nécessairement un super-type à tous les objets.

En ce qui concerne le double de l'objet racine, sports scala une classe appelée Nothing, qui est aussi vide curieusement, et est le sous-type de toutes les autres classes. Il ne peut pas être instancié, mais tient assez utile sémantique pour mettre en œuvre la liste vide, qui est appelée Nil, et est égal à List[Nothing] (comme sur pointe dans les commentaires, il est possible que programmeur ne jamais utiliser directement cette valeur dans la plupart des cas, ce qui en fait apparemment pas aussi utile que ce soit). Nothing pourrait être considéré comme un double du type racine -. appelée Any SCALA, mais ces types couvrent non seulement les classes, mais aussi primitives types, de sorte que tout peut être upcasted à Any, par exemple

Answer 3

La possibilité de définir des collections qui peuvent contenir des types arbitraires de choses, sans avoir besoin de définir différentes méthodes pour différents types de choses, est très utile. Modèles en C ++ rendre possible pour un seul fichier source pour définir les types de collections qui peuvent contenir différents types de choses, mais le compilateur devra dupliquer le code pour tous les différents types de choses dans la collection. Si, au contraire on définit presque tous les types du système pour dériver d'un seul type, puis une collection qui peut contenir des références à des choses de ce type sera en mesure de contenir des références à des choses de presque tous les types.

Cette approche présente toutefois une limitation, ce qui est qu'il brouille les distinctions entre les valeurs et les entités. Une référence qui encapsule une valeur en identifiant un objet particulier peut être remplacée par une référence à une copie de cet objet sans modifier sa sémantique. Une référence qui sert à identifier une entité, cependant, ne peut pas être remplacé dans ce mode. L'organisation même sera quelque chose qui ne peut être copié (par exemple si elle représente une connexion à quelque chose dans le monde réel) ou l'entité peut encapsuler l'ensemble des références qui existent à ce . Une chose clé à noter est que les objets se comportent comme des valeurs lorsque l'on ne peut changer ou qu'une seule référence existe pour les, et ils se comportent comme des entités lorsque plusieurs références existent.

Brouiller la distinction entre les valeurs et les entités, il est difficile pour les types de collecte de savoir si elles doivent considérer leur contenu comme des valeurs ou des entités; à son tour, limite la capacité des collections à mettre en œuvre des choses comme equals ou clone de façon utile. Les langues qui font une plus forte distinction de type / entité peut avoir des collections faire plus de choses automatiquement que les langues qui ne le font pas, mais les distinctions ajouter une certaine complexité, que les concepteurs de langue peuvent ou ne se sentent pas est justifiée par les avantages.