This class has three instance variables. The number of seats, the driver name,
and the list of passengers. For which are these should we have getters and
setters. The number of seats certainly shouldn't have a setter. You can't
really change the number of seats in a car. Should it have a getter? if you
added one, it's not a mistake. but there's probably no grade reason for having
it. I didn't add one. Now, the driver name definitely needs a setter, because,
when you look through the methods, there is no way of setting it otherwise. So,
let's add a setter. Here is my setter. Do I need a getter? I think I do.
There's no other way of finding out who's driving this car. None of the other
methods make any use of the driver name. I'm assuming it was important since
someone added the instance variable. So, let's add the getter as well. Here is
my getter. And as is so often, the setter and the getter have very simple
implementation. What about the third instance variable? You definitely don't
want to have getters and setters for this variable. It would be very odd to
have a method that holds and places an internal array of the class. And you
also wouldn't really want to return it, because then you would give the user of
the class the possibility of changing its content. So there is a rule of thumb
that says that in general, a class that does not want to return any internal
parts of its implementation that a third party could modify. Now, you've seen a
bunch of useful patterns that hopefully will help you designing the
implementation of a class. I will put those to good use when we implement our
car share application. But before we do that, there is another technical topic
that we need to tackle. Namely, variables and methods that don't belong to
objects, but to the class as a whole.
Esta clase tiene tres variables de instancia. El número de asientos, el nombre del conductor,
y la lista de pasajeros. ¿Para cuales de estos deberías tener obtenedores y
configuradores? El número de asientos, sin duda no debe tener un configurador. De hecho,
no puedes cambiar el número de asientos en un coche. ¿Debería tener un obtenedor? Si
agregas uno, no es un error, pero probablemente no haya una gran razón para
tenerlo. No añadí uno. Ahora, el nombre del conductor definitivamente necesita un configurador, ya que,
cuando veas a través de los métodos, no hay forma de configurarlo de otra manera. Así que
agreguemos un configurador. Aquí está mi configurador. ¿Necesito un obtenedor? Creo que sí.
No hay otra forma de averiguar quién está manejando el coche. Ninguno de los otros
métodos utilizan el nombre del conductor. Estoy asumiendo que era importante ya que
alguien agregó la variable de instancia. Así que agreguemos un obtenedor también. Aquí está
mi obtenedor. Frecuente, el configurador y el obtenedor tienen
implementación muy sencilla. ¿Qué pasa con la tercera variable de instancia? Definitivamente no quieres
tener obtenedores y configuradores para esta variable. Sería muy extraño
tener un método que conserve y coloque un array interno de la clase. Y tú
en realidad tampoco quieres devolverlo, porque entonces le darías al usuario
de la clase la posibilidad de cambiar su contenido. Así que hay una regla de oro
que dice que, en general, una clase no quiere devolver cualquier parte
interna de su implementación que un tercero podría modificar. Ahora, has visto
muchos patrones útiles que esperamos te ayuden a diseñar
la implementación de una clase. Pondré aquellos a buen uso cuando implementemos nuestra
aplicación de compartir coche. Pero antes de hacer eso, hay otro tema técnico
que tenemos que abordar. Es decir, las variables y métodos que no pertenecen a
objetos, sino a la clase como un todo.
Cette classe a trois variables d'instance.
Le nombre de sièges, le nom du chauffeur et la liste des passagers.
Pour lesquels devrions-nous avoir des getters et setters.
Le nombre de sièges ne devrait pas avoir de setter.
On ne peut pas changer le nombre de sièges dans une voiture.
Devrait-il avoir un getter?
Si vous en ajoutiez un, ce ne serait pas une erreur.
mais il n'y a probablement aucune raison d'en avoir un,
je n'en ai pas ajouté.
Maintenant, le nom du chauffeur a certainement besoin d'un setter, car,
quand vous regardez les méthodes,
il n'y a aucun moyen de le configurer autrement.
Alors, ajoutons un setter.
Voici mon setter.
Ai-je besoin d'un getter?
Je pense que oui.
Il n'y a pas d'autre moyen de savoir qui conduit cette voiture.
Aucune des autres méthodes utilise le nom du chauffeur.
J'imagine que c'était important
car quelqu'un avait ajouté la variable d'instance.
Donc, ajoutons le getter aussi.
Voici mon getter.
Et comme souvent, le setter et le getter
ont une implémentation très simple.
Qu'en est-il de la troisième variable d'instance?
Il vaut mieux ne pas avoir des getters et setters pour cette variable.
Il serait très étrange d'avoir une méthode
qui tient et place et remplace
un tableau interne d'une classe.
Et vous ne voudriez pas non plus le renvoyer,
car alors vous donneriez à l'utilisateur de la classe
la possibilité de changer son contenu.
Donc, il y a une règle générale qui dit qu'en général,
une classe qui ne veut pas renvoyer des parties internes
de son implémentation qu'une tierce partie pourrait modifier.
Maintenant, vous avez vu un tas de modèles utiles qui, espérons-le,
vous aideront à concevoir l'implémentation d'une classe.
Je les mettrai à profit lors
de l'implémentation de notre application de covoiturage.
Mais avant cela,
il y a un autre sujet technique que nous devons aborder,
à savoir, les variables et les méthodes qui n'appartiennent pas aux objets,
mais à la classe dans son ensemble.
このクラスには3つのインスタンス変数があります
座席数と運転手名と乗客リストです
どれにゲッターとセッターを足すべきでしょうか
座席数は変更できないので 座席数にセッターは不要です
ゲッターを足してもいいですが 特に必要ではありません
私は足しませんでした
運転手名には必ずセッターが必要です
メソッドを見ると分かりますが 他に設定する方法がないからです
なのでこのようにセッターを足しましょう
ゲッターも必要です 誰が運転するのか
調べる方法がないからです 他のメソッドでは運転手名を活用できません
誰かがインスタンス変数を加えたので これは重要だと考えます
ゲッターも追加しましょう
これがゲッターです
大抵の場合セッターとゲッターの実装は ご覧のように
非常にシンプルです
では3番目のインスタンス変数はどうでしょう？
この変数にはゲッターとセッターを つけてはいけません
クラスの内部配列を 保持または変換するメソッドがあるのは
非常に不自然なことだからです
また値を返すこともよくありません 値を返すことで
クラスのユーザが そのコンテンツを変更できるからです
これまでの経験から言えるのは 一般的にクラスには
第三者が変更可能な実装の内部を 返したくないのです
クラスの実装を設計する時に役立つ 様々なパターンを見てきました
それではカーシェアリングの アプリケーションを実装する時に
それらのパターンを応用していきたいと思います
しかしその前にやっておきたい 技術的なトピックがあります
オブジェクトに属さず クラス全体に属する変数とメソッドについてです