J'ai été la programmation dans les langages orientés objet depuis des années maintenant, mais secrètement je regarde certaines des choses que mes collègues le font avec envie. Beaucoup d'entre eux semblent avoir une certaine intérieure OO instinct que je n'ai pas n'importe comment dur j'ai essayer. J'ai lu tous les bons livres sur OO mais ne peut toujours pas semble se fissurer. Je me sens comme le gars qui a donné de 110% à être un joueur professionnel de football, mais n'a tout simplement pas le talent pour le faire. Je suis à une perte et de la pensée de carrières de commutation - que dois-je?
Réponses
Trop de publicités?
Je dirais moins d'accent sur la programmation orientée-objet et de se concentrer plus sur le OO design. Prenez un papier et un crayon (ou peut-être un langage de modélisation UML de l'outil), et de s'éloigner de l'écran.
En pratiquant à la conception d'un système, vous allez commencer à obtenir une sensation naturelle pour les relations d'objet. Le Code est juste un sous-produit de la conception. Dessiner des diagrammes et le modèle de votre application dans un but purement non sous forme de code. Quelles sont les relations? Comment vos modèles interagissent-ils? Ne pensez même pas le code.
Une fois que vous avez passé du temps à la conception de... puis de le traduire en code. Vous serez surpris de voir combien rapidement le code peut être écrit à partir d'un bon OO design.
Après beaucoup de pratique en matière de conception, vous allez commencer à voir des espaces communs qui peuvent être modulaire ou abstraite, et vous verrez une amélioration dans les deux de vos projets et de votre code.
Andrew Siemer
Points
7226
Le moyen le plus facile est d'apprendre des concepts tels que les SOLIDES, SÈCHES, d'AJUSTEMENT, d'DDD, TDD, MVC, etc. Comme vous le look de ces acronymes, il vous mèneront vers de nombreux autres trous de lapins et une fois que vous avez terminé votre lecture, vous devriez avoir une bonne compréhension de ce qui mieux la programmation orientée objet est!
SOLIDE podcasts: http://www.hanselminutes.com/default.aspx?showID=168, http://www.hanselminutes.com/default.aspx?showID=163
SOLIDE ventilation: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
SEC: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
AJUSTEMENT: http://www.netwellness.org/question.cfm/38221.htm
DDD lecture obligatoire: http://www.infoq.com/minibooks/domain-driven-design-quickly
TDD: http://en.wikipedia.org/wiki/Test-driven_development
MVC: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Et oui, retrousser vos manches et de codage est toujours une bonne idée. Faire un petit projet pour le meilleur de vos capacités actuelles. Ensuite lu un article à partir de ci-dessus. Ensuite restructurer le code afin de répondre aux besoins de ce que vous venez de lire. Répétez jusqu'à ce que vous avez refait l'enfer hors de votre code. À la fin vous doit non seulement savoir ce que OO est tout au sujet, mais vous devriez être en mesure d'expliquer pourquoi il est important et comment obtenir de leurs la première fois. Apprendre à refactoriser est une des clés du bon code. Ce qui est juste n'est pas de droit de demain.
jalf
Points
142628
Ma suggestion serait d'apprendre quelque chose de différent.
Apprendre la programmation fonctionnelle, et d'appliquer ce que vous apprenez de celui de la programmation orientée objet. Si vous connaissez le C++, jouer avec programmation générique.
Apprendre la non-langages orientés objet.
Pas seulement parce que vous devez utiliser toutes ces choses ainsi (vous devriez), ou parce qu'ils doivent remplacer complètement la programmation orientée objet (ils probablement ne devrait pas), mais parce que vous pouvez appliquer les leçons de ces à la programmation orientée objet.
Le secret de la programmation orientée objet est qu' il n'est pas toujours de sens pour l'utiliser. Tout n'est pas une classe. Pas chaque relation ou un morceau de comportement doit être modélisée comme une classe.
Aveuglément en essayant d'appliquer la programmation orientée objet, ou en s'efforçant d'écrire le meilleur de la programmation orientée objet code possible tend à conduire à d'énormes overengineered mess avec beaucoup trop de niveaux d'abstraction et d'indirection et très peu de flexibilité.
N'essayez pas d'écrire du bon code de la POO. Essayez d'écrire du bon code. Et l'utilisation de la programmation orientée objet lorsqu'il contribue à cet objectif.
Bill Karwin
Points
204877
Dans de nombreux domaines, il y a un "eureka" moment où tout vient ensemble.
Je me souviens de se sentir frustré à l'école secondaire de la géométrie. Je ne savais pas à qui le théorème s'applique sur chaque étape de la preuve. Mais j'ai continué. J'ai appris chaque théorème dans le détail, et a étudié la façon dont ils ont été appliqués dans les différents exemple de preuves. Ce que j'ai compris non seulement la définition de chaque théorème, mais comment l'utiliser, j'ai construit une "boîte à outils" de familiers des techniques que j'ai pu en tirer.
Je pense que c'est la même chose dans la programmation. C'est pourquoi les algorithmes, structures de données, et les modèles de conception sont étudiés et analysés. Il ne suffit pas de lire un livre et obtenir la définition abstraite d'une technique. Vous devez le voir en action.
Donc, essayez de lire plus de code, en plus de pratiquer l'écriture elle-même. C'est une beauté de l'open source, vous pouvez télécharger un bon nombre de code pour l'étudier. Pas tous du même code est bon, mais l'étude mauvais code peut être tout aussi éducatif que l'étude du bon code.
Achim
Points
6912
Apprendre une autre langue! La plupart des développeurs utilisant uniquement Java (juste un exemple) n'ont qu'une compréhension limitée de OO parce qu'ils ne peuvent pas séparer les fonctions du langage et des concepts. Si vous ne le connaissez pas encore, jetez un oeil à python. Si vous connaissez python, apprendre Ruby. Ou choisissez l'un des langages fonctionnels.
