LINUX.ORG.RU
Форум — Development  

Помогите в решении ООП, TDD.

 ,


1

2

Опять от меня ООП-шный вопрос. Взгляните на код:

interface Job {
    String getName();
    Location getLocation();
    int getActionRadius();
    boolean isInArea(Location otherLocation);
}

class ViewData {
    .....
}

interface ViewDataBuilder {
    ViewData buildFromJob(Job job);
}

Вот тут у нас Job, который предоставляет геттеры для своих данных и какое-то поведение, isInArea().

Для отображения данных в представлении необходимы методы доступа. Т.к. разработка ведется через тестирование (TDD), то Job является интерфейсом.

Суть топика: Мне ненравится, то, что Job это интерфейс, но его необходимо использовать в каком-то другом классе, на который пишется тест. С другой стороны интерфейс тут неудобно.

Может кто-нибудь видит какие-то варианты решения?

isInArea() лишняя в списке методов. getLocation() достаточно. И отдельно пусть будут функции для проверки условий по параметрам джобов (Location, ActionRadius), в том числе и принадлежность локации. Тем самым тебе удасться оттестировать алгортимы работы с параметрами джобами без джобов целиком.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от pozitiffcat

Смущает что:

interface Job extends Spot {
    String getName();
}

interface Spot {
    Location getLocation();
    int getActionRadius();
}

class IntersectionService {

    boolean isIntersect(Spot spot, Location location);

}
Deleted
()
Ответ на: комментарий от Deleted

Вы предлагаете использовать другой класс, который будет использовать чужие данные, не имя своих, по сути это функция, из этого следует, что это не ООП, а процедурное программирования.

pozitiffcat ★★★
() автор топика
Ответ на: комментарий от pozitiffcat

это фейспалм а не ООП, потому что любая концепция в основе своей содержит идеи направленные на упрощение работы программиста в т.ч. в дальнейшем. Если ты не понимаешь зачем это но делаешь тупо потому что так велит концепция - то у тебя проблемы.

Deleted
()
Ответ на: комментарий от pozitiffcat

Мало принципов, нужно больше!

Deleted
()
Ответ на: комментарий от RedPossum

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

1. для определения этой операции на точке нам достаточно локации и радиуса - т.е. метод не использует внутреннее состояние

2. при различных реализация интерфейса - тело метода всегда будет одинаково

3. при разрешении пересечений с ... отрезком (прямоугольником, кривой) - будет совсем другой код использующий те же getLocation getActionRadius

Очевидное решение - использовать базовый абстрактный класс (или фишку из java8) - допустимо, но приведет к загромождению интерфейса методами которые _можно_ вынести и сгруппировать в некий «утилитный» сервис, на деле это может быть примитивный utils класс с статическими методами, но тут надо учитывать специфику - разруливание пересечений может в некоторых случах быть затратной и частой операцией (в игре например) и в конечном итоге все кончится пространственным индексом в котором болтаются наши объекты - и тогда тогда уже ни метод в объекте, ни статический не будут толком нас устраивать 8) .

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development