Qu’est-ce que la programmation d’interfaces ? Jouons à l'architecte

Peut-être avez-vous déjà entendu parler de la « programmation d’interfaces ». Il est temps de mieux connaître cela. Il y aura peu de texte et beaucoup de code (sans logique). Je n'ai pas pu savoir quand les premières interfaces sont apparues. C’était probablement il y a très longtemps et Internet l’a oublié. De toute façon. L'idée de l'interface est simple : décrire ce que l'on va faire sans entrer dans les détails. Ceux. peu importe la façon dont vous le faites, ce que vous faites compte. Mais après avoir écrit cet article, j’en ai trouvé un bon sur un sujet similaire ici en groupe. Cliquez sur le lien et lisez, plus c'est mieux ! Contenu:

• Pourquoi est-ce nécessaire ?
• Qu'est-ce que cela apporte au développeur ?

Pourquoi est-ce nécessaire ?

Lorsque le code est constitué d’une seule classe, cela n’est pas vraiment nécessaire. Mais lorsque les classes doivent interagir les unes avec les autres et que leur nombre dépasse plusieurs dizaines, alors il est temps de penser au design. Tout d’abord, réfléchissez à toute la structure du projet de haut en bas (de l’abstraction maximale à la mise en œuvre). Si plusieurs personnes travaillent sur un projet, alors il est très pratique de se mettre d'accord, de décrire les interfaces d'interaction des classes, puis de démonter ces interfaces et de commencer à les implémenter. Le résultat est un bon parallélisme des tâches ; elles sont faciles à répartir, car tout le monde est d’accord sur tout, mais personne ne se soucie des détails.

Qu'est-ce que cela apporte au développeur ?

Le développeur n’a pas besoin d’une implémentation de la classe. Cela signifie qu’une fois que tout le monde est d’accord, il prend les interfaces dont il a besoin et les utilise. L'implémentation sera remplacée lorsqu'elle sera prête. Laissez-moi vous montrer mon exemple, puis nous en reparlerons davantage. J'ai décidé d'écrire un petit projet de caisse enregistreuse. Elle aidera à choisir les billets, à les vendre, à donner et à retirer de l'argent à la banque, à changer de l'argent pour ceux qui viennent en grand nombre. Alors, mon expiration architecturale : PS il n'est pas nécessaire de copier et de créer une structure, par paresse j'ai joint une archive avec du code en fin d'article ;) Structure : Un tas de modèles :

package cashbox.model;

public enum Currency {
    USD,
    EUR,
    RUR
}

package cashbox.model;

public interface Direction {
    /**
     * @return город How цель направления, куда едем/летим/двигаемся
     */
    String getCity();
}

package cashbox.model;

/**
 * модель денег
 */
public interface Money {
    /**
     * @return тип валюты
     */
    Currency getCurrency();

    /**
     * @return сумма денег
     */
    long getAmount();
}

package cashbox.model;

public interface Ticket {
    /**
     * @return направление куда двигаемся
     */
    Direction getDirection();

    /**
     * @return цена билета
     */
    Money getPrice();

    /**
     * @return транспорт на котором передвигаемся
     */
    Transport getTransport();
}

package cashbox.model;

public interface Transport {
}

Paire d'exception :

package cashbox.exception;

public class NoSoMuchMoneyException extends RuntimeException {
}

package cashbox.exception;

import cashbox.model.Money;

public class NoSuchCurrencyException extends RuntimeException {
    private Money money;

    public NoSuchCurrencyException(Money money) {
        this.money = money;
    }

    public NoSuchCurrencyException(String message, Money money) {
        super(message);
        this.money = money;
    }

    public Money getMoney() {
        return money;
    }
}

La caisse enregistreuse est la partie la plus importante :

package cashbox;

import cashbox.exception.NoSoMuchMoneyException;
import cashbox.exception.NoSuchCurrencyException;
import cashbox.model.*;
import javafx.util.Pair;

import java.util.List;
import java.util.Map;

public interface CashBox {

    /**
     * @param direction направление билета
     * @return Стоимость проезда по видам транспорта
     */
    Map<Transport, Money> getPrice(Direction direction);

    /**
     * Продать билет
     * @param money деньги за билет
     * @return пару из билета и сдачи
     */
    Pair<Ticket, Money> sellTicket(Money money);

    /**
     * обмен валюты
     * @param moneyFrom валюта, которую передает клиент
     * @param currency валюта, которую клиент хочет получить, тут будет учитываться только тип валюты,
     *                 количество будет проигнорировано
     * @return Требуемая валюта
     * @throws NoSoMuchMoneyException если недостаточно денег в кассе для обмена
     * @throws NoSuchCurrencyException если нет такой валюты, отсутствующая валюта передается How атрибут
     */
    Money change(Money moneyFrom, Currency currency) throws NoSoMuchMoneyException, NoSuchCurrencyException;

    /**
     * Инкасация - отправить деньги в банк
     * @param money - сумма и валюта, можно передать несколько
     */
    void sendToBank(Money... money);

    /**
     * Запрос денег из банка
     * @param money - сумма и валюта необходимая кассе
     */
    void requestFromBank(Money... money);

    /**
     * Подбор билета.
     * В метод передается либо одно, либо другое, либо вместе.
     * Если оба атрибута null значит вызов некорректный
     * @param transport - желаемый транспорт
     * @param direction - желаемое направление
     * @return список подходящих билетов
     */
    List<Ticket> chooseBy(Transport transport, Direction direction);
}

La première chose qui attire l’attention d’un développeur non préparé est javadoc. Bien qu'ils soient probablement familiers à un développeur non formé. Certaines personnes sont parfois paresseuses, mais mon code est déjà bon, sans document ;) Même maintenant, je ne veux pas écrire de document sur certaines choses. Eh bien, pourquoi écrire aux transports que c'est du transport ? Laissons ça pour plus tard ! J'ai essayé de décrire dans des documents tout ce qui était nécessaire. Je vais maintenant expliquer pourquoi il est plus pratique d'écrire du code de cette façon. Écoutez, maintenant je peux vous donner une interface CashBoxet vous demander de l'implémenter. N'est-il pas difficile ? De plus, le comportement requis est décrit dans la documentation. Vous n'aurez pas besoin d'attendre que quelqu'un écrive des modèles ou quoi que ce soit d'autre. Vous prenez des modèles d'interface et commencez à travailler sur leur base. Maintenant, vous programmez dans les interfaces, félicitations. Et maintenant l'essentiel. Je peux vous confier la tâche d'implémenter CashBox, ainsi qu'à quelqu'un d'autre, afin que nous ayons 2 implémentations. Par exemple, billetterie suburbaine et internationale. Vous serez en mesure d'écrire du code en parallèle et tout membre de l'équipe qui écrira du code basé sur celui-ci CashBoxpourra déjà commencer et construire sur l'interface. C'est très confortable. Le multitâche, au diable. Lien vers le code sur Google Drive -> ici