Le livre "Objets élégants. Édition Java »

Salut, habrozhiteli! Ce livre révise sérieusement l'essence et les principes de la programmation orientée objet (POO) et peut être métaphoriquement appelé «POO Lobachevsky». Egor Bugaenko , développeur avec 20 ans d'expérience, analyse de manière critique les dogmes de la POO et propose de regarder ce paradigme d'une manière complètement nouvelle. Ainsi, il stigmatise les méthodes statiques, les getters, les setters, les méthodes mutables, croyant que c'est mal. Pour un programmeur débutant, ce volume peut devenir un éclaircissement ou un choc, et pour un programmeur expérimenté, c'est une lecture obligatoire.

Extrait «N'utilisez pas de méthodes statiques»

Ah, les méthodes statiques ... Un de mes sujets préférés. Il m'a fallu plusieurs années pour réaliser l'importance de ce problème. Maintenant, je regrette tout le temps que j'ai passé à écrire des logiciels procéduraux plutôt que des objets. J'étais aveugle, mais maintenant j'ai vu. Les méthodes statiques sont tout aussi importantes sinon même un problème plus important dans la POO que d'avoir une constante NULL. Les méthodes statiques, en principe, n'auraient pas dû être en Java et dans d'autres langages orientés objet, mais, hélas, elles existent. Nous ne devrions pas connaître des choses telles que le mot-clé statique en Java, mais, hélas, sont forcés .. Je ne sais pas qui les a amenés à Java, mais ils sont du mal absolu .. Les méthodes statiques, pas les auteurs de cette fonctionnalité. Je l'espère.

Voyons quelles sont les méthodes statiques et pourquoi nous les créons toujours. Disons que j'ai besoin de la fonctionnalité de chargement d'une page Web via des requêtes HTTP. Je crée une telle «classe»:

class WebPage { public static String read(String uri) { //  HTTP- //     UTF8- } } 

Il est très pratique de l'utiliser:

 String html = WebPage.read("http://www.java.com"); 

La méthode read () appartient à la classe de méthodes à laquelle je m'oppose. Je suggère d'utiliser un objet à la place (j'ai également changé le nom de la méthode conformément aux recommandations de la section 2.4):

 class WebPage { private final String uri; public String content() { //  HTTP- //     UTF8- } } 

Voici comment l'utiliser:

 String html = new WebPage("http://www.java.com") .content(); 

Vous pouvez dire qu'il n'y a pas beaucoup de différence entre eux. Les méthodes statiques fonctionnent encore plus rapidement, car nous n'avons pas besoin de créer un nouvel objet chaque fois que nous devons télécharger une page Web. Appelez simplement la méthode statique, elle fera le travail, vous obtiendrez le résultat et vous continuerez à travailler. Il n'est pas nécessaire de jouer avec les objets et le garbage collector. De plus, nous pouvons regrouper plusieurs méthodes statiques dans une classe utilitaire et la nommer, par exemple, WebUtils.

Ces méthodes vous aideront à charger des pages Web, à obtenir des informations statistiques, à déterminer le temps de réponse, etc. Elles comporteront de nombreuses méthodes et leur utilisation est simple et intuitive. De plus, la façon d'appliquer des méthodes statiques est également intuitive. Tout le monde comprend comment ils fonctionnent. Écrivez simplement WebPage.read (), et - vous l'avez deviné! - la page sera lue. Nous avons donné des instructions à l'ordinateur, et il l'exécute. Simple et clair, non? Et non!

Les méthodes statiques dans n'importe quel contexte sont un indicateur indubitable d'un mauvais programmeur qui n'a aucune idée de la POO. Il n'y a aucune justification pour appliquer des méthodes statiques dans n'importe quelle situation. Prendre soin de la performance ne compte pas. Les méthodes statiques sont une moquerie d'un paradigme orienté objet. Ils existent en Java, Ruby, C ++, PHP et d'autres langages. Malheureusement Nous ne pouvons pas les jeter, nous ne pouvons pas réécrire toutes les bibliothèques open source pleines de méthodes statiques, mais nous pouvons arrêter de les utiliser dans notre code.

Nous devons cesser d'utiliser des méthodes statiques.

Maintenant, regardons-les de plusieurs positions différentes et discutons de leurs lacunes pratiques. Je peux vous les généraliser à l'avance: les méthodes statiques dégradent la maintenabilité du logiciel. Cela ne devrait pas vous surprendre. Tout se résume à la maintenabilité.

Objective versus Computer Thinking

Initialement, j'ai appelé cette sous-section Objective versus Procedural Thinking, mais plus tard je l'ai renommée. «Pensée procédurale» signifie presque la même chose, mais l'expression «penser comme un ordinateur» décrit mieux le problème. Nous avons hérité de cette façon de penser des premiers langages de programmation tels que Assembly, C, COBOL, Basic, Pascal et bien d'autres. La base du paradigme est que l'ordinateur fonctionne pour nous, et nous lui disons quoi faire, en lui donnant des instructions explicites, par exemple:

  CMP AX, BX JNAE greater MOV CX, BX RET greater: MOV CX, AX RET 

Il s'agit d'une «routine» d'assembleur pour le processeur Intel 8086. Elle trouve et renvoie le plus grand des deux nombres. Nous les mettons respectivement dans les registres AX et BX, et le résultat tombe dans le registre CX. Voici exactement le même code C:

 int max(int a, int b) { if (a > b) { return a; } return b; } 

"Qu'est-ce qui ne va pas avec ça?" - demandez-vous. Rien .. Tout va bien avec ce code - il fonctionne comme il se doit. C'est ainsi que tous les ordinateurs fonctionnent. Ils s'attendent à ce que nous leur donnions des instructions à suivre les uns après les autres. Pendant de nombreuses années, nous avons écrit des programmes de cette façon. L'avantage de cette approche est que nous restons proches du processeur, dirigeant son mouvement ultérieur. Nous sommes aux commandes et l'ordinateur suit nos instructions. Nous indiquons à l'ordinateur comment trouver le plus grand des deux nombres. Nous prenons des décisions, il les suit. Le flux d'exécution est toujours cohérent, du début du script à sa fin.

Ce type de pensée linéaire est appelé «penser comme un ordinateur». L'ordinateur à un moment donné commence à exécuter des instructions et à un moment donné le termine. Lors de l'écriture de code en C, nous sommes obligés de penser de cette façon. Les opérateurs séparés par des points-virgules vont de haut en bas. Ce style est hérité de l'assembleur.
Bien que les langages d'un niveau plus élevé que l'assembleur aient des procédures, des sous-programmes et d'autres mécanismes d'abstraction, ils n'éliminent pas une façon de penser cohérente. Le programme continue de fonctionner de haut en bas. Il n'y a rien de mal à une telle approche lors de l'écriture de petits programmes, mais à plus grande échelle, il est difficile de penser comme ça.

Jetez un œil au même code écrit dans le langage de programmation fonctionnel Lisp:

 (defun max (ab) (if (> ab) ab)) 

Pouvez-vous dire où commence et se termine l'exécution de ce code? Non. Nous ne savons pas comment le processeur obtiendra le résultat, ni comment la fonction if fonctionnera. Nous sommes très éloignés du processeur. Nous pensons comme une fonction, pas comme un ordinateur. Lorsque nous avons besoin d'une nouvelle chose, nous la définissons:

 (def x (max 5 9)) 

Nous définissons, ne donnons pas d'instructions au processeur. Avec cette ligne, nous lions x à (max 5 9). Nous ne demandons pas à l'ordinateur de calculer le plus grand des deux nombres. Nous disons simplement que x est le plus grand des deux nombres. Nous ne contrôlons pas comment et quand il sera calculé. Notez que cela est important: x est le plus grand des nombres. La relation «est» («être», «être») est la différence entre un paradigme de programmation fonctionnel, logique et orienté objet d'un paradigme procédural.

Avec un état d'esprit informatique, nous sommes à la barre et contrôlons le flux d'instructions. Avec une façon de penser orientée objet, nous déterminons simplement qui est qui et nous les laissons interagir quand ils en ont besoin. Voici à quoi devrait ressembler le calcul du plus grand des deux nombres dans la POO:

 class Max implements Number { private final Number a; private final Number b; public Max(Number left, Number right) { this.a = left; this.b = right; } } 

Et donc je vais l'utiliser:

 Number x = new Max(5, 9); 

Écoutez, je ne calcule pas le plus grand des deux nombres. Je détermine que x est le plus grand des deux nombres. Peu m'importe ce qui se trouve à l'intérieur de l'objet de la classe Max et comment exactement il implémente l'interface numérique. Je ne donne pas d'instructions au processeur concernant ce calcul. J'instancie juste l'objet. C'est très similaire à def en Lisp .. En ce sens, la POO est très similaire à la programmation fonctionnelle.

En revanche, les méthodes statiques en POO sont les mêmes que les sous-routines en C ou assembleur. Ils ne sont pas liés à la POO et nous obligent à écrire du code procédural dans une syntaxe orientée objet. Voici le code Java:

 int x = Math.max(5, 9); 

C'est complètement faux et ne doit pas être utilisé dans une conception orientée objet réelle.

Style déclaratif versus impératif

La programmation impérative «décrit les calculs en termes d'opérateurs qui changent l'état d'un programme». La programmation déclarative, quant à elle, «exprime la logique du calcul sans décrire le flux de son exécution» (je cite Wikipedia). En fait, nous en avons parlé au cours de plusieurs pages précédentes. La programmation impérative est similaire à ce que font les ordinateurs - exécution séquentielle d'instructions. La programmation déclarative est plus proche de la façon naturelle de penser dans laquelle nous avons des entités et des relations entre elles. De toute évidence, la programmation déclarative est une approche plus puissante, mais une approche impérative est plus compréhensible pour les programmeurs procéduraux. Pourquoi l'approche déclarative est-elle plus puissante? Ne changez pas, et après quelques pages, nous arrivons au point.

Qu'est-ce que tout cela a à voir avec les méthodes statiques? Peu importe qu'il s'agisse d'une méthode ou d'un objet statique, nous devons encore écrire if (a> b) quelque part, non? Oui, exactement. La méthode statique et l'objet ne sont qu'un wrapper sur l'instruction if, qui effectue la tâche de comparaison de a avec b. La différence réside dans la façon dont cette fonctionnalité est utilisée par d'autres classes, objets et méthodes. Et c'est une différence significative. Considérez-le avec un exemple.
Disons que j'ai un intervalle limité à deux entiers, et un entier qui devrait tomber dedans. Je dois m'assurer qu'il l'est. Voici ce que je dois faire si la méthode max () est statique:

 public static int between(int l, int r, int x) { return Math.min(Math.max(l, x), r); } 

Nous devons créer une autre méthode statique, entre (), qui utilise les deux méthodes statiques disponibles, Math.min () et Math.max (). Il n'y a qu'une seule façon de le faire - une approche impérative, car la valeur est calculée immédiatement. Lorsque je fais un appel, j'obtiens immédiatement le résultat:

 int y = Math.between(5, 9, 13); //  9 

J'obtiens le numéro 9 juste après avoir appelé entre (). Une fois l'appel effectué, mon processeur commencera immédiatement à travailler sur ce calcul. Il s'agit d'une approche impérative. Et à quoi ressemble l'approche déclarative?

Ici, jetez un oeil:

 class Between implements Number { private final Number num; Between(Number left, Number right, Number x) { this.num = new Min(new Max(left, x), right); } @Override public int intValue() { return this.num.intValue(); } } 

Voici comment je vais l'utiliser:

 Number y = new Between(5, 9, 13); //   ! 

Sentez-vous la différence? Elle est extrêmement importante. Ce style sera déclaratif, car je ne dis pas au processeur que les calculs doivent être effectués immédiatement. Je viens de déterminer ce que c'était et de laisser à l'utilisateur le soin de décider quand (et s'il était nécessaire) de calculer la variable y à l'aide de la méthode intValue (). Peut-être qu'il ne sera jamais calculé et mon processeur ne saura jamais quel est le nombre 9. Tout ce que j'ai fait, c'est déclarer ce que c'est. Je viens d'annoncer. Je n'ai pas encore donné de travail au processeur. Comme indiqué dans la définition, exprimé la logique sans décrire le processus.

J'entends déjà: «D'accord, je vous comprends. Il existe deux approches - déclarative et procédurale, mais pourquoi la première est-elle meilleure que la seconde? » J'ai mentionné plus tôt qu'il est évident que l'approche déclarative est plus puissante, mais n'a pas expliqué pourquoi. Maintenant que nous avons examiné les deux approches avec des exemples, nous allons discuter des avantages d'une approche déclarative.

Premièrement, c'est plus rapide. À première vue, cela peut sembler plus lent. Mais si vous regardez de plus près, il deviendra clair qu'en fait, c'est plus rapide, car l'optimisation des performances est entièrement entre nos mains. En effet, il faudra plus de temps pour créer une instance de la classe Between que d'appeler la méthode static between (), au moins dans la plupart des langages de programmation disponibles au moment de la rédaction de ce livre. J'espère vraiment que nous aurons un langage dans un futur proche dans lequel l'instanciation d'un objet sera aussi rapide que l'appel d'une méthode. Mais nous ne sommes pas encore venus à lui. C'est pourquoi l'approche déclarative est plus lente ... lorsque le chemin d'exécution est simple et direct.

Si nous parlons d'un simple appel à une méthode statique, alors ce sera certainement plus rapide que de créer une instance d'un objet et d'appeler ses méthodes. Mais si nous avons de nombreuses méthodes statiques, elles seront appelées séquentiellement lors de la résolution du problème, et pas seulement pour travailler sur les résultats dont nous avons vraiment besoin. Que diriez-vous de ceci:

 public void doIt() { int x = Math.between(5, 9, 13); if (/*  ? */) { System.out.println("x=" + x); } } 

Dans cet exemple, nous calculons x, que nous ayons besoin de sa valeur ou non. Le processeur trouvera la valeur 9 dans les deux cas. La méthode suivante utilisant l'approche déclarative fonctionnera-t-elle aussi vite que la précédente?

 public void doIt() { Integer x = new Between(5, 9, 13); if (/*  ? */) { System.out.println("x=" + x); } } 

Je pense que le code déclaratif sera plus rapide. C'est mieux optimisé. Et il ne dit pas au processeur quoi faire. Au contraire, il permet au processeur de décider quand et où le résultat est vraiment nécessaire - les calculs sont effectués à la demande.

L'essentiel est que l'approche déclarative est plus rapide car elle est optimale. C'est le premier argument en faveur d'une approche déclarative par rapport à l'impératif de la programmation orientée objet. Le style impératif n'a définitivement pas sa place dans la POO, et la première raison en est l'optimisation des performances. Il ne faut pas dire que plus vous contrôlez l'optimisation du code, plus il est suivi. Au lieu de laisser l'optimisation du processus de calcul au compilateur, à la machine virtuelle ou au processeur, nous le faisons nous-mêmes.

Le deuxième argument est le polymorphisme. En termes simples, le polymorphisme est la capacité de briser les dépendances entre les blocs de code. Supposons que je veuille changer l'algorithme pour déterminer si un nombre tombe dans un certain intervalle. C'est assez primitif en soi, mais je veux le changer. Je ne veux pas utiliser les classes Max et Min. Et je veux qu'il effectue une comparaison en utilisant les instructions if-then-else .. Voici comment procéder de manière déclarative:

 class Between implements Number { private final Number num; Between(int left, int right, int x) { this(new Min(new Max(left, x), right)); } Between(Number number) { this.num = number; } } 

Il s'agit de la même classe Between que dans l'exemple précédent, mais avec un constructeur supplémentaire. Maintenant, je peux l'utiliser avec un autre algorithme:

 Integer x = new Between( new IntegerWithMyOwnAlgorithm(5, 9, 13) ); 

Ce n'est probablement pas le meilleur exemple, car la classe Between est très primitive, mais j'espère que vous comprenez ce que je veux dire. La classe Between est très facile à séparer des classes Max et Min, car ce sont des classes. Dans la programmation orientée objet, un objet est un citoyen à part entière, mais pas la méthode statique. Nous pouvons passer l'objet comme argument au constructeur, mais nous ne pouvons pas faire de même avec la méthode statique. Dans la POO, les objets sont associés à des objets, communiquent avec des objets et échangent des données avec eux. Pour détacher complètement un objet des autres objets, nous devons nous assurer qu'il n'utilise le nouvel opérateur dans aucune de ses méthodes (voir section 3.6), ainsi que dans le constructeur principal.

Permettez-moi de répéter: pour détacher complètement un objet des autres objets, il vous suffit de vous assurer que le nouvel opérateur n'est utilisé dans aucune de ses méthodes, y compris le constructeur principal.

Pouvez-vous faire le même découplage et refactoring avec un extrait de code impératif?

 int y = Math.between(5, 9, 13); 

Non, tu ne peux pas. La méthode statique entre () utilise deux méthodes statiques, min () et max (), et vous ne pouvez rien faire avant de l'avoir complètement réécrite. Et comment pouvez-vous le réécrire? Passer le quatrième paramètre à la nouvelle méthode statique?

À quel point sera-t-il laid? Je pense vraiment.

Voici mon deuxième argument en faveur d'un style de programmation déclaratif - il réduit la cohésion des objets et le rend très élégant. Sans oublier le fait que moins de cohésion signifie plus de maintenabilité.

Le troisième argument en faveur de la supériorité de l'approche déclarative sur l'impératif - l'approche déclarative parle des résultats, alors que l'impératif explique la seule façon de les obtenir. La seconde approche est beaucoup moins intuitive que la première. Je dois d'abord «exécuter» le code dans ma tête pour comprendre quel résultat attendre. Voici une approche impérative:

 Collection<Integer> evens = new LinkedList<>(); for (int number : numbers) { if (number % 2 == 0) { evens.add(number); } } 

Pour comprendre ce que fait ce code, je dois le parcourir, visualiser ce cycle. En fait, je dois faire ce que fait le processeur - parcourir tout le tableau des nombres et mettre les nombres pairs dans la nouvelle liste. Voici le même algorithme, écrit dans un style déclaratif:

 Collection<Integer> evens = new Filtered( numbers, new Predicate<Integer>() { @Override public boolean suitable(Integer number) { return number % 2 == 0; } } ); 

Ce morceau de code est beaucoup plus proche de la langue anglaise que le précédent. Il se lit comme suit: "evens est une collection filtrée qui inclut uniquement les éléments qui sont pairs." Je ne sais pas exactement comment la classe Filtered crée une collection - utilise-t-elle une instruction for ou autre chose. Tout ce que j'ai besoin de savoir en lisant ce code, c'est que la collection a été filtrée. Les détails de l'implémentation sont masqués et le comportement est exprimé.

Je me rends compte que pour certains lecteurs de ce livre, il était plus facile de percevoir le premier fragment. Il est un peu plus court et très similaire à ce que vous voyez quotidiennement dans le code que vous traitez. Je vous assure que c'est une question d'habitude. C'est un sentiment trompeur. Commencez à penser en termes d'objets et de leur comportement, plutôt qu'en termes d'algorithmes et leur exécution, et vous obtiendrez une véritable perception. Le style déclaratif se rapporte directement aux objets et à leur comportement, et l'impératif - aux algorithmes et à leur exécution.

Si vous trouvez ce code moche, essayez Groovy, par exemple:

 def evens = new Filtered( numbers, { Integer number -> number % 2 == 0 } ); 

Le quatrième argument est l'intégrité du code. Jetez un autre coup d'œil aux deux extraits précédents. Veuillez noter que dans le deuxième fragment, nous déclarons evens comme un seul opérateur - evens = Filtered (...). Cela signifie que toutes les lignes de code responsables du calcul de cette collection sont côte à côte et ne peuvent pas être séparées par erreur. Au contraire, dans le premier fragment, il n'y a pas de «collage» évident des lignes. Vous pouvez facilement modifier leur ordre par erreur et l'algorithme se cassera.

Dans un morceau de code aussi simple, c'est un petit problème, car l'algorithme est évident. Mais si le fragment du code impératif est plus grand - disons, 50 lignes, il peut être difficile de comprendre quelles lignes de code sont liées les unes aux autres .. Nous avons discuté un peu plus tôt du problème de la concaténation temporelle - lors de la discussion des objets immuables .. Le style de programmation déclarative aide également à éliminer cette concaténation , grâce à laquelle la maintenabilité est améliorée.

Il y a probablement encore des arguments, mais j'ai cité le plus important, de mon point de vue, de ceux liés à la POO. J'espère avoir pu vous convaincre que le style déclaratif est ce dont vous avez besoin. Certains d'entre vous peuvent dire: «Oui, je comprends ce que vous voulez dire. Je combinerai les approches déclaratives et impératives, le cas échéant. J'utiliserai des objets là où cela a du sens et des méthodes statiques quand je devrai faire rapidement quelque chose de simple, comme calculer le plus grand des deux nombres. ".." Non, tu te trompes! " - Je vais te répondre. Vous ne devez pas les combiner. N'utilisez jamais un style impératif. Ce n'est pas un dogme. Cela a une explication très pragmatique.

Le style impératif ne peut pas être combiné avec un caractère déclaratif purement technique. , — .

, — max() min(). , . , , .. — Between, between(). ? , , , , . . , Between. , - , .

- : , — . .

« ! — . — ?» … , . - , - ( ). , , — . , .. , . , , — , , , . , Apache Commons FileUtils.readLines(), . :

 class FileLines implements Iterable<String> { private final File file; public Iterator<String> iterator() { return Arrays.asList( FileUtils.readLines(this.file) ).iterator(); } } 

, , :

 Iterable<String> lines = new FileLines(f); 

FileLines, . . , , — FileLines. , .

-

- , , ( -).. , java.lang.Math — -. Java, Ruby , , . ? . 1.1 , — . - , :

 class Math { private Math() { //   } public static int max(int a, int b) { if (a < b) { return b; } return a; } } 

, -, , , . , , , .

- — - . - — — . , , . - — .. .

«»

«» — , , . , , . :

 class Math { private static Math INSTANCE = new Math(); private Math() {} public static Math getInstance() { return Math.INSTANCE; } public int max(int a, int b) { if (a < b) { return b; } return a; } } 

. Math, INSTANCE.. , getInstance(). , . INSTANCE — getInstance().

«» , . , . , . , , , , -, . - Math, , :

 class Math { private Math() {} public static int max(int a, int b) { if (a < b) { return b; } return a; } } 

max():

 Math.max(5, 9); // - Math.getInstance().max(5, 9); //  

? , , . , -? Java-. , : « ». Par exemple:

 class User { private static User INSTANCE = new User(); private String name; private User() {} public static User getInstance() { return User.INSTANCE; } public String getName() { return this.name; } public String setName(String txt) { this.name = txt; } } 

, . «, ». -, , - . .. , -: « ».. . .. -, , :

 class User { private static String name; private User() {} public static String getName() { return User.name; } public static String setName(String txt) { User.name = txt; } } 

- , . , ? ? , — , , - — , . , , setInstance() getInstance(). , . , :

 Math.getInstance().max(5, 9); 

Math. , Math — , . , Math , . , . , , , -, . , , Math.max() -. ? :

 Math math = new FakeMath(); Math.setInstance(math); 

«» , . : - , . - — . - — — .

, ? -, , . Pourquoi? , — , , .. . . , :

 #include <stdio> int line = 0; void echo(char* text) { printf("[%d] %s\n", ++line, text); } 

echo(), line. line *.-.. . Java , . Java, Ruby --, . Pourquoi? . . . . , . , , GOTO.

, , - Java, «».. - , . .
. .

« ? — . — , , ?» , , , . - . ? !

, .

, , .. . . , . , : , , . . , , , . , — , 2.1.

. .

: , ()? , , , .. , ? Lisp, Clojure Haskell Java C++?

, :

 class Max implements Number { private final int a; private final int b; public Max(int left, int right) { this.a = left; this.b = right; } @Override public int intValue() { return this.a > this.b ? this.a : this.b; } } 

:

 Number x = new Max(5, 9); 

Lisp , :

 (defn max (ab) (if (> ab) ab)) 

, ? Lisp .

, , — . - , - -, . , - Java, , Java , -. — , . .

, - . -, Java, ( ) , . .

, . — - . — - , — , , :

 names = new Sorted( new Unique( new Capitalized( new Replaced( new FileNames( new Directory( "/var/users/*.xml" ) ), "([^.]+)\\.xml", "$1" ) ) ) ); 

, , -. , 3.2. , names, , , . , , , . .

? , , , .

, . Directory, FileNames, Replaced, Capitalized, Unique Sorted — , . . .

, ( ). , Unique — Iterable, . FileNames — , .
- . , .. - app.run(), . if, for, switch while. , .

if Java , . Java , If? :

 float rate; if (client.age() > 65){ rate = 2.5; } else { rate = 3.0; } 

- :

 float rate = new If( client.age() > 65, 2.5, 3.0 ); 

?

 float rate = new If( new Greater(client.age(), 65), 2.5, 3.0 ); 

, :

 float rate = new If( new GreaterThan( new AgeOf(client), 65 ), 2.5, 3.0 ); 

- . — , rate.

, , . if, for, switch while. If, For, Switch While. ?

, . . . , .. , .
, - — .

? , : . , . . . , — .

: static — , , .

»Plus d'informations sur le livre sont disponibles sur le site Web de l'éditeur

20% — Java