Java Developer
  • Менеджерско-программистская выжимка за 17 лет в отрасли

    Очень толково изложено и без воды.
    Пишите ещё, пожалуйста.

  • Абстракция для программистов, или как я забыл MySQL и потерял 1500у.е

    но не пишем ради конкретного приложения ни строчки

    Это прорыв! Скажите, над автогенерацией БД и проверкой орфографии работа не ведётся?

  • Абстракция для программистов, или как я забыл MySQL и потерял 1500у.е

    А вы какой-то код пишете? Можно привести пример клиентского кода к вашему CRUD?

  • Абстракция для программистов, или как я забыл MySQL и потерял 1500у.е

    Забористо!

    то мне сказали, что сейчас будет абстрактный класс, и смело показали ПУСТОЙ класс...
    Единожды написаный код обслуживает все четыре действия с базами данных: создать, изменить, извлечь, удалить запись.

    Spring-Data

    public interface EntityRepository extends CrudRepository<Entity, Long> {}

    Оно?

    Поддержал: Taras Murzenkov
  • Нужны советы по GOF паттернам

    Если для джуниоров, то, на мой взгляд, был бы хорош такой подход.
    1. Поставить задачу.
    2. Показать, как она решается «в лоб».
    3. Показать, к каким проблемам это приводит. Основных вижу две: это постоянная модификация существующего кода и затруднённое его тестирование. В результате, тесты не пишутся вообще, работает ли новый функционал и не поломался ли старый — неизвестно.
    4. Применить шаблон проектирование. Показать, что проблемы из предыдущего пункта решились.
    5. Как вишенку на торте, рассказать, какие появились новые :-)

    Видел статьи, в которых пункты 2 и 3, для краткости, выбрасывались. Дескать, делать надо так, а почему — должно быть очевидно. А для джуниоров это не очевидно.

    На ютюбе когда-то видел хороший ролик, который заодно ТДД демонстрировал. Автор показывал пример калькулятора с арифметическими действиями. Сначала написал тесты, потом реализовал операции через if-ы, потом перешёл к фабрике.

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

    Згоден з вами. Не зважайте, стаття написана дещо гротексно. Тим не менш, хочу зауважити, що у статичних методів, наслідування і може й в пхп (не знайомий, не можу дискусутувати) дійсно є вагомі недоліки. Ви слушно зауважили про професіоналізм й інструменти, але я, нажаль, чимало стикався з підходом «спільний код виносимо в базовий клас» і от, як вмію, висвітлюю альтернативу — композицію.

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

    Оказывается сообщения можно посылать не только другим объектам

    Мне видится, что посылка сообщения — это несколько более широкое понятие чем вызов метода. И, да, мне кажется, что предпочтительнее, чтобы в коде было именно объект.метод(), я собираюсь написать пост на эту тему.

    Богдан, раз вы критикуете этот момент, может не откажете в любезности взглянуть на черновик? Или сразу какой-то аргумент приведёте, может я полностью заблуждаюсь?

    Своим «хорошим» наследованием вы требуете отказаться от отказаться от целого пласта полиморфизма.

    Я вообще призываю наследованием не пользоваться, чего тут пластами мелочиться :-) Также честно написал, что затрудняюсь привести хороший обучающий пример. В комментах два раза упомянули иерархию UI-контролов. Может вы что-то добавите из рабочей практики или упомянутого пласта?

    Пункт 3 «в наследниках переопределяются» противоречит принципу Лисков

    Спасибо, вы совершенно верно поправили.

    Нет, переопределение не противоречит. Оно может противоречить, а может и нет.

    Нужно сформулировать как-то мягче, в стиле «если уж переопределяйте, то крайне аккуратно, помните про LSP, не изменяйте поведение»

    Собеседование — это не экзамен, тут не эффективно использовать понятие «ответ засчитан или нет».

    И я так считаю, но мне нужно выражаться яснее. Разрешите переформулировать. Если кандидат в задаче про отчёты может перейти к композиции при изменении требований, его техническая адекватность оценивается выше, нежели позиция «Общий код всегда должен выноситься в базовый класс, других вариантов я предолжить не могу».

  • Идеальный код

    Из текста статьи — toList и replace

  • Идеальный код

    На первый взгляд, ваши примеры на шаблон Фабрика не похожи. Также есть такое, например, мнение www.yegor256.com/...e-to-utility-classes.html

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

    Простите, но вот вы своей статьей и ответами на комменты продемонстрировали полное непонимание ООП

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

    Спринт и марафон — это разные дисциплины :)На простом примере вы проверите только то как человек справляется с простыми (а в вашем случае универскими) задачами.

    Спасибо, кэп. А на сложном примере — как со сложными задачами. А как с работой будет справляться — дайте угадаю — по результатам испытательного срока?

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

    Иван, спасибо за подробное изложение вашего подхода к собеседованиям. В общем и целом, я, естественно, солидарен. Ниже мы с Serhiy Serbin приблизительно то же самое обсуждали, только акценты по-другому расставлены были.

    Если кандидат не знает, то собеседование заканчивается?

    Прошу прощения за категоричность, оно не начинается. По странному стечению обстоятельств, в таких случаях обычно и с hashCode() путаются.

    Меня в собеседованиях всегда смущали вопросы типа «назовите принципы ООП»

    Я тоже не сторонник спрашивать чеканные формулировки.

    то есть задачу, результатом которой будет код. И он либо работает, либо нет.

    Солидарен. Набросок кода лучше разговоров, работающий код лучше наброска.

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

    Алгоритмические задачи типа разворота строки, как предлагали вы, или возведение натурального числа в степень, как предлагал Сергей, с одной стороны не помешают, с другой — я пока не понимаю, с каким весом их оценивать.

    Вопросы что и как важны, но важнейший, на мой взгляд, — почему.

    Спасибо, верный акцент.

    Я не вижу проблемы в том, что кандидат не знает каких-то паттернов или выберет «не тот» вариант.

    Аналогично. Но я, к сожалению, сталкиваюсь с ситуацией, когда срабатывает установка «общий код нужно выносить в базовый класс», а при изменении требований наступает ступор, хотя вроде как композицию обсуждали 5 минут назад.

    Ну не верю я, что вы дадите ему сразу с нуля проектировать новую систему, или новый оригинальный модуль в имеющейся системе.

    Систему и модуль — конечно, нет. А новые классы ему, скорее всего, создавать придётся. И я беспокоюсь, как они будут скомпонованы.

    Давайте будем на собеседовании и в заданиях / вопросах ближе к повседневной работе, к существующему проекту и процессам на нем

    Безусловно, стараюсь как могу.

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

    Спасибо за вопросы.

    1. Middle java developer.
    2. Вводные вопросы для общей оценки знаний кандидата в ООП. Например, кандидат может не знать понятия интерфейса.
    3. Практически проверить понимание проектирования на простом примере.
    4. Решение принимает менеджер с учётом в том числе технического фидбека. Если кандидат даёт правильные ответы, фидбек позитивный.
    5. Если кандидат предлагает дизайн, позволяющий без копи-паста скомпоновать отчёты, ответ засчитывается. Мною. Если говорит, что не знает, как решить задачу, ответ не засчитывается.

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

  • Идеальный код

    Не сочтите за придирки, сам о идеальном коде радею.

    0. Все примеры — статические методы. Хорошо ли это?
    1. Раз мы узнали (действительно есть такая проблема?) про Collections.singletonList, то может сразу его использовать, без прослойки toList?
    2. Понимаю, что пример с replace условный, но название метода не говорящее само-объясняющее.
    3. cronExpression точно мутабельное поле? Если нет, почему бы просто не использовать упомяную константу? Если вдруг да, опять же, достаточно ли говорящее название переменной?

    Поддержали: Andrii Vovk, Rostislav Nikitin
  • Композиция vs Наследование в Java

    Вопрос из разряда почему люки круглые или как измерить расстояние с помощью градусника. А в чем отличие между теплым и мягким?

    Извините, вы, по-моему, разные вещи в одну кучу смешали.

    Вопрос по люки призывает задуматься о привычных вещах и имеет чёткий инженерный ответ.
    Измерение расстояния градусником — как я понимаю, о нетипичном использовании инструмента.
    Тёплое и мягкое — классический пример несравнимых категорий.

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

    Это Вы лихо придумали: задать вопрос с двумя неправильными вариантами ответа. Как и в версии «В чём отличие между композицией и наследованием?» вопрос задан не верно.

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

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

    Конечно. Вот я и пытаюсь, как умею, это и объяснить.

    Конкретно для вашего примера таки да не подходит тот вариант наследования

    Рад, что для вас это очевидно. Если бы я не сталкивался с противоположными примерами, вряд ли бы написал эту статью.

    но зачем плодить разные класы для DefaultHeader и DefaultFooter, создали бы один интерфейс для хранения списка компонентов внутри отчета и хранили бы там вашы Header, Footer, Appendix, Body и все что душа пожелает.

    Вроде как именно так и написано. Разные блоки наверное будут реализовывать один интерфейс. Тогда их действительно можно хранить в списке. Всё же, главный посыл был о неприменимости наследования. Как строить композицию — тоже важный вопрос, но выходит за рамки статьи.

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

    то что ваша задача еще более синтетическая, чем квадраты, вам пояснили ниже (этот комментарии является топ ответом на текущий момент).

    Вас не затруднит процитировать часть топ-комментария, где утверждается, что задача про отчёты синтетическая? В любом случае, вот вы говорите, что она надуманная, а мне почти в каждом проекте их приходилось делать. И другие комментаторы сталкивались. Специфика работы. Я бы даже так сказал, что это за энтерпрайз проект без отчётов? :-)

    я прихожу к вам на собеседование — я вообще понятие не имею, чего вы там делаете.

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

    Мне кажется, вы себе нарисовали определённую картину и яростно с ней спорите. Вы лучше спросите, и я вам отвечу — перед собеседованием обсуждается проект, технологии и задачи. Если, допустим, кандидат отличный С-embedded-developer — честь ему и хвала, но наш проект о другом, и отнимать друг у друга время нет смысла.

    да хватит заливать

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

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

    Я вас услышал. Будет более ценно, если вы привёдете примеры таких вопросов. Ок, возведение натурального числа в степень, что ещё?

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

    плюс, я категорически советую не задавать вопросы базирующиеся на вашем ТЕКУЩЕМ опыте — проекте

    Почему? Аргументируйте, пожалуйста.

    Я рассуждаю так. Вот мы работаем, допустим, с таким-то фреймворком, столкнулись с такими-то проблемами, решаем их так-то. Почему не спросить об этом кандидата? Если решает их так же — хорошо, человек в теме. Если по-другому — тоже хорошо, по крайней мере, в курсе проблемы. Если решение лучше — вообще отлично! Ну, а если не сталкивался — это не показатель, говорим тогда о других аспектах.

    можете просто не расслышать рациональное зерно в словах вашего собеседника.

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

    Я не уверен, что таким образом можно проверить понимание дизайна, шаблонов проектирования и т.д

    Это уже мягче. Я тоже не уверен, но пока придумал вот так. Какой вариант вы бы предложили?

    вам какой результат нужен — рабочий код или шаблоны?

    А почему вы противопоставляете? На мой взгляд, нужно и то и другое.

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

    Вопрос не мне, и я, к сожалению, с Go не знаком. Но, не зависимо от языка, я предложил бы рассмотреть вариант композиции: вынести общие поля и методы в отдельный класс и использовать его в упомянутых двух. Об этом, собственно, и статья.

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

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

    Ложную дихотомию на собеседовании я не использую, не та ситуация. Задачу про квадрат не задаю. Здесь я её привёл в несколько провокативном виде для того, чтобы напомнить, что отношение is-a в обычной жизни не всегда означает наследование в ООП.

    У кандидата я спрашиваю то, что реально используется на проекте — знание фреймворков и компоновку кода. Задача про отчёты — об этой самой компоновке.

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

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

    Дякую за приклад. Згода, є системи об’єктів, які утворюють настільки чітку ієрархію, і до дедублювання кода яких дійсно можна застусування наслідування. Але вони радше виняток.

    І тут не обійтися лише одними інтерфейсами.
    Ось тут не певен.
    Поддержал: Alexandr Sova
  • Композиция vs Наследование в Java

    У автора нет возможности редактировать статью.

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

    Попробую ответить ещё раз.

    Эта фраза — квинтэссенция всей статьи: ООП — это когда выражения с точечкой. :)

    Я не утверждал, что ООП — это когда выражения с точечкой. Вы приписали мне утверждение и высмеяли его. Кажется, это приём Pugna.

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

    Целью статьи было показать ограничения применения наследования на примере Template Pattern. Как организовать композицию — это следующий вопрос.

    Своим опусом вы породили не меньше инвалидов от программирование чем университетские сказки про три кита.

    Сильно сомневаюсь, что вы можете подтвердить это утверждение ссылкой на статистику инвалидов. Скорее, это всё же ваше субъективное мнение.

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

    Познавательно. А я по её мотивам хотел напомнить, что отношение is-a реальных объектов не означает наследования.

    P.S. Посыл про то что наследованием классов надо пользоваться очень аккуратно правильный

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

← Сtrl 1... 789101112 Ctrl →