Считается ли это низкой связанностью и высокой связностью? Есть шанс улучшить?

Я пытаюсь усвоить принципы SOLID Роберта С. Мартина. В настоящее время я изучаю низкую связанность и высокую сплоченность. Я создал некоторый код, который представляет мое текущее понимание этого предмета. Не могли бы вы, ребята, сказать мне, если на правильном пути? Есть ли шанс улучшить текущий дизайн?

Основное приложение, которое создает два адреса и присваивает их сотруднику:

public class App {

    public static void main(String[] args) {
        Address homeAddress = new HomeAddress("This is my Home Address");
        Address workAddress = new WorkAddress("This is my Work Address");        
        Employee employee = new Employee(homeAddress, workAddress);

        employee.getAddresses();
    }

}

Класс сотрудника:

public class Employee {

    private Address homeAddress;
    private Address workAddress;

    Employee(Address homeAddress, Address workAddress) {
        this.homeAddress = homeAddress;
        this.workAddress = workAddress;
    }

    public void getAddresses() {
        System.out.println("homeAddress: " + homeAddress.getAddress());
        System.out.println("workAddress: " + workAddress.getAddress());
    }

}

Адресный интерфейс:

public interface Address {

    String getAddress();

}

Конкретная реализация адреса 1 (HomeAddress):

public class HomeAddress implements Address {

    String specificAddress;

    public HomeAddress(String specificAddress) {
        this.specificAddress = specificAddress;
        System.out.println("In HomeAddress Constructor");
    }

    public String getAddress() {
        return specificAddress;
    }
}

Конкретная реализация адреса 2 (WorkAddress):

public class WorkAddress implements Address {

    String specificAddress;

    public WorkAddress(String specificAddress) {
        this.specificAddress = specificAddress;
        System.out.println("In WorkAddress Constructor");
    }

    public String getAddress() {
        return this.specificAddress;
    }
}

Любая помощь/отзыв будет принята с благодарностью! Заранее спасибо.

Марк.


person M. Groenhout    schedule 02.11.2018    source источник
comment
Зачем нужен тип, чтобы отличить рабочий адрес от домашнего? В предоставленном вами коде вы не обогащаете ни один из подклассов новыми функциями, что делает их избыточными.   -  person Alexandre Dupriez    schedule 02.11.2018
comment
Оба адреса делают то же самое. Возможно, вам на самом деле не нужны две реализации   -  person Héctor    schedule 02.11.2018
comment
Что касается низкой связанности и высокой связности, ваш код правильный. Но обратите внимание, что с такой легкой моделью трудно не соблюдать эти принципы.   -  person davidxxx    schedule 02.11.2018
comment
Я согласен. В этом примере оба адреса делают одно и то же. Так что в этом случае это сделает только одна реализация. В случае, если у них обоих была другая реализация, я должен был создать две отдельные. Спасибо. Ребята, что вы думаете о высокой связности и низкой связанности в этом примере? Правильно ли я здесь поступаю?   -  person M. Groenhout    schedule 02.11.2018
comment
@davidxxx Спасибо. Я понимаю, что это просто схема. Для меня это все о понимании основ.   -  person M. Groenhout    schedule 02.11.2018


Ответы (1)


Это небольшой пример, но его можно улучшить с точки зрения связи/сплоченности.

Объекты сплочены. Почему? В объекте Employee и конструктор, и getAddresses() (который, кстати, должен называться printAddresses()) ссылаются на обе переменные экземпляра (что означает, что они связаны с одним и тем же). То же самое для объектов Address.

Что касается соединительной части, я думаю, вы могли бы сделать лучше. В нынешнем виде объект Employee «знает» (т. е. связан) с внутренним представлением объекта Address. Это потому, что вы «экспортируете» данные (строку) из объекта Address вместо того, чтобы печатать их прямо там, где находятся данные.

Это делает ваши объекты более связанными и приведет к тому, что любые изменения (например, добавление Street и City и тому подобное) в объектах Address будут просачиваться в Employee. Так что у него есть реальные минусы.

Решение состоит в том, чтобы определить метод print() в Address и выполнить System.out.println() там. Это соответствует другим концепциям, таким как Закон Деметры, Говори, не спрашивай.

person Robert Bräutigam    schedule 05.11.2018
comment
Спасибо, @Robert Bräutigam. Отличный отзыв. Я согласен. Employee знать (или принимать решение) о внутреннем представлении объекта Address действительно плохая идея. В этом случае изменения коснутся трех классов Employee, HomeAddress и WorkAddress. Я лично также назвал бы это «неправильным уровнем абстракции». - person M. Groenhout; 07.11.2018