Ce qui fait un langage Orienté Objet?

Définitions pour l'Orientation de l'Objet sont bien sûr un énorme boîte de pandore, mais voici mes 2 cents:

Pour moi, l'Orientation de l'Objet est sur tous les objets qui collaborent par l'envoi de messages. C'est, pour moi, la seule et la plus importante caractéristique d'un langage orienté-objet.

Si je devais mettre en place une liste ordonnée de toutes les fonctionnalités d'un langage orienté objet doit avoir, il devrait ressembler à ceci:

1. Les objets de l'envoi de messages à d'autres objets
2. Tout est un Objet
3. La Liaison Tardive
4. Sous-Type De Polymorphisme
5. Héritage ou quelque chose de la même façon expressive, comme Délégation
6. L'Encapsulation
7. Se Cacher De L'Information
8. Abstraction

Évidemment, cette liste est très controversé, puisqu'il exclut une grande variété de langues qui sont largement considérés comme étant orientée objet, comme Java, C# et C++, tout en violant les points 1, 2 et 3. Cependant, il ne fait aucun doute que ces langages permettent de programmation orienté-objet, mais le fait de C) et même de faciliter (qui C qui ne marche pas). Donc, j'en viens à l'appel de langues que de répondre à ces exigences "purement orienté objet".

Comme l'archétype des langages orientés objet, j'appellerais Auto et Novlangue.

À la fois satisfaire les exigences mentionnées ci-dessus. Les deux sont inspirés par et les successeurs de Smalltalk, et les deux arrivent à être "plus OO" dans un certain sens. Les choses que j'aime à propos de l'Auto et de la Novlangue sont que de prendre le message de l'envoi d'un paradigme à l'extrême (Novlangue même plus que Moi).

En Novlangue, tout est un message envoyer. Il n'y a pas de variables d'instance, pas de champs, pas d'attributs, sans constantes, pas de noms de classe. Ils sont tous des émules en utilisant les getters et les setters.

Dans l'Auto, il y a pas de classes, seuls les objets. Cela met en évidence, ce que l'OO est vraiment sujet: les objets, et non des classes.

Essentiellement Orientée Objet vraiment se résume à "passage de messages"

Dans un langage procédural, j'appelle une fonction comme ceci :

  f(x)

Et le nom de f est probablement lié à un bloc de code particulier au moment de la compilation. (Sauf si c'est un langage procédural avec des fonctions d'ordre supérieur ou de pointeurs de fonctions, mais laisse ignorer que la possibilité d'une seconde.) Donc cette ligne de code ne peut signifier qu'une sans ambiguïté chose.

Dans un langage orienté objet, je passe un message à un objet, peut-être comme ceci :

 o.m(x) 

Dans ce cas. m n'est pas le nom d'un bloc de code, mais un "sélecteur de la méthode" et le bloc de code est appelé dépend en réalité de l'objet o, d'une certaine façon. Cette ligne de code est plus ambigu ou général, car il peut avoir des significations différentes dans des situations différentes, en fonction de l'o.

Dans la majorité des langages à objets, l'objet o a une "classe", et la classe détermine le bloc de code est appelé. Dans un couple des langages à objets (le plus célèbre, Javascript) o n'a pas de classe, mais a des méthodes directement attaché à elle au moment de l'exécution, ou a hérité d'un prototype.

Mon démarcation, c'est que ni les classes ni d'héritage sont nécessaires pour qu'une langue soit OO. Mais ce polymorphes gestion des messages est essentiel.

Bien que vous pouvez simuler cet effet avec des pointeurs de fonction en C, ce n'est pas suffisant pour la C d'être appelé un langage OO, parce que vous allez avoir à mettre en place votre propre infrastructure. Vous pouvez le faire, et un OO style est possible, mais la langue n'a pas donné pour vous.

Smalltalk est généralement considéré comme l'archétype du langage OO, bien que Simula est souvent cité comme étant le premier langage OO.

Courant OO langues peuvent être vaguement classés par langue, ils empruntent la plupart des concepts à partir de:

• De Smalltalk-comme: Ruby, Objective-C
• Simula-like: C++, Pascal Objet, Java, C#

Prend en charge les classes, méthodes, attributs, l'encapsulation, les données de la clandestinité, de l'héritage, le polymorphisme, l'abstraction...?

À ce que la bai a dit, je dirais qu'une langue n'est pas vraiment orienté objet, à moins que les bibliothèques standard disponibles sont orientées objet. Le plus grand exemple de ceci est PHP. Bien qu'il prend en charge tous les standards des concepts orientés objet, le fait qu'un grand pourcentage de la norme de bibliothèques ne sont pas orientées objet, signifie qu'il est presque impossible d'écrire votre code dans un objet orienté vers les.

Il n'a pas d'importance qu'elles mettent en place des espaces de noms si toutes les bibliothèques standard vous exiger de préfixe de tous vos appels de fonction avec des trucs comme mysql_ et pgsql_, lorsque, dans un langage soutenu les espaces de noms dans l'API, vous pourriez se débarrasser de fonctions mysql_ et ont juste un simple "inclure système.db.mysql.*" en haut de votre fichier de sorte qu'il serait de savoir où ces choses sont venus.

Dans mon expérience, les langues ne sont pas orienté objet, le code est.

Il y A quelques années j'ai écrit une série de programmes en AppleScript, qui n'a pas vraiment d'appliquer toutes les fonctionnalités orientées objet, quand j'ai commencé à grok OO. Il est maladroit d'écrire des Objets en AppleScript, mais il est possible de créer des classes, constructeurs, et ainsi de suite si vous prenez le temps de trouver comment.

La langue était la langue correcte pour le domaine: l'obtention de différents programmes sur le Macintosh à travailler ensemble pour accomplir certaines automatique de tâches basées sur des fichiers d'entrée. Prendre la peine de s'auto-appliquer un style orienté objets était le bon choix de programmation, car il a entraîné dans le code plus facile à dépanner, de tester et de comprendre.

La fonction que j'ai remarqué que la plupart de changer le code de procédure pour OO a été encapsulation: à la fois des propriétés et des appels de méthode.

Objet: un objet est un référentiel de données. Par exemple, si ma liste est une liste d ' achats de l'objet, Maliste pouvez enregistrer votre liste de courses.

Classe: Une classe est un type d'objet. Beaucoup d'objets de la même classe peuvent exister; par exemple, Maliste et YourList peut à la fois être liste d ' achats d'objets.

Méthode: une procédure ou Une fonction qui fonctionne sur un objet ou d'une classe. Une méthode est associée à une classe particulière. Par exemple, addItem peut être une méthode qui ajoute un élément à n'importe quel liste d ' achats de l'objet. Parfois, une méthode est associée à une famille de classes. Par exemple, addItem peut fonctionner sur n'importe quelle Liste, dont une liste d ' achats est juste un type.

De l'héritage: Une classe peut hériter des propriétés d'une classe plus générale. Par exemple, la liste d ' achats de classe hérite de la classe List la propriété de stocker une séquence d'éléments.

Polymorphisme: La possibilité d'avoir un appel de méthode de travail sur plusieurs classes d'objets, même si les classes ont besoin de différentes implémentations de l'appel de méthode. Par exemple, une ligne de code pourrait être en mesure d'appeler la "addItem" méthode sur chaque type de Liste, même si l'ajout d'un élément à une liste d ' achats est complètement différent de l'ajout d'un élément à un ShoppingCart.

Orienté-objet: Chaque objet connaît sa propre classe et les méthodes de manipuler les objets de la classe. Chaque liste d ' achats et de chaque ShoppingCart connaît la mise en œuvre de addItem s'applique à elle.

Dans cette liste, la seule chose qui distingue vraiment des langages orientés objet à partir de langages procéduraux (C, Fortran, Basic, Pascal) est le polymorphisme.

Source: https://www.youtube.com/watch?v=mFPmKGIrQs4&liste=PL-XXv-cvA_iAlnI-BQr9hjqADPBtujFJd

Archétype

La capacité à exprimer des scénarios du monde réel dans le code.

foreach(House house in location.Houses)
{
 foreach(Deliverable mail in new Mailbag(new Deliverable[]
              {
              GetLetters(), 
              GetPackages(), 
              GetAdvertisingJunk()
              })
 {
    if(mail.AddressedTo(house))
    {
        house.Deliver(mail);
    }
 }
}

-

foreach(Deliverable myMail in GetMail())
{
    IReadable readable = myMail as IReadable;
    if ( readable != null )
    {
        Console.WriteLine(readable.Text);
    }
}

Pourquoi?

Pour nous aider à comprendre plus facilement. Il est plus logique dans nos têtes et s'il est appliqué correctement rend le code plus efficace, réutilisable et réduit à la répétition.

Pour obtenir ce dont vous avez besoin:

• Pointeurs/Références pour s'assurer que cette == ce et ce != qu'.
• Classes à point (par exemple, Bras) qui stockent les données (int hairyness) et des opérations (Throw(IThrowable))
• Polymorphisme (Héritage et/ou des Interfaces) pour traiter des objets spécifiques dans un générique de la mode, donc vous pouvez lire des livres ainsi que des graffitis sur le mur (à la fois de mettre en œuvre IReadable)
• Encapsulation parce que apple n'a pas d'exposer une des Atomes [la propriété]