ты можешь вообще не дропать колонку, просто потом почистить

сделать тасочку себе

и спокойно потом удалить

но идея с тем что код надо на 2 ситуации очевидная спс

ога

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

1. добавляем колонку в базу и пишем код который будет писать в обе колонки 2. деплоим и ждем 3. пишем миграцию которая перенесет старые данные 4. деплоим 5. когда все ок и данные в новой колонке всегда актуальны - дропаем колонку

в 5 пункте

наоборот в начале выкатываем app

потом бд получается

да

и тут начинаются приколюхи потому как те средства для миграций не позволяют это дело разделять

ога логично

у нас предлагают адовый пиздец я против

я вообще против бесшовных деплоев не уперлось оно нам)

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

и тут начинаются приколюхи потому как те средства для миграций не позволяют это дело разделять

да знаю

1. - до деплоя, 2 - после

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

да типо этого

или миграции тэг какой

меня больше послеовательность операций мучала

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

но в итоге просто делаем руками пока

ибо ситуация достаточно редкая что бы инвестировать в нее кучу времени

ну да)

у нас подобным образом

но ваш подход лучше чем то что у нас предлагают

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

тип того

получается универсально и без бажно

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

у нас есть кого этим озадачить

отдельная личность)

бородатая)

спс, пойду спать теперь точно

Господа

Если у нас есть некий класс с кучей полей и билдер к нему - у них обоих есть одинаковые поля. Почему бы не сделать им общего предка в виде POD-класса?

Доброго времени суток. Приссоеденюсь к вашему чату. О себе - изучаю усиленно ООП. Мож помогу тут советом или кто то мне поможет.

Если у нас есть некий класс с кучей полей и билдер к нему - у них обоих есть одинаковые поля. Почему бы не сделать им общего предка в виде POD-класса?

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

мне кажется это идея не очень

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

Задайся вопросом будут ли являтся и билдер и тот некий класс тем предком т.е. можно сказать что некий класс = предок и билдер = предок . Если да, то юзай наследование.

Но если есть способ избежать наследования - избегай

Задайся вопросом будут ли являтся и билдер и тот некий класс тем предком т.е. можно сказать что некий класс = предок и билдер = предок . Если да, то юзай наследование.

запутанная формулировка

Если у нас есть некий класс с кучей полей и билдер к нему - у них обоих есть одинаковые поля. Почему бы не сделать им общего предка в виде POD-класса?

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

оно визуально похоже но это не тоже самое

Но если есть способ избежать наследования - избегай

именно

Задайся вопросом будут ли являтся и билдер и тот некий класс тем предком т.е. можно сказать что некий класс = предок и билдер = предок . Если да, то юзай наследование.

именно так, и мне кажется это не их общий предок

Наследование применяют когда производный класс семантически является базовым. Если этого равенства нет, то как говорит Сергей Протко - дублирования нет.

Наследование применяют когда производный класс семантически является базовым. Если этого равенства нет, то как говорит Сергей Протко - дублирования нет.

несовсем

Наследование применяют когда производный класс семантически является базовым. Если этого равенства нет, то как говорит Сергей Протко - дублирования нет.

что есть "базовым"? ты говоришь про классы или типы/контракты?

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

потому что если все есть в базовом классе нафига наследоваться, юзай его

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

опять же, не расширить а "сузить"

что есть "базовым"? ты говоришь про классы или типы/контракты?

про классы, я так понял об этом была речь? нет?

предоставить более специфичное поведение

про классы, я так понял об этом была речь? нет?

мы вообще про ООП)

ооп не про классы

предоставить более специфичное поведение

да с этим согласен, я просто веду речь к тому что даже в ЯП слово extend (расширить) используется в наследование

ооп не про классы

+++

))) ок, ок...но чувак про классы спрашивал

))) ок, ок...но чувак про классы спрашивал

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

хотя никакого дублирования там нет

тут тупо чье субьективное мнение лучше)

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

конечно не стоит

далеко не всегда билдеры и то что мы билдим по итогу будет иметь одинаковую структуру

сергей сейчас с пруфами докажет что тоже не стоит и не правильно вы ооп и даст куча материала на изучение

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

Ок, если вопрос что просто поля одинаковые у разных объектов, то тогда это не есть причина юзать наследование впринципе

именно так

но реальность такова что люди не всегда слушают то что считают другие

но реальность такова что люди не всегда слушают то что считают другие

на самом деле потому что не очень понимают

возможно

не все люди еще могут признать что они не правы были например

я не врубился в суть вопроса видать

и начинается игра в отстаивание позиции до последнего

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

главное без protected

запутанная формулировка

Liskov substitution - "можно ли везде вместо предка использовать экземпляр потомка?"

Liskov substitution - "можно ли везде вместо предка использовать экземпляр потомка?"

хороший наброс)

Liskov substitution - "можно ли везде вместо предка использовать экземпляр потомка?"

ну тут то все просто. Ты же на это дело с позиции контрактов смотришь

а контракты интерфейс

кстате да

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

Liskov substitution - "можно ли везде вместо предка использовать экземпляр потомка?"

можете разъяснить вопрос, я туплю

и при наследование @Overwrite метод публичный то мы сразу нарушаем лиски

можете разъяснить вопрос, я туплю

с которого все началось?

"можно ли везде вместо предка использовать экземпляр потомка?"

я просто не понял это вопрос или уже тут ответили на него

"можно ли везде вместо предка использовать экземпляр потомка?"

ну это "принцип подстановки барбары лисков".

"можно ли везде вместо предка использовать экземпляр потомка?"

тут речь о SOLID и об одной из букавок Liskov substitution

упрощенное определение

я в курсе

который просто оффтопом, задали))

Правильный ответ, если что, "зачем вообще в билдере такие же поля как у класса, пускай хранит сам объект класса)"

ок, походу туплю со страшной силой ил

Правильный ответ, если что, "зачем вообще в билдере такие же поля как у класса, пускай хранит сам объект класса)"

имя поля может одинаковое, а значение разное

имя поля может одинаковое, а значение разное

все проще - поля не часть контракта