В большинстве нормальных языков есть экзошн проверки которые не позволят "забыть" какой-нибудь из вариантов.
я не спорил ни с кем, просто отметил, что противопоставление "свитчи плохо полиморфизм хорошо" это ложная дихотомия, которую впрочем некоторые очень любят.
Ну давайте пример: вам нужно по неочень тривиальной логике (тем не менее она описана бизнесом в какой-нибудь жире) отправлять сообщения пользователю. Типа если не заходил 3 месяца или только один месяц, но подписан на такие-то определение категории, или ещё что-то и то-то. Ну и какие категории порекомендовать тоже спецификация на пару страниц. Как будете релизить такой функционал?
Для кого стало, а кто амазон только на картинке видел (да, вот такой я динозавр). У других разработчиков другой опыт, и то что вам очевидно для других может быть открытием. Я вот в первый раз про это слышу, но спасибо за информацию)
Я очень сомневаюсь что разработчики движков БД не сталкивались с проблемой хранения блобов в БД и никогда не занимались оптимизацией этого. Поэтому считаю крайне наивными размышления людей о том, что они сейчас сделают связь 1-к-1 чем ускорят программу.
Очевидно это зависит от движка базы. Те которыеы с миллионами часов вложенными в них например будут их иметь, а какой-нибудь SQlite или какая-нибудь очередная революционная рейвендиби может не иметь.
Думаю люди среагировали бы куда мене бурно, если бы эта инфорация была в первом комменте вида "а вы знаели что бд X,Y,Z автоматически это оптимизируют и вам не нужно ничего делать? Вот ссылка на документацию (линк)". Для меня например это была новая информация, спасибо за нее. Впрочем, как я ниже говорил могут быть и другие причины для подобного разделения. В свою очередь считаю что одно из качетв хорошего разработчика — отсутствие категоричности в высказываниях/суждениях.
Ок, а как нам тогда быть если у нас не 1 дополнительное поле, а 3? У нас получается либо 3 нулла, либо они все заполнены — раньше это автоматически энфорсилось правило наличием отдельной таблицы, а в таком подходе как защищаться от запрещенных комбинаций вида "нулл-данные-нулл"? У нас кроме вопроса хранения на диске есть еще вопрос корректности.
Тесты это способ описать формально дефинишн оф дан — если логика чуть нетрививальнее чем 2+2 то тупо проще написать тест и озеленить его чем писать код, а потом поднимать все и глазами смотреть что вышло что хотелось. Хотя встречал товарищей, которые считают что их дело кодес написать, а делает ли он что хотелось пусть специально обученные люди смотрят, не про него честь.
Видели. Вот такой например код из прод кодовой базы:
impl Responder for UpdateResponse {
type Body = BoxBody;
fn respond_to(self, _req: &HttpRequest) -> HttpResponse<Self::Body> {
match self {
UpdateResponse::UpdateSuccess => HttpResponse::Ok().finish(),
UpdateResponse::UpdateIgnored => HttpResponse::Ok().json("Update ignored"),
UpdateResponse::UpdateNeedsFullData => HttpResponse::new(StatusCode::IM_A_TEAPOT),
UpdateResponse::AlreadyUpdating => HttpResponse::new(StatusCode::IM_A_TEAPOT),
}
}
}
Знакомый жава-разраб порывался все тут разбить на иерархию из 4 классов, и спрятать туда логику "а что делать если вот то-то произошло". Вроде бы хотел ещё параллельную иерархию стратегий ведь HTTP взаимодействие это другая ответственность, значит в эту иерархию её пихать нельзя...
Я в целом согласен с вами и статья мягко говоря спорная, но простой код — существует. Причем чем круче разраб по моему опыту тем проще он может написать что-то. Написать сложно просто, написать просто зачастую сложно.
А вы сами хороший разработчик, верно? Можете спроектировать схему как хранить данные для товарища выше: пяток служебных полей по 32 байта каждая и картинка на 10мб. Как будут хранить это добро в одной таблице разработчики, которые умеют проектировать схему?
А вот когда методов уже несколько, а кейсов с десяток, то полиморфизм будет проще.
Так а с чего вы взяли что полиморфизма там нет? Не забывайте что у полиморфизма есть разные измерения — set of objects vs set of features. Поэтому например существует паттерн "визитор", который часто используется в местах иерархией которая редко меняется, но зато функционал часто разный. А визитор это просто switch in disguise по большому счету.
Такое ощущение что чистый код травмирует людей настолько, что они начинают ненавидеть свитч и не понимают, что это и есть тот самый полиморфизм, но по другим ракурсом. Иногда это плохое решение, если нам нужно постоянно добавлять новые обьекты. А иногда — хорошее, если мы постоянно добавляем новые функции.
Я не считаю, что выбора нет. Есть конкретные шаги которые можно сделать, чтобы существенно снизить вероятность риска. Кто хочет "не париться" — пожалуйста, но мне такой вариант кажется очень расточительным
Основная сложность — наличие имущества и невозможность его переписать (даже генеральная доверенность не дает права дарения если прямо не указано кому можно подарить имущество). Любые серьезные ограничения в этом направлении это большая проблема, которую хочется решить превентивно.
Ну вот ООП в стиле с фабриками декораторов — это то что у меня прочно ассоциируется с джавой, и думаю я не один такой. Прошу прощения если задел.
На джаве можно писать так, чтобы получилось быстро. Но он будет признан "неидиоматичным" почти любым джава-корифеем. А правильный кодес по гайдлайнам будет выглядеть как спринг.
Я сказал "ООП как в джава". В противовес скажем "ООП как в раст" или "ООП как в смоллтолк" или "ООП как в джаваскрипт". Чтобы не спорить о терминах я просто очертил круг языков про которые говорю.
Никто никуда не плевал и презрительно не кивал, не надо искать того чего нет.
В большинстве нормальных языков есть экзошн проверки которые не позволят "забыть" какой-нибудь из вариантов.
я не спорил ни с кем, просто отметил, что противопоставление "свитчи плохо полиморфизм хорошо" это ложная дихотомия, которую впрочем некоторые очень любят.
Ну давайте пример: вам нужно по неочень тривиальной логике (тем не менее она описана бизнесом в какой-нибудь жире) отправлять сообщения пользователю. Типа если не заходил 3 месяца или только один месяц, но подписан на такие-то определение категории, или ещё что-то и то-то. Ну и какие категории порекомендовать тоже спецификация на пару страниц. Как будете релизить такой функционал?
Для кого стало, а кто амазон только на картинке видел (да, вот такой я динозавр). У других разработчиков другой опыт, и то что вам очевидно для других может быть открытием. Я вот в первый раз про это слышу, но спасибо за информацию)
Очевидно это зависит от движка базы. Те которыеы с миллионами часов вложенными в них например будут их иметь, а какой-нибудь SQlite или какая-нибудь очередная революционная рейвендиби может не иметь.
Думаю люди среагировали бы куда мене бурно, если бы эта инфорация была в первом комменте вида "а вы знаели что бд X,Y,Z автоматически это оптимизируют и вам не нужно ничего делать? Вот ссылка на документацию (линк)". Для меня например это была новая информация, спасибо за нее. Впрочем, как я ниже говорил могут быть и другие причины для подобного разделения. В свою очередь считаю что одно из качетв хорошего разработчика — отсутствие категоричности в высказываниях/суждениях.
Ок, а как нам тогда быть если у нас не 1 дополнительное поле, а 3? У нас получается либо 3 нулла, либо они все заполнены — раньше это автоматически энфорсилось правило наличием отдельной таблицы, а в таком подходе как защищаться от запрещенных комбинаций вида "нулл-данные-нулл"? У нас кроме вопроса хранения на диске есть еще вопрос корректности.
Кто сказал что будут использоваться какие-то облачные платформы, а не какой-нибудь дигиталоушон с аргосд и простой постгрей?
Тесты это способ описать формально дефинишн оф дан — если логика чуть нетрививальнее чем 2+2 то тупо проще написать тест и озеленить его чем писать код, а потом поднимать все и глазами смотреть что вышло что хотелось. Хотя встречал товарищей, которые считают что их дело кодес написать, а делает ли он что хотелось пусть специально обученные люди смотрят, не про него честь.
Так а зачем вам тесты? Я так понял они только в гуано проектах… Вы же не хотите работать с гуано проектом? Значит и тестов быть не должно
Видели. Вот такой например код из прод кодовой базы:
Знакомый жава-разраб порывался все тут разбить на иерархию из 4 классов, и спрятать туда логику "а что делать если вот то-то произошло". Вроде бы хотел ещё параллельную иерархию стратегий ведь HTTP взаимодействие это другая ответственность, значит в эту иерархию её пихать нельзя...
Я в целом согласен с вами и статья мягко говоря спорная, но простой код — существует. Причем чем круче разраб по моему опыту тем проще он может написать что-то. Написать сложно просто, написать просто зачастую сложно.
Что-то вспомнилось
остается вопрос зачем нам в базе хранить 10 миллионов нуллов
А вы сами хороший разработчик, верно? Можете спроектировать схему как хранить данные для товарища выше: пяток служебных полей по 32 байта каждая и картинка на 10мб. Как будут хранить это добро в одной таблице разработчики, которые умеют проектировать схему?
Так а с чего вы взяли что полиморфизма там нет? Не забывайте что у полиморфизма есть разные измерения — set of objects vs set of features. Поэтому например существует паттерн "визитор", который часто используется в местах иерархией которая редко меняется, но зато функционал часто разный. А визитор это просто switch in disguise по большому счету.
Такое ощущение что чистый код травмирует людей настолько, что они начинают ненавидеть свитч и не понимают, что это и есть тот самый полиморфизм, но по другим ракурсом. Иногда это плохое решение, если нам нужно постоянно добавлять новые обьекты. А иногда — хорошее, если мы постоянно добавляем новые функции.
Поэтому тут нет никакого противопоставления.
Я не считаю, что выбора нет. Есть конкретные шаги которые можно сделать, чтобы существенно снизить вероятность риска. Кто хочет "не париться" — пожалуйста, но мне такой вариант кажется очень расточительным
Я не согласен с такой постановкой вопроса. Терять всю жизнь конечно хуже, чем потерять 5-10 лет, тем не менее и последнее это едва ли "черт с ним".
Основная сложность — наличие имущества и невозможность его переписать (даже генеральная доверенность не дает права дарения если прямо не указано кому можно подарить имущество). Любые серьезные ограничения в этом направлении это большая проблема, которую хочется решить превентивно.
Ну вот ООП в стиле с фабриками декораторов — это то что у меня прочно ассоциируется с джавой, и думаю я не один такой. Прошу прощения если задел.
На джаве можно писать так, чтобы получилось быстро. Но он будет признан "неидиоматичным" почти любым джава-корифеем. А правильный кодес по гайдлайнам будет выглядеть как спринг.
Я сказал "ООП как в джава". В противовес скажем "ООП как в раст" или "ООП как в смоллтолк" или "ООП как в джаваскрипт". Чтобы не спорить о терминах я просто очертил круг языков про которые говорю.
Никто никуда не плевал и презрительно не кивал, не надо искать того чего нет.
Спорный вопрос. Для меня большим откровением было что вместо
можно написать
И такой код будет куда лучше смотреться, особенно по месту использования.