Рубрики
Без рубрики

Технический долг или мы должны улучшить качество нашей кодовой базы

Сообщение о хороших принципах ВВЕРХУ. С тегами java, best practice, ood, ооп.

В этой статье я бы рассказал об одном важном качестве кода – обслуживании.

  1. Проблема.
  2. Два способа решить ваш технический долг.
  3. Статические методы
  4. Добытчики и сеттеры
  5. Избегайте null.
  6. Вывод.

Проблема

В техническом мире существует такой факт, как технический долг. Похоже, мы должны посвятить время улучшению поддерживаемой кодовой базы нашего продукта. Например, мы работаем над приложением для Android. Мы должны доставить приложение конечному потребителю как можно скорее. Но приходит время, когда вы уже не понимаете, что происходит в приложении, есть много зависимостей или избыточных блоков if – else, в то время как некоторые вещи можно упростить. Так что посвятить время улучшению вашей кодовой базы может быть хорошим решением. Прежде всего, лично для вас – вы будете благодарны себе за это, в то время как другие тоже будут благодарны вам за это. Недавно я прочитал “Эффективную Java” Джошуа Блоха и “Элегантные объекты” Егора Бугаенко. Эти две книги противоположны друг другу.

Два способа решить ваш технический долг

Статические методы

Джошуа Блох – статический метод хорош , он может использовать вместо этого конструктор. Например:

public class Car {

    //Client of this does not may create object by this way. Only static
    private Car() {
    }

    //Create a default car for client.
    public static Car getDefaultCar() {
        return new Car();
    }
}

Вместо этого этот Элегантный объект говорит нам:

Статические методы – это зло, не используйте его! Но если ваш процедурный программист, вы можете использовать его:)

Добытчики и сеттеры

В течение многих лет мы рассматривали методы получения и установки как инкапсуляцию состояния объекта. Но это неправда. Мы можем влиять на это внутреннее состояние с помощью методов настройки. Например:

public class Cash {
    private int dollars;

    public Cash(int dollars) {
        this.dollars = dollars;
    }

    //Influence on the internal state on the object
    public void setDollars(int dollars) {
        this.dollars = dollars;
    }

    public int getDollars() {
        return this.dollars;
    }
}

t – не очень хороший метод для создания изменяемого объекта, гораздо лучше иметь неизменяемый объект, такой как java.lang. Строка

public class Cash {
    private final Integer dollars;

    public Cash(final Integer dollars) {
        this.dollars = dollars;
    }

    public Integer usd() {
        return this.dollars;
    }
}

В этом случае у нас нет возможности изменить внутреннее состояние объекта. Чтобы представить новую наличность, мы должны создать новый объект.

Избегайте нулевого значения

Иногда у вас есть метод, который принимает null в качестве аргумента. Например:

public class FileFinder {
    private final File file;

    public FileFinder(final File file) {
        this.file = file;
    }

    public List findByMask(IMask mask) {
        if (mask == null) {
            return mask.all();
        }
        return mask.find(file);
    }

    public static void main(String[] args) {
       IMask mskMask = new Mask("*.msk");
       List mskFiles = new FileFinder(args[0]).find(mskMask);

       //Get all files
       List allFiles = new FileFinder(args[0]).find(null); 
    }
}

Этот код выглядит правильным, но в нем много бесполезных слов. Не используйте null, используйте объект-заглушку. С помощью stub object приведенный выше код будет выглядеть следующим образом:

public class FileFinder {
    private final File file;

    public FileFinder(final File file) {
        this.file = file;
    }

    public List findByMask(IMask mask) {
        return mask.find(file);
    }

    public static void main(String[] args) {
        IMask withouAnyMask = new WithoutAnyMaskImpl();
        List allFiles = new FileFinder(args[0]).find(withoutAnyMask); 

    }
}

Лично для меня второй вариант более удобочитаем и понятен. Также это не приводит к уродливому NullPointerException .

Вывод

Я предлагаю прочитать обе книги, чтобы получить более глубокое понимание того, как улучшить качество кода. Также я рекомендую подумать о ремонтопригодности вашей кодовой базы, потому что это действительно важно.

Следуйте за мной 😉

Оригинал: “https://dev.to/vrnsky/technical-debt-or-we-must-improve-our-code-base-quality-n6b”