Pull to refresh
218
0.1
Алексей @PsyHaSTe

Зигохистоморфирующий

Send message

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


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

Ну давайте пример: вам нужно по неочень тривиальной логике (тем не менее она описана бизнесом в какой-нибудь жире) отправлять сообщения пользователю. Типа если не заходил 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 взаимодействие это другая ответственность, значит в эту иерархию её пихать нельзя...


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

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

А вы сами хороший разработчик, верно? Можете спроектировать схему как хранить данные для товарища выше: пяток служебных полей по 32 байта каждая и картинка на 10мб. Как будут хранить это добро в одной таблице разработчики, которые умеют проектировать схему?

А вот когда методов уже несколько, а кейсов с десяток, то полиморфизм будет проще.

Так а с чего вы взяли что полиморфизма там нет? Не забывайте что у полиморфизма есть разные измерения — set of objects vs set of features. Поэтому например существует паттерн "визитор", который часто используется в местах иерархией которая редко меняется, но зато функционал часто разный. А визитор это просто switch in disguise по большому счету.


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


Поэтому тут нет никакого противопоставления.

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

Ну заберёт его государство через 10 лет за долги, и чёрт с ним

Я не согласен с такой постановкой вопроса. Терять всю жизнь конечно хуже, чем потерять 5-10 лет, тем не менее и последнее это едва ли "черт с ним".

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

Ну вот ООП в стиле с фабриками декораторов — это то что у меня прочно ассоциируется с джавой, и думаю я не один такой. Прошу прощения если задел.


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

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


Никто никуда не плевал и презрительно не кивал, не надо искать того чего нет.

Спорный вопрос. Для меня большим откровением было что вместо


// print current game state in stdout
void foo(game: Game) {}

можно написать


void printCurrentGameState(game: Game) {}

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

Information

Rating
3,262-nd
Registered
Activity