Différences entre «Java OOP» et «Pythonic OOP»? [fermé]

19

J'ai commencé avec ActionScript 2.0, puis j'ai continué avec Java. J'ai appris, ou du moins utilisé, un tas de langues depuis lors, y compris Python (probablement mon préféré).

Je crains cependant que mon style de programmation orientée objet ne soit pas très pythonique, et ressemble plus à Java OOP avec la syntaxe Python. Qu'est-ce qui différencie Java et Pythonic OOP? Quelles choses les programmeurs Java font-ils souvent "de manière non pythonique" lors de l'écriture de code orienté objet en Python?

Anto
la source

Réponses:

54

Pour un gars de Java, Python est un terrain de jeu anarchique où tout le monde peut attraper un club et commencer à se taquiner la tête.

Pour un gars de Python, Java est un univers orwellien où vous êtes constamment enchaîné à la vue décroissante de quelqu'un d'autre sur le fonctionnement de l'univers.

La vérité est tout ce que vous pouvez faire dans une langue, vous pouvez le faire dans l’autre aussi proprement. Cependant, comme vous l'avez mentionné, il existe une différence importante dans les deux communautés quant à ce que signifie propre .

Méthode Java: Un système propre est celui qui fait ce qui est fait et rien d'autre, il ne permettra pas d'extensions ou de modifications qui vont à l'encontre de la nature du but recherché et tentera de les appliquer autant que possible via le compilateur. La flexibilité est obtenue grâce à une fabrication soignée d'interfaces simples dans des structures strictes. En Java, le bac à sable doit toujours être clairement délimité et les dépasser, avec un retour rapide du compilateur. Java fournit des moyens pour définir statiquement des structures d'objets et créer des interactions dynamiques à partir de leurs instances. Lorsque je travaille en Java, j'essaie de créer intelligemment des blocs de construction de base vers une solution mortelle. Je travaille principalement de bas en haut une fois que j'ai une théorie de travail sur la façon de résoudre le problème.

Java aura tendance à produire de gros logiciels pouvant couvrir de grandes équipes et fournissant des outils et des moyens pour garder le troupeau sous contrôle. Si elle n'est pas cochée, cela conduira des équipes très détachées à travailler de manière indépendante vers un objectif toujours plus flou. Finalement, chaque équipe devient sa propre raison d'être et le système dans son ensemble se dilue, entraînant le projet principal. Ceux-ci peuvent entraîner des dépassements de coûts extrêmes et d'énormes systèmes logiciels qui fonctionnent et se maintiennent mal.

Il n'y a presque jamais un petit moyen rapide et facile de faire des choses en Java, mais l'IDE et l'outillage sont là pour faire des tâches pénibles en quelques clics.

Méthode Python: Clean signifie concis et facilement lisible. Un bon système python est conçu pour vous permettre d'aller directement au cœur de celui-ci et d'exposer ses secrets les plus intimes d'une manière que vous pouvez comprendre à partir du code l'utilisation et le but prévus. Il vous permettra également de concevoir votre propre solution en étendant et / ou en encapsulant la conception originale afin qu'elle aille exactement dans votre direction. Python fournit des moyens de créer des modèles d'objets à partir desquels vous pouvez modifier dynamiquement l'instance pour répondre aux besoins actuels. En python, j'ai tendance à résoudre le problème tout de suite, puis à diffuser le code dans une structure logique telle que la solution finale reste aussi simple et lisible que possible. En python, j'ai tendance à travailler de haut en bas et à gérer les complexités croissantes grâce à une approche diviser pour mieux régner.

Les équipes Python auront tendance à produire des systèmes légers et à fournir très rapidement une solution de travail. Ils auront tendance à être un groupe soudé travaillant de manière interchangeable sur n'importe quelle partie du système, validant la solution de chacun à chaque occasion. Ils se nourrissent les uns des autres créant une synergie assez exaltante. Cependant, cela crée des équipes qui sont difficiles à adapter à des systèmes plus grands et qui touchent souvent une sorte de plafond de verre. L'introduction de nouveaux membres dans l'équipe aidera mais il faudra un certain temps pour que les connaissances se propagent suffisamment pour que la productivité supplémentaire se fasse sentir. L'équipe se divise alors et l'aperçu constant de l'ensemble du système se dilue, tout comme l'atmosphère des premiers jours. Cela peut conduire à un code trop alambiqué à ce qui était autrefois un problème simple,

Il existe presque toujours un moyen rapide et facile de faire les choses avec Python, mais la complexité peut être plus difficile à contrôler une fois que le système atteint un certain seuil.

En bref, les deux ont un côté sombre et les deux ont une force claire. Cependant, lorsque vous vous promenez le long des deux communautés, vous constaterez que la force de l'une mène au côté obscur de l'autre et vice versa.

D'où les débats houleux sur lequel est le meilleur.

Newtopian
la source
14

Vous savez donc tout sur la définition de la visibilité des méthodes et des variables? Ouais, ça n'existe plus, tout est public. Il existe des conventions de dénomination et un changement de nom, mais tout est vraiment toujours disponible.

Une partie de la flexibilité de Python vient du fait que vous êtes autorisé à faire presque n'importe quoi. Pour cette raison, la philosophie est que les gens devraient savoir comment utiliser l'API plutôt que l'API imposant qu'une méthode soit utilisée correctement.

Au lieu de surcharges de méthode, vous avez des variables par défaut. N'utilisez pas d'objets mutables comme valeur par défaut.

# bad
def fL(x=[])
  x.append(1)
  print x
# good
def fN(x=None)
  if (x is None):
    x = []
  x.append(1)
  print x

fL()
fL()
fN()
fN()

La différence entre les variables de classe et d'instance est très subtile au premier démarrage.

class Obj(object):
   thing = "class variable"
   def __init__(self):
      self.thing1 = "instance variable"
      print self.thing, self.thing1

Ce sont quelques-unes des choses auxquelles j'ai dû m'habituer lorsque j'ai fait le changement.

unholysampler
la source
1
+1 bon résumé de certaines choses, bien que je connaissais celles d'avant
Anto
6

Eh bien, Python n'a pas d'interfaces, a des métaclasses et permet le typage de canard. Python a des compréhensions de liste, qui sont très puissantes et n'existent pas en Java. Java a un système de type riche avec beaucoup de structures de données, et Python n'a que des listes. Donc, si vous exploitez ce que Python a au lieu d'essayer de recréer ce que Java a en Python, vous écrivez probablement du code Pythonic.

Mais en ce qui concerne le code OO, il existe certains principes fondamentaux de style qui ne doivent pas changer de langue en langue: vous devez toujours vous efforcer d'écrire du code timide et sec, que vous écriviez en Applescript, Python, Java ou C ++.

----Éditer----

Comme le souligne @delnan, il existe en fait CINQ types de données composites définis par Python au niveau du noyau (liste, dict, tuple, set et frozenset, selon ma copie de "Python in a Nutshell"). Bien que cela soit vrai, cela n'est pas vraiment pertinent au point que j'essaie de faire: Python s'appuie sur des listes en tant que structure de données essentielle. Oui, vous POUVEZ utiliser une liste comme pile, mais vous pouvez utiliser exactement la même liste comme file d'attente. Et puis une pile à nouveau.

Java, d'autre part, a une structure de données de noyau (Array, selon "The Java Pocket Guide), mais en général, vous ne pouvez pas faire beaucoup de choses en Java sans importer des collections. Une fois que vous faites cela, vous avez accès à une bibliothèque de type «riche» (dans ce sens, je veux dire immensément complexe) avec laquelle obtenir la même fonctionnalité que vous aviez avec la liste de Python.

Bien sûr, les deux langages ont des classes et Java a des interfaces, mais bien que ce soient des types de données composites, ce ne sont pas vraiment des structures de données au sens d'un manuel.

Une différence est que vous ne pouvez pas extraire un élément d'une file d'attente Java et que vous ne pouvez pas passer un objet de file d'attente Java quelque part qui attend une liste liée Java. Donc peut-être par «riche», je veux dire en fait «rigide».

Donc, pour expliquer ce que je veux dire en disant "Python n'a que des listes", ce que je veux dire, c'est que vous pouvez faire à peu près tout ce que vous devez faire en Python que vous feriez avec des collections Java en utilisant le type de liste Pythons. Ce type unique fait le travail d'un grand nombre de types en Java.

Qu'est-ce que cela signifie pour le programmeur Python? Cela signifie que vous pouvez exploiter le type de liste Python pour écrire du code direct très précis sans utiliser de bibliothèques supplémentaires - et le caractère fin (c'est-à-dire la caractéristique de transmettre plus de valeur en moins de caractères) est une caractéristique essentielle du code "Pythonic". .

philosodad
la source
Je connais tout sauf les métaclasses, je vais les chercher. Merci :)
Anto
7
-1 jusqu'à ce que vous puissiez expliquer ce qui suit: (1) "Python n'a que des listes" - Python possède une multitude de structures de données. Il n'a pas trois implémentations de chaque structure de données unique jamais conçue, mais toujours celle dont la plupart des gens auront besoin. (2) Le fait d'appeler le système de type Java «riche» est une moquerie de ces systèmes de type vraiment sophistiqués. Pour commencer , regardez Haskell (98 sans aucune extension).
Je suis désolé, ce n'est tout simplement pas vrai. Python a exactement deux structures de données: listes et dictionnaires. Certaines BIBLIOTHÈQUES Python peuvent étendre ces structures de base, mais ce n'est pas la même chose que de dire que le langage les a.
philosodad
5
C'est déjà deux fois plus que les noms de réponse. La liste se double d'une pile. Ensembles et tuples sont également intégrés dans (le nombre de structures de données sont intégrées dans Java?) Il y a aussi des modules de la bibliothèque standard pour (min-) tas, Deques, dossiers immuables et des tableaux homogènes bien emballés (limités à C les types). Et c'est juste du haut de ma tête. Oui, la plupart d'entre eux utilisent des listes / dict en interne (cependant, les ensembles ne sont pas des dicts avec des clés inutilisées). Mais il en va de même pour la plupart des collections en Java - en fait, dans toutes les langues. Voilà comment ça marche.
1
Maintenant, je pense que je comprends le point que vous avez essayé de faire (et supprimé mon downvote - que j'ai ajouté en premier lieu parce que cette partie était tout à fait erronée de la façon dont elle avait été initialement énoncée). Je pense toujours que vous devez considérer au moins deux structures de données (les listes comme des séquences presque universelles et les dits comme des mappages presque universels). Et cela sans parler des différents itérateurs et générateurs, que j'utilise au moins aussi (et même plus encore) fréquemment comme listes.