J'entends souvent les gens dire: "Je suis fatigué d'écrire la méthode getter / setter une par une, mais pourquoi devrais-je l'écrire? Où devrais-je l'écrire après tout?", Alors je l'ai écrit comme un article.

(Garantie à 100% que Masakari volera)

En outre, les mots ayant des propriétés similaires telles que les champs, les variables d'instance, les propriétés et les variables de membre ne sont pas utilisés correctement ici, mais sont collectivement appelés champs. En outre, les méthodes, les fonctions membres, etc. sont également désignées collectivement sous le nom de méthodes.

Fondamentalement,

Tout d'abord, je vais expliquer brièvement comment est né le concept de méthode getter / setter.

Une propriété des programmes orientés objet est le polymorphisme. C'est, par exemple

Dans Smalltalk, quel que soit le destinataire, vous n'avez qu'à vous soucier de pouvoir répondre aux messages que vous envoyez.
En Java, si l'objet implémente une interface spécifique, vous pouvez appeler la méthode de l'interface spécifique de cet objet sans vous soucier de l'implémentation.

C'est la nature.

En d'autres termes, vous programmez pour l'interface, pas pour l'implémentation. Cela permet de réduire le coût du développement logiciel.

Lors de l'écriture d'un programme pour une interface, c'est-à-dire un programme qui élimine autant que possible les dépendances d'implémentation, le plus important est de rendre la partie d'implémentation concrète inaccessible (encapsulation). Les champs sont simplement inclus dans l'implémentation interne, nous devons donc fournir une méthode alternative pour les rendre inaccessibles directement de l'extérieur. Cela crée un modèle qui "pour un champ spécifique, nous préparerons une méthode pour acquérir les données de l'extérieur ou une méthode pour changer les données de l'extérieur". La méthode correspondant à ce modèle a été appelée plus tard la "méthode getter / setter".

L'écriture d'un exemple d'utilisation de la méthode getter / setter en Java ressemble à ceci

class User{
    private String name;

    public String getName(){
        return name;
    }

    public void setName(String name){
        this.name = name;
    }
}

C'est celui que vous voyez souvent.

En passant, je pense que Smalltalk reflète le mieux le concept d'encapsulation et les méthodes getter / setter. En effet, dans Smalltalk, le qualificatif d'accès d'une variable d'instance (en Java, etc.) ne peut pas être modifié de protected.


Object subclass: #User
    instanceVariableNames: 'name'

User>>name
    ^ name

User>>name: aName
    name := aName

Ici, la méthode setter / getter de Smalltalk ou sa série de OOPL est différente du style habituel et se présente sous la forme de nom, nom: comme dans l'exemple ci-dessus. (C'est vraiment très beau ...)

Mais il y a des exceptions (?)

La méthode getter / setter a également l'inconvénient de rendre le code redondant. Dans l'exemple ci-dessous, définir seulement trois champs rendrait le code gonflé.

class User{
    private String name;
    private int age;
    private boolean isAdmin;

    public String getName(){
        return name;
    }

    public void setName(String name){
        this.name = name;
    }

    public int getAge(){
        return age;
    }

    public void setAge(int age){
        this.age = age;
    }

    public boolean getIsAdmin(){
        return isAdmin;
    }

    public void setIsAdmin(boolean isAdmin){
        this.isAdmin = isAdmin;
    }
}

Voici quelques cas où il vaut mieux ne pas définir de méthode getter / setter.

Lors de l'utilisation de PI

PI (Persistence Ignorance) est un modèle de la classe qui "se comporte comme une simple structure". Aussi connu sous le nom de POJO (ancien objet java simple). En utilisant ce modèle, le code Java ci-dessus peut être réécrit comme:

class User{
    public String name;
    public int age;
    public boolean isAdmin;
}

Dans une structure simple, le champ lui-même se comporte comme une interface, il n'est donc pas nécessaire d'écrire des méthodes setter / getter redondantes, et il est correct de l'écrire comme ça dans un programme orienté objet.

Ce modèle est souvent utilisé dans les classes de modèles et autres.

Lorsque vous utilisez ActiveRecord, Eloquent ORM, etc.

Les ActiveRecords tels que Ruby on Rails et Laravel vous permettent d'accéder dynamiquement aux champs qui ne sont pas définis dans votre code.

Par exemple, à Laravel

class User extends Model{

}

$user = User::first();
$user->id; //1 ou quelque chose
$user->name; //ogiwara

Bien entendu, dans de tels cas, il n'est pas nécessaire de définir la méthode getter / setter une par une.

Au fait, même s'il n'est pas défini dans le code, s'il s'agit de PHP, @property etc. est PHPDoc Si vous l'écrivez, vous pouvez obtenir le support de l'IDE, etc.


/**
 * @property int $id
 * @property string $name
 */
class User extends Model{

}

Il est intégré à la spécification du langage

Kotlin, C #, etc. ont des spécifications de langage qui facilitent l'écriture des méthodes getter / setter. Dans Kotlin, envisagez de créer le même modèle utilisateur créé en Java ci-dessus.

class User{
    public name: String
    public age: Int
    public isAdmin: Boolean
}

Ici, lors de la modification des spécifications telles que «laisser un journal lors de l'accès au champ de nom», il suffit de réécrire comme suit.


class User{
    public name: String
        get(){
            println("Le nom a été consulté")
            name
        }
    public age: Int
    public isAdmin: Boolean
}

En d'autres termes, «le traitement peut être étendu ultérieurement pour l'acquisition et la modification de champs». Cette fonctionnalité peut également servir de délégation de champ, comme suit:

class User{
    private realName: String
    public name: String
        get(){
            realName
        }
        set(value){
            realName = value
        }
}

Cette fonctionnalité est fournie dans Kotlin, C # sous le nom "getter / setter".

Résumé

Je suis très satisfait des spécifications de langage qui peuvent être étendues ultérieurement, telles que Kotlin et C #.