Java Developer
  • Композиция vs Наследование в Java

    — задавая вопросы по ООП, вы всегда будете скатываться в синтетические и абсурдные примеры

    В статье упомянуты три задачи по компоновке (чтобы не употреблять громких слов вроде ООП, архитектуры, дизайна) кода. На мой взгляд у них есть вполне быстрые и практически-разумные решения.

    — вашему собеседнику, надо будет хаотично догадываться, чего же вы от него на самом деле ожидаете

    Кажется, вы домысливаете за собеседника и за меня. В компоновке кода нет единственно правильных решений. Мне важно посмотреть ход рассуждений кандидата.

  • Композиция vs Наследование в Java

    Спасибо за ссылку. Не подозревал, что существует так много вариантов ответов.

  • Композиция vs Наследование в Java

    Мiй варiант у кiнцi статтi.

  • Композиция vs Наследование в Java

    Боюсь, мы сейчас уйдём от темы.

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

    Мой пример — с отчётами — близок к текущему проекту. Возведение в степень и другая длинная арифметика, с одной строны, у нас не используются, с другой — я сходу не соображу как умножение в столбик (если я правильно понял вашу задачу) поможет прояснить понимание наследования.

  • Композиция vs Наследование в Java

    Нет, конечно, в задаче нет никаких обязательных условий, даже те, которые таковыми заявлены :-)

    Единственно, хочу заметить, что задача про компоновку кода. Пример с отчётами не совсем удачный, потому что провоцирует на всякие темплейты. Пусть будут не отчёты, а дома.

    Ваш вариант решения?

  • Композиция vs Наследование в Java

    Да перестаньте просто эти бесполезные вопросы задавать на собеседовании.

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

  • Композиция vs Наследование в Java

    Любой программист с ненулевым опытом работы с ООП прочитав её скажет, что оба ответа бессмысленны

    Да, мне искренне хотелось, чтобы так и было.

    Поддержал: Yarik Ponomarenko
  • Композиция vs Наследование в Java

    Извините, Ринат. Провокативно, не отрицаю. Но разве на работе и в жизни не бывает таких ситуаций, когда нужно выходить за рамки поставленных условий?

    ru.wikipedia.org/wiki/Ложная_дилемма

  • Композиция vs Наследование в Java

    Пожалуйста, у меня был бы абстрактный класс Фигура с абстрактными методами для подсчета площади, периметра, чем-то еще. И все мои квадраты, кружки прямоугольники просто бы реализовывали этот базовый класс. Как-то не круто кастить что квадрат к прямоугольнику, что прямоугольник к квадрату. Главное чтобы фигуры были readonly.

    Правильный ответ, конечно. Мой ответ — в конце статьи.

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

    Тут, извините, не понял. Что значит «обмазывать людей»? Или это опечатка «обмаНывать»?

  • Композиция vs Наследование в Java

    Могу я спросить, каков бы был ваш ответ на задачу про квадрат?

  • Композиция vs Наследование в Java

    а как же принцип never repeat yourself? ваш код выглядит как сплошной копипаст, однако, он дает долю flexibility, но количество кода растет пропорционально

    DRY — это хороший принцип. Но в приведённом примере DRY с помощью наследования не справился с изменившимися требованиями. Поэтому предлагается перейти к композиции и, если необходимо, снова вспомнить о DRY, но уже другими способами.

    кстати, репорт не должен сам себя генерировать/печатать — в этом изначальная ошибка вашего подхода

    С одной стороны, это просто пример вынесения общего кода в базовый класс, может не самый удачный, но я к нему привык. В комментариях на это указывали, что должен быть ReportPrinter.
    С другой — как вам такое мнение www.yegor256.com/.../objects-end-with-er.html ?

  • Композиция vs Наследование в Java

    Супер аргумент. Он настолько сильный ( в плане отбить желание строить дальнейший диалог), что на нем ответ можно было бы и закончить.

    Извините, Антон. Во-первых, это некоректный аргумент, во-вторых, как показали в одной из веток, слабый. Если позволите, я хотел бы взять эти слова назад.

    По поводу предложенного решения проблемы

    Поскольку в джаве нет множественного наследования, от одного класса можно как наследоваться, так и строить декоратор. Более того, в случае наследования код будет короче символов будет меньше. Но означает ли это, что нужно применять наследование?!

    Я за вариант

    Опять же, можно создать базовый класс, и определить в нем конструктор, который принимал бы как аргумент, обьект — читалку цсв,

    только без слова «базовый».

    Посмотрите, пожалуйста, статью www.yegor256.com/...omposable-decorators.html

  • Композиция vs Наследование в Java

    Согласен по всем пунктам. И, вообще, весьма признателен за филигранную аргументацию.

    Однако, давайте вернёмся к исходной задаче про репорты с её изменяющимися требованиями. Могу я спросить, какой дизайн бы вы предложили?

  • Композиция vs Наследование в Java

    Задача про квадрат — не капризничание, а проверка усвоения материала в стиле:

    — Здесь нельзя яблоки есть, они отравленные. Поняли?
    — Да!
    — Какое съедите — чёрное или синее?
    — Синее!

    Поддержал: Alexandr Sova
  • Композиция vs Наследование в Java

    Спасибо за ответ.

    Да, действительно, начальную задачу можно решить с помощью наследования и Template Pattern-a. Да, вначале утверждается, что требования не могут меняться, а потом они меняются. Имхо, лучший возможный ответ кандидата — условие изменилось, переделываем на композицию. Не буду отрицать, что задачи и про отчёты и про квадрат сформулированы несколько провокационно.

    Что в моих пунктах, что в вашем ответе, используется выражение «скорее всего», что смягчает категоричность высказывания.

    Пункт 3 «в наследниках переопределяются» противоречит принципу Лисков, который, конечно, тоже не догма, а сигнал.

    Я неоднократно наблюдал в проектах, когда создавалась иерархия классов, а потом, при изменении требований, наследование становилось неподходящим приёмом, а переделка на композицию, на реальном проекте, а не на собеседовании, при всей поддержке IDE — это всё таки переделка, с ценой в виде времени-денег-тестирования.

    Безусловно, и этот аргумент не означает, что композицию нужно превентивно использовать всегда, а лишь в 97% случаев :-)

  • Композиция vs Наследование в Java

    А как же 4 линии через 9 точек, выход за рамки и всё такое? Не всегда нужно выбирать из предложенных вариантов.

    Поддержал: Дмитро Бугай
  • Композиция vs Наследование в Java

    Спасибо за обсуждение задачи, в конце статьи добавлен авторский ответ

    Поддержал: Дмитро Бугай
  • Композиция vs Наследование в Java

    Может, раз такое чувство, подскажите к кому конкретно в Люксофте за деньгами обратиться?

    Побудили собеседования, я же написал об этом.

  • Композиция vs Наследование в Java

    Давайте, пока я не добежал до стены и ещё жив, уточним: мы про библиотеку на каком языке? Есть ли в нём понятие интерфейсов? Если что, я ещё раз подчеркну, что расширять интерфейсы можно.

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

  • Композиция vs Наследование в Java

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

    Себе я, например, позволяю иметь BaseIntegrationTest с шапкой аннотаций и кучу его наследников. Но это, так сказать, техническое использование, а не настоящее :-)

← Сtrl 1... 789101112 Ctrl →