Dans cet article, j'expliquerai les bases de l'orientation des objets avec la métaphore
Prenons une carte Trump comme exemple.
Card.java
public class Card {
//Champ (= variable membre)
private Suit suit; //marque(Coeurs, piques, diamants, clubs)
private int number;//Nombres(1~13)
//Méthode (= fonction)
public Card(Suit suit, number) {//constructeur
this.suit = suit;
this.number = number;
}
public Suit getSuit() {
return this.suit;
}
public int getNumber() {
return this.number;
}
}
Une fée est un objet en orientation objet. Les fées sont celles qui habitent dans les choses et contrôlent (= contrôlent) les choses. En d'autres termes, toutes les fées ont les rôles de XX, XX et XX. Tous les êtres humains, comme une fée qui nettoie au milieu de la nuit, une fée qui reste dans ses chaussures et aide les gens qui les portent, et [la fée de Densetsu](https://wiki.ducca.org/wiki/legendary Suzuki) Cela nous aidera.
C'est l'équipe magique qui décide du genre de fée à appeler. Dans le cercle magique, non seulement la fée elle-même, mais aussi le contrat avec la fée est écrit. Un cercle magique est une classe en orientation objet. La fée est ** sérieuse et obéissante **, donc elle fera exactement ce que dit le cercle magique. Si vous pouvez écrire le cercle magique, invoquons la fée. Le sort est "Invocation! Fée!". Dans le code source Java, nouveau est le sort d'invocation.
//Sort d'invocation de fée
Fairy alice = new Fairy();
Le champ (= variable membre) représente "ce qu'il a" et "ce qu'il sait" de la fée. Les fées peuvent se rappeler ce qu'elles sont et quelles autres fées sont prêtes à les aider. ** Les fées n'aiment pas pouvoir regarder leur contenu. ** ** C'est la même chose qu'une lycéenne qui dit: "Hé! Je ne suis pas contente en ce moment! C'est embarrassant> <". Par conséquent, il est souhaitable que le champ (= variable membre) soit privé plutôt que public. La raison en est que s'il est public, ce sera une source de bugs inattendus car vous ne saurez pas quand la fée a été impressionnée ni ce que vous faites maintenant. Au début, si vous vous perdez, vous pouvez le laisser privé pour le moment. Si vous voulez voir ou changer ce que la fée a, échangeons-le via les fonctions getter / setter (nommé get ○○○ et set ○○○).
La méthode (= fonction) représente le "ce que vous pouvez faire" et "ce que vous pouvez faire" de la fée. Vous pouvez faire diverses choses comme «faire ce travail» ou «répondre aux questions». Oui, vous pouvez l'écrire dans le cercle magique (= classe).
En fait, la fée Trump ci-dessus n'est pas encore devenue une fée. Avoir une valeur et la mettre dans et hors est juste un conteneur, et vous interagissez toujours avec les choses et les gens. Voici un exemple.
public staric main(String[] args) {
Card heart = new Card(Suit.HEART, 7);//Suit est de type Enum.
if(heart.getNumber() >= 5) {
System.out.println("Cette carte est de 5 ou plus.");
} else {
System.out.println("Cette carte est inférieure à 5.");
}
}
Ensuite, jetons un coup d'œil à l'interaction entre la fée et les gens.
Card.java
public class Card {
// ...Les champs et autres fonctions sont les mêmes que ci-dessus, donc omis...
public boolean isOver(int number) {
return this.getNumber() >= number;
}
}
public staric main(String[] args) {
Card heart = new Card(Suit.HEART, 7);
if(heart.isOver(5)) {
System.out.println("Cette carte est de 5 ou plus.");
} else {
System.out.println("Cette carte est inférieure à 5.");
}
}
Au mieux, vous pourriez penser que ce n'est qu'une fonction de plus, mais ** Fairy veut pouvoir faire son travail par elle-même. ** Ce n'est pas juste une chose, vous pouvez donc penser et agir par vous-même. Par conséquent, il est préférable de laisser le jugement lié à ce que la fée sait à la fée, plutôt que d'y penser en tant que maître. Créez une nouvelle fonction et donnez-lui un joli nom court et descriptif.
L'argument représente «l'enseignement» à la fée. Apprenons à la fée ce dont vous avez besoin à travers les arguments. Comme je l'ai mentionné plus tôt, la fée veut pouvoir faire son travail seule, il est donc préférable d'enseigner moins (= argument). Si vous souhaitez enseigner la même chose encore et encore, il est préférable de l'enseigner via le constructeur, d'ajouter la fonction ○○○ et de définir la fonction ○○○ à l'avance afin de pouvoir utiliser ce que vous avez appris. Laissons le travail à la fée ~~ jetant le tout ~~. De cette façon, la fée et le maître seront heureux.
Les erreurs (= exceptions) sont des "choses dangereuses" pour la fée et le maître, et "ne pas faire" pour la fée. La fée est une travailleuse acharnée, mais à force d'essayer trop fort, le maître peut avoir des ennuis. Je suis très inquiet si je me perds ou si je vais là où je ne devrais pas. C'est une erreur de l'empêcher. Si la fée est sur le point de faire quelque chose de dangereux, arrêtez-la. Cependant, il est préférable d'écrire un cercle magique (= classe) afin que des choses dangereuses ne se produisent pas en premier lieu, plutôt que de s'arrêter s'il y a une chose dangereuse.
Une bonne fée est petite et mince. Être petit signifie que le code est court. Plus une fée est chargée de travail, plus le code source devient long et plus la fée devient grande. Une autre raison pour laquelle la fée grossit est la duplication de code. Diète en créant une fonction pour assembler la partie qui se chevauche ou en partageant le travail avec une nouvelle fée. Le but est de pouvoir répondre à la question "Que fait cette fée?" En une phrase. Il vaut mieux laisser beaucoup de travail à beaucoup de petites fées plutôt que de laisser beaucoup de travail à une grosse fée. Faisons un harem féerique. Par contre, une fée très grosse devient ** Dieu </ font> **.
La fée de Dieu est une fée gênante à qui le travail est confié mais qui ne comprend pas pourquoi il bouge. C'est une présence que les anciens maîtres appellent et effraient les maîtres actifs. Quand j'essaie de faire faire quelque chose de nouveau à God Fairy, cela crée un grand nombre de bugs et leurs possibilités, et j'ai du mal à les corriger, voire cent fois de mal. Donc, lorsque vous écrivez un nouveau cercle magique, ne faites pas un ** dieu. ** ~~ Cette ligne est cool ... ~~ Ce type de "ne sait pas" en programmation s'appelle ** anti-pattern **. Au contraire, les méthodologies recommandées sont appelées ** Design Patterns **. Le plus connu s'appelle GoF (Gang of Four), et il y en a 23 au total. Une fois que vous comprenez la syntaxe de votre programme, c'est une bonne idée de le rechercher.
Le code propre est un code facile à lire pour le maître (hautement lisible). Les programmeurs ont l'esthétique dans leur code source, tout comme les mathématiciens trouvent la beauté dans les formules mathématiques. Il existe diverses techniques telles que l'indentation peu profonde et le nom propre. L'astuce pour faire une petite et belle fée est de rechercher et d'apprendre en ** refactorisant **.
La fée veut penser et agir seule. Laissons le travail à la fée autant que possible. Et essayons de créer un mécanisme pour que de nombreuses petites et belles fées puissent coopérer.
Pour moi, ** je pense qu'il vaut mieux étudier le refactoring avant d'étudier l'orientation objet **. Savoir quoi faire permet de mieux comprendre à quoi sert l'orientation objet. J'ai appris le refactoring après avoir étudié les bases de l'orientation des objets et des modèles de conception, mais après avoir étudié le refactoring, j'ai pu mieux comprendre ces modèles et ces idées.
Eh bien, nous attendons avec impatience vos goûts, impressions et commentaires.
① Après avoir lu cet article, j'ai pensé qu'il y avait des gens qui avaient la même idée, j'ai donc décidé d'écrire ce commentaire. Vous pouvez également voir de quel type de philosophie l'orientation de l'objet a été faite. https://qiita.com/s_yuche/items/d46c7c843a56e6b2ebb7
② Il vous dira quel genre de fée vaut sept vertus. Je ne peux pas dire que tout est ainsi, mais il y a beaucoup de choses que je peux comprendre. https://www.kaitoy.xyz/2015/10/28/seven-virtues-of-good-object/
③ J'ai étudié le refactoring dans [ce livre](https://www.amazon.co.jp/ Refactoring-Safely améliorer le code existant-OBJECT-TECHNOLOGY-Martin-Fowler / dp / 427405019X) .. Je le recommande fortement. Cependant, il y avait des endroits où le code était omis et le contenu était un peu vieux. Par conséquent, nous recommandons celui-ci avec presque le même contenu. [[Amazon] Introduction au refactoring appris en langage Java](https://www.amazon.co.jp/ Introduction au refactoring appris en langage Java-Yuki-Hiroshi / dp / 4797337990 /)
Recommended Posts