Пациент и врач капец разные класс

Тут хуже все, пациент и врач -это роли людей. Пациент может стать врачём в любой момент и наоборот. Врач даже может лечить самого себя (привет парадоксу брадобрея)

Тут хуже все, пациент и врач -это роли людей. Пациент может стать врачём в любой момент и наоборот. Врач даже может лечить самого себя (привет парадоксу брадобрея)

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

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

> родительскому классу человек тут наследование не нужно.

Я могу просто вписать каждому классу эти общие поля

Сделай сначала просто, ничего не объединяя. Если через какое-то время дублирование ФИО будет причинять боль, тогда и будешь с ним разбираться. Дублирование в двух местах ни капли не страшнее преждевременного обобщения кода

Сделай сначала просто, ничего не объединяя. Если через какое-то время дублирование ФИО будет причинять боль, тогда и будешь с ним разбираться. Дублирование в двух местах ни капли не страшнее преждевременного обобщения кода

с другой стороны сущность в 20 полей уже может быть поводом выделять VO

но тут цель уже не в DRY

с другой стороны сущность в 20 полей уже может быть поводом выделять VO

Может быть, а может и нет. Возвращаясь к ФИО, вряд ли придется переиспользовать одно и тоже ФИО в нескольких местах. Если преждевременно выделять ФИО в Value-Object получиться еще больше дублирования. Вместо простого doctor = Doctor('Telichkin', 'Roman', 'Konstantinovich') Мы получим my_name = FullName('Telichkin', 'Roman', 'Konstantinovich') doctor = Doctor(my_name) my_name больше нигде не переиспользуется, но для создания экземпляров класса нам нужно каждый раз создавать объект FullName patient_name = FullName('Protko', 'Sergey', 'Fesorovich') patient = Patient(patient_name) Естественно, такое дублирование нас не устраивает, и мы вводим фабрику doctor = DoctorFactory.create('Telichkin', 'Roman', 'Konstantinovich') patient = PatientFactory.create('Protko', 'Sergey', 'Fesorovich') Но, как видно, фабрика здесь имеет такой же интерфейс, как конструктор класса в самом первом примере. Так зачем нам нужно усложнять код сначала Value-Object'om, а потом накручивать из-за этого усложнения сверху фабрику?

Может быть, а может и нет. Возвращаясь к ФИО, вряд ли придется переиспользовать одно и тоже ФИО в нескольких местах. Если преждевременно выделять ФИО в Value-Object получиться еще больше дублирования. Вместо простого doctor = Doctor('Telichkin', 'Roman', 'Konstantinovich') Мы получим my_name = FullName('Telichkin', 'Roman', 'Konstantinovich') doctor = Doctor(my_name) my_name больше нигде не переиспользуется, но для создания экземпляров класса нам нужно каждый раз создавать объект FullName patient_name = FullName('Protko', 'Sergey', 'Fesorovich') patient = Patient(patient_name) Естественно, такое дублирование нас не устраивает, и мы вводим фабрику doctor = DoctorFactory.create('Telichkin', 'Roman', 'Konstantinovich') patient = PatientFactory.create('Protko', 'Sergey', 'Fesorovich') Но, как видно, фабрика здесь имеет такой же интерфейс, как конструктор класса в самом первом примере. Так зачем нам нужно усложнять код сначала Value-Object'om, а потом накручивать из-за этого усложнения сверху фабрику?

Зачем вводить фабрику, если можно создавать Name в конструкторе

И да, зачем фабрика?

И да, зачем фабрика?

Чтобы создавать объект не двумя строчками: создание FullName, а потом создание объекта, а одной. Можно создавать Name в конструкторе, но это такое же дублирование, просто вынесенное в совершенно ненужную абстракцию

Чтобы создавать объект не двумя строчками: создание FullName, а потом создание объекта, а одной. Можно создавать Name в конструкторе, но это такое же дублирование, просто вынесенное в совершенно ненужную абстракцию

Дублирование чего?

изначально изза этогоФИО человек хотел общего предка делать. это уже говорит о том,что неплохо бы выделить VO. да и с ФИО постоянно надо чтото делать. краткое Фамилия И.О. и т.д.

выделение этого VO окупится

Ну и вот

http://wiki.c2.com/?PrimitiveObsession

Чтобы создавать объект не двумя строчками: создание FullName, а потом создание объекта, а одной. Можно создавать Name в конструкторе, но это такое же дублирование, просто вынесенное в совершенно ненужную абстракцию

дублирование чего?

все бизнес ограничения привязанные к полному имени будут в одном месте. А если ты под дублирование подразумеваешь факт того что нам надо объект где-то инициализировать и придется делать это в разных местах (например конструкторы разных сущностей)... наверное тогда тяжко какой-нибудь string buidler юзать будет... там же тоже везде и всюду дублирование. или объекты дат

но дублирования как бы... нет)

это как вызов метода, если ты вызываешь его в нескольких местах, но вся логика всеравно внутри, где тут дублирование?

изначально изза этогоФИО человек хотел общего предка делать. это уже говорит о том,что неплохо бы выделить VO. да и с ФИО постоянно надо чтото делать. краткое Фамилия И.О. и т.д.

Пока у него нет требования на создание краткого Ф.И.О, VO не нужен. Не нужно писать код, который может быть потом пригодиться. Когда понадобиться, тогда и напишешь.

тебе уже столько аргументов привели

Пока у него нет требования на создание краткого Ф.И.О, VO не нужен. Не нужно писать код, который может быть потом пригодиться. Когда понадобиться, тогда и напишешь.

когда понадобиться - может стать поздно. объеденять вещи потом проще чем разъеденять.

это не требует никаких усилий - завернуть ФИО в класс

зато мы более явно в коде выразим термин "полное имя"

а может быть нам не полное имя вообще нужно, и т.д. это уже из требований.

Пока у него нет требования на создание краткого Ф.И.О, VO не нужен. Не нужно писать код, который может быть потом пригодиться. Когда понадобиться, тогда и напишешь.

Даже в случае вывода в админке вам не надо конкатенировать три поля, можно в VO реализовать метод toString и все

Я раньше тоже много работал с примитивами, но в последнее время работа с VO очень нравится, аж удовольствие получаешь плюс не дублирую валидацию если есть такая

тебе уже столько аргументов привели

А я такой негодяй все равно про KISS рассказываю. Я не против VO, и не против обобщения. Вообще, хороший код в пределе не содержит повторений. Но человек спрашивал варианты решения задачи без контекста. Без контекста эта задача выглядит простой и усложнять ее новыми сущностями без необходимости не стоит. Kent Beck "Simplicity is the most intensely intellectual of the XP values. To make a system simple enough to gracefully solve only today's problem is hard work."

А я такой негодяй все равно про KISS рассказываю. Я не против VO, и не против обобщения. Вообще, хороший код в пределе не содержит повторений. Но человек спрашивал варианты решения задачи без контекста. Без контекста эта задача выглядит простой и усложнять ее новыми сущностями без необходимости не стоит. Kent Beck "Simplicity is the most intensely intellectual of the XP values. To make a system simple enough to gracefully solve only today's problem is hard work."

> про KISS рассказываю кисс не про то что бы "сделать тупо", а про то что бы "тупо пользоваться" > и не против обобщения тут по сути нет обобщения... хотя как, есть наверное немного... но это не такое жесткое обобщение как скажем наследование. А так - преждевременное обобщение это очень нехорошо, тут я с тобой согласен > Вообще, хороший код в пределе не содержит повторений. большая часть принципов конфликтуют между собой не спроста, а что бы ты добился баланса. > Без контекста эта задача выглядит простой контекст он минимально задал, есть 2 сущности, у них есть общие поля, и что бы эти общие поля убрать он захотел наследоваться. VO в этом ключе позволяет решить ему ту же задачу но намного более адекватно и "обобщения" тут на самом деле меньше, как и вариантов дальнейшего развития событий. > Simplicity is the most intensely intellectual of the XP values и что может быть проще чем VO?)

> про KISS рассказываю кисс не про то что бы "сделать тупо", а про то что бы "тупо пользоваться" > и не против обобщения тут по сути нет обобщения... хотя как, есть наверное немного... но это не такое жесткое обобщение как скажем наследование. А так - преждевременное обобщение это очень нехорошо, тут я с тобой согласен > Вообще, хороший код в пределе не содержит повторений. большая часть принципов конфликтуют между собой не спроста, а что бы ты добился баланса. > Без контекста эта задача выглядит простой контекст он минимально задал, есть 2 сущности, у них есть общие поля, и что бы эти общие поля убрать он захотел наследоваться. VO в этом ключе позволяет решить ему ту же задачу но намного более адекватно и "обобщения" тут на самом деле меньше, как и вариантов дальнейшего развития событий. > Simplicity is the most intensely intellectual of the XP values и что может быть проще чем VO?)

Скалярчик ?

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

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

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

я к тому что не надо путать "просто" и "легко"

Можешь не скидывать этот видос, я его тоже смотрел

хз о каком ты видосе

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

https://www.infoq.com/presentations/Simple-Made-Easy

а, этот... у Алана Кея есть похожее, и много у кого еще

но смысл в икажении таких вещей как KISS и подмена понятий (та же приведенная тобой цитата Кента она как бы несколько к другим вещам относится)

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

У меня подход немного другой. Если он не знает, предложить сделать так, как он знает и посоветовать возможные опции для дальнейшей эволюции кода. Возможных опций вы написали сполна, пожтому оставалось сказать: "Сделай как знаешь, но максимально просто"

но смысл в икажении таких вещей как KISS и подмена понятий (та же приведенная тобой цитата Кента она как бы несколько к другим вещам относится)

Это вообще проблема любого человеческого общения. Нужно что-то, что сможет передавать суть лучше, чем письмо и речь

Это вообще проблема любого человеческого общения. Нужно что-то, что сможет передавать суть лучше, чем письмо и речь

в этом конкретном примере - нет

У меня подход немного другой. Если он не знает, предложить сделать так, как он знает и посоветовать возможные опции для дальнейшей эволюции кода. Возможных опций вы написали сполна, пожтому оставалось сказать: "Сделай как знаешь, но максимально просто"

то что ты предложил по сути у него и так было, нет?)

то что ты предложил по сути у него и так было, нет?)

Было метание между наследованием и отсутствием наследования. А что конкретно было в коде я не знаю

Помню, скидывали тут видео про мужика, который на джаве без switch уже 8 лет пишет. Там у него в докладе много формальной логики и понять без подготовки сложно. Кто ещё пишет на ООП языках без switch 5+ лет скиньте более доступные примеры.

без switch/case? или я сильно мелко беру?

без switch/case? или я сильно мелко беру?

Ну да, без них.

а в чем проблема без них?) это ведь просто сахар в том же питоне их нет - пиши себе через if/else и не парься

ведь свитч это просто частный случай серии if'ов с оператором == и фиксированным левым операндом

там, конечно, ещё break есть, но его можно заменить флагом и if без else, если нужны "провалы" или использовать if/else if, если считать, что break есть везде

а в чем проблема без них?) это ведь просто сахар в том же питоне их нет - пиши себе через if/else и не парься

он свитчи видать полиморфизмом заменил)

Наверное я некорректно выразился. Под switch подразумевается и if/else Кто смотрел видео может подсказать там имелись ввиду только switch в фабриках или вообще везде?

он свитчи видать полиморфизмом заменил)

Да, скорее про это. Где почитать?

Да, скорее про это. Где почитать?

половина паттернов GoF про это

честно - хз что именно читать... про полиморфизм в целом?

на википедии в целоп неплохо вопрос покрыт

или ты про того чувака который SOLID через логику Хоара раскрывал?

у него там были такие фразочки как "пишу без свитчей"

или ты про того чувака который SOLID через логику Хоара раскрывал?

Да.

https://www.youtube.com/watch?v=CmCEdVrZQAE

вот этот чел короч

название стрёмное какое-то..вангую прям чушь внутри. Сергей, стоит смотреть?)

Да не, нормальное

Можно смотреть

Да, просто сложно было понимать без подготовки. Что в итоге он предлагает или просто вывел принципы?

tnx

гляну, спасибо

название стрёмное какое-то..вангую прям чушь внутри. Сергей, стоит смотреть?)

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

Да, просто сложно было понимать без подготовки. Что в итоге он предлагает или просто вывел принципы?

он типа их "доказывает"....

ну мол, я чет не уловил что бы они от этого стали более формальными, он по сути больше open/close как по мне доказать пытался

ну название желтезной попахивает) но гляну, раз такое дело

Вопрос практический. Так размер JS(TS) приложений постоянно растёт, то там тоже возникают проблемы написания легко поддерживаемых приложений за счёт использования хороших подходов к написанию кода. Так вот, есть ли смысл тянуть правильные ООП-плюшки в JS(TS), учитывая особенности реализации ООП в JS?

Вопрос практический. Так размер JS(TS) приложений постоянно растёт, то там тоже возникают проблемы написания легко поддерживаемых приложений за счёт использования хороших подходов к написанию кода. Так вот, есть ли смысл тянуть правильные ООП-плюшки в JS(TS), учитывая особенности реализации ООП в JS?

а что там за особенности такие?)

никаких особенностей

другое - возможно. Но принципам на это плевать

Ну, this "не такой как все."

Ну, this "не такой как все."

привязанный к контексту... то есть такой же)

можешь на python посмотреть

как по мне там намного более "не такой"

но это субъективно

и не мешает студентам в MIT на примере python изучать ООП

> возникают проблемы написания легко поддерживаемых приложений за счёт использования хороших подходов к написанию кода. то есть проблемы возникают из-за хороших практик?

> возникают проблемы написания легко поддерживаемых приложений за счёт использования хороших подходов к написанию кода. то есть проблемы возникают из-за хороших практик?

Неправильно выразился. ООП придуман, чтобы писать и поддерживать приложения было легче. Я вот думаю, стоит ли это все из ООП мира пытаться воспроизводить в JS(TS). Или все жеэсеры так и пишут?

Неправильно выразился. ООП придуман, чтобы писать и поддерживать приложения было легче. Я вот думаю, стоит ли это все из ООП мира пытаться воспроизводить в JS(TS). Или все жеэсеры так и пишут?

Ну, там без getter/setter и static и так далее.

смотря что и на чем ты пишешь

Ну, там без getter/setter и static и так далее.

Без switch.

возможно стоит смотреть в сторону ФП?

там то как раз без свитчей)

смотря что и на чем ты пишешь

Например, большие приложения на ноде или игры.

возможно стоит смотреть в сторону ФП?

Так один ФП ведь мир не спасет.

Так один ФП ведь мир не спасет.

ФП и модель экторов например