Les exceptions et les bonnes pratiques. Bien souvent, un programme doit traiter des situations exceptionnelles qui n'ont pas un rapport direct avec sa tâche principale.
Ceci oblige le programmeur à réaliser de nombreux tests avant d'écrire les instructions utiles du programme. Cette situation a deux inconvénients majeurs : Le programmeur peut omettre de tester une condition ; Le code devient vite illisible car la partie utile est masquée par les tests. Java remédie à cela en introduisant un Mécanisme de gestion des exceptions qui est l'objet de cet article. Grâce à ce mécanisme, on peut améliorer grandement la lisibilité du code en découplant le code utile de celui qui traite des situations exceptionnelles, et on peut aussi déléguer au langage la tâche d'énumération des tests à effectuer.
Une situation exceptionnelle peut être assimilée à une erreur (dans le cadre de cet article), c'est à dire une situation qui est externe à la tâche principale d'un programme. IV-A. Il faudrait plutôt écrire ceci : IV-B. IV-C. VI-A. VI-B. VI-C. ArticleS.UncleBob.PrinciplesOfOod. The Principles of OOD What is object oriented design?
What is it all about? What are it's benefits? What are it's costs? It may seem silly to ask these questions in a day and age when virtually every software developer is using an object oriented language of some kind. Of all the revolutions that have occurred in our industry, two have been so successful that they have permeated our mentality to the extent that we take them for granted. Programs written in these languages may look structured and object oriented, but looks can be decieving. In March of 1995, in comp.object, I wrote an article that was the first glimmer of a set of principles for OOD that I have written about many times since.
These principles expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects. Dependency Management is an issue that most of us have faced. The first five principles are principles of class design. The next six principles are about packages. Robert, Denis. An introduction to the SOLID principles of OO design - dave^2 = -1.
I would be very hard pressed to go passed Robert "Uncle Bob" Martin’s SOLID principles as the single most useful tool for helping me with OO design.
Some people seem to have a natural talent for OO design and thinking, and have an innate understanding of these principles without requiring the SOLID formalism. I, on the other hand, find them indispensable. Unfortunately the names used in the somewhat-cryptic "acronym of acronyms"[1] don’t exactly lend themselves to being easily learned (Bob Martin and Scott discussed how this came about on a Hanselminutes episode on SOLID, which is well worth a listen).
I thought I’d post my interpretation of the principles as a refresher for myself, and as an introduction for anyone trying the learn the terminology. I should point out I am far from a guru on this stuff, so if there’s any misinformation in here please point it out in a comment or email, so I can correct the post and learn me some OO :). Single Responsibility Principle Open Closed Principle.