Често срещани грешки, които открих при стажанти разработчици: Част 2: Конструктори

С опита, който придобих, работейки със стажанти по софтуерно инженерство, забелязах някои често срещани грешки и модели на програмиране.

Тук съм изброил някои често срещани грешки и лоши практики, които ще бъдат направени от нови разработчици на софтуер. Следователно това ще помогне на новите разработчици на Java да идентифицират и коригират грешките си в бъдеще.

Тази статия е втората от поредицата.

Вторите най-чести грешки в моделните класове се случват в класа Конструктори.

Няма конструктор по подразбиране, където съществуват полета за събиране

Когато има клас с колекции, най-добрата практика е да имате конструктор с инициализация на колекция. В противен случай стойността по подразбиране на колекцията е нула, ако се извика конструкторът по подразбиране.

Но за примитивните полета практиката е те да се инстанцират в линия, а не в конструктора със стойността по подразбиране.

/**
 * Created by Dulaj on 2019-05-28.
 */
public class DataHolder<T> {
    
    private String id = "";
    private List<T> data;
    
    public DataHolder() {
        data = new ArrayList<>();
    }
    
    public List<T> getData() {
        return data;
    }
    
    public void setData(List<T> data) {
        this.data = data;
    }
}

Извикване на нефинални методи в конструктори

Извикването на нефинални методи ще доведе до неочаквано поведение, тъй като в дъщерните класове този нефинален метод може да бъде заменен. Следователно поведението може да не е същото като очакваното. (извикването на метода super ще извика заместен дъщерен метод и това може да причини грешки). „Външен пример“

Причината за тези проблеми ще бъде главно защото, ако методът бъде заменен, има достъп до поле на дъщерен клас, което ще бъде инициализирано в конструктора. Но извикването на публични окончателни методи или частни методи (и двата не могат да бъдат отменени) никога няма да доведе до такива проблеми и е безопасно да се извика в конструктора.

Конструктор/ Метод с голям брой параметри

Методът с голям брой параметри ще доведе до по-малка четимост и разбираемост на кода. Следователно конструкторът и другите методи трябва да имат ограничен брой параметри. Ако някой метод се нуждае от много параметри, тогава трябва да ги капсулираме (използвайки допълнителен клас).

Полезните класове се нуждаят от частен конструктор

Util Class е клас само със статични членове (методи и полета).

По принцип помощен клас без частен конструктор ще доведе до създаване на екземпляр по погрешка и ще скрие полезния характер (не е предназначен да създава екземпляри). Но целият смисъл на наличието на клас Util е да се извикват неговите методи с помощта на класа (не от екземпляра). Java ще добави конструктор по подразбиране към всеки клас, ако не е деклариран изрично. Следователно е необходимо да имате частен конструктор, за да избегнете инстанциране.

Примерът по-горе показва клас само със статични членове и частният конструктор ще се погрижи да не създава екземпляри отвън.

След това можете да извиквате методи и да осъществявате достъп до полетата като това.

int length = SampleUtil.getLength("sample text ");
String key = SampleUtil.KEY;

Нека да видим някои общи грешки в част трета от поредицата статии.

Моля, оставете коментар по-долу, ако имате въпроси или отзиви.

Ако харесвате тази публикация, последвайте ме в Medium за още подобни публикации.

Ако имате някакви притеснения или въпроси, моля, използвайте секцията за коментари по-долу.