Здравствуйте!

Есть такой код:

Конкретно в моём примере метод getFoodCost не является частью интерфейса и реализующих его классов, это некий внешний метод

interface Subdivision {
    int numberOfEmployers();
}

class Workshop implements Subdivision {
    @Override
    public int numberOfEmployers() {
        // тут должна быть реализация интерфейса
    }
}

class Department implements Subdivision {
    @Override
    public int numberOfEmployers() {
        // тут должна быть реализация интерфейса
    }
}

class Service {
    public static void main(String[] args) {
        Workshop workshop1 = new Workshop();
        Department department1 = new Department();
        // some code
        int sum1 = getFoodCost(workshop1);
        int sum2 = getFoodCost(department1);
    }

    public static int getFoodCost(Subdivision subdivision) {
        return subdivision.numberOfEmployers() * 300;
    }
}

Подскажите пожалуйста правильно ли я отобразил отношения между классами описанных в коде? А именно между service и интерфейсом Subdivision?

Не могу утверждать точно на 100%, но

Реализация интерфейса изображена корректно, тут нет проблемы, но вот ассоциация между классом Service и интерфейсом Subvision, мне кажется не правильной.

Среди атрибутов Service два, один типа Workshop, другой Department, т.е. Service по идее должна иметь две ассоциации - одну к Складу, другую к Отделу. Если же имелась ввиду реально одна ассоциация, то атрибут должен иметь тип интерфейса

@Galogen

не ту диаграмму прикрепил. Обновил диаграмму. Это метод.

Подскажите пожалуйста правильно ли я отобразил отношения между классами описанных в коде? А именно между service и интерфейсом Subdivision?

Связь с классом, описывающим тип параметра операции (как и тип локальной переменной в теле метода) -- это зависимость, а не ассоциация. Обоснование просто. Такие переменные "живут" лишь в течение вызова, в отличие от атрибута, который "живёт" время, сравнимое с временем жизни связанного объекта.
Рекомендации:
Убрать ассоциацию Service -----> Subdivision.
Добавить зависимость Service - - -> Subdivision.
Добавить зависимость Service - - -> Workshop.
Добавить зависимость Service - - -> Department.

P. S. И разбирать примеры в подфоруме про примеры.

Спасибо большое за ответ и внимание к вопросу.
1. да согласен с вами, что это не ассоциация, а зависимость.
2. Почему связь Service - - -> Department, Workshop.  Ведь в классе Service есть метод который обращается к интерфейсу Subdivision. А уже непосредственно из интерфейса к классам реализующих его.

Код: [Выделить]

public static int getFoodCost(Subdivision subdivision)
Таким образом хотелось показать "полиморфизм".

3.  Извините, не нашел подфорум про примеры. Поэтому пока осмелился здесь продолжить свой вопрос.
Если подскажите ссылкой на подфорум, буду благодарен.

Связь с классом, описывающим тип параметра операции (как и тип локальной переменной в теле метода) -- это зависимость, а не ассоциация. Обоснование просто. Такие переменные "живут" лишь в течение вызова, в отличие от атрибута, который "живёт" время, сравнимое с временем жизни связанного объекта.
Рекомендации:
Убрать ассоциацию Service -----> Subdivision.
Добавить зависимость Service - - -> Subdivision.
Добавить зависимость Service - - -> Workshop.
Добавить зависимость Service - - -> Department.

P. S. И разбирать примеры в подфоруме про примеры.

Почему связь Service - - -> Department, Workshop.  Ведь в классе Service есть метод который обращается к интерфейсу Subdivision. А уже непосредственно из интерфейса к классам реализующих его.

В коде в описаниях метода Service::main упоминаются классы Department и Workshop как типы локальных переменных. Этого достаточно для зависимостей. Если стоит цель сделать Service независимым от Department и Workshop, то workshop1 и department1 должны иметь тип Subdivision, а их создание следует поручить какой-нибудь фабрике (которая будет знать про Department и Workshop и зависеть от них). Фабрика позволит другим классам получать экземпляры классов, реализующих интерфейс, не зная имён этих классов и не завися от них.

Таким образом хотелось показать "полиморфизм".

Полиморфизм есть в Service::getFoodCost, но зависимость от классов, реализующих интерфейс, сохраняется из-за main.

Примеры тут.