Правильно ли я понимаю, что вы отказываетесь отвечать на вопрос: «Существует ли по вашему мнению процентный налог, при введении которого отечественный производитель получит преимущество, но импортный производитель не окажется вне игры?»?
другого пути как побороть это, кроме как перестать лениться (хотя бы на определенные отрезки времени), нет
Человек не контролирует себя на 100%. Он стремится к удовольствию и пытается избежать боли. При помощи разума можно потерпеть небольшую боль сейчас, чтобы избежать большей боли в будущем или получить большее удовольствие в будущем. Для того, чтобы действовать подчиняясь культурно-социальной программе (например, построить дом\вырастить сына\посадить дерево), а не человеческой природе, есть два наиболее простых способа: 1)победить человеческую природу 2)подстроить обстоятельства так, чтобы потребности человеческой природы не противоречили социальным убеждениям.
Вариант 1. Победа над человеческой природой. Идём в спецназ, тренируем самоконтроль до тех пор, пока не сможем не давать телу отбирать контроль и отдёргивать руку от обжигающего огня. Можно демонизировать свою природу и стать одержимым идеей добить успеха в соответствии с культурно-социальной программой, но к счастью это не приведёт. Можно также уйти в медитацию на несколько лет.
Вариант 2. Делаем так, чтобы испытывать позитивные эмоции при исполнении социальной программы, т.е. при увеличении власти и накоплении материальных благ. Устраиваемся на работу, которая нравится. Награждаем себя за свои успехи. Впадаем в эйфорию при получении новой медальки или атрибута престижа.
Ну или ещё как-нибудь, тут простор для воображения большой.
Хотя, имхо, тут особой разницы нет, чьей марионеткой быть: желания за верёвочки дергают или убеждения. Хотя если за ниточки дёргают «правильные» убеждения, направленные на исполнение своего долга и увеличении счастья всего общества в целом, то это всё же немного лучше. Хорошо делать свои обязанности — пример такого «хорошего» убеждения. Хотя если это идёт вразрез с человеческой природой, а «договориться» с ней не получается, то это скорее всего приведёт к страданиям. Тут можно или пытаться исполнять свой долг и страдать, или не пытаться исполнять свой долг и страдать. А можно пойти другим путём. Постепенно «договариваться» со своей человеческой природой. Или в меньшей степени быть марионеткой. Или перестать быть марионеткой. Ну или ещё что-нибудь. Каждый сам пытается решать, для чего он живёт. Выигрывает он или проигрывает в той или иной ситуации.
Позиция автора понятна. Пытаемся качественно исполнять свои обязанности, но при этом не проявляем насилие по отношению к себе. Очень гармоничная позиция. Но она не приводит к власти и силе. Не пытаться стремиться к власти и силе — тоже означает подавлять свою человеческую природу. Надолго ли вас хватит? Что произойдёт, когда человечность возьмёт своё? Не лучше ли вам поискать ещё более гармоничную позицию? Или вы всё же сможете уйти от жажды власти и почестей? Следует ли размышлять над этими вопросами?
Существует ли по вашему мнению процентный налог, при введении которого отечественный производитель получит преимущество, но импортный производитель не окажется вне игры?
Принесёт ли пользу — другой вопрос. Давайте сначала определимся, повышение налогов на импортные авто и компьютеры уберёт ли конкуренцию среди отечественного и импортного производителя в России.
Не утруждайтесь. Допустим, что при повышении на 2000 (эту цифру изначально предложили вы) все импортные авто окажутся неконкурентоспособными (это спорный вопрос, но допустим, что так). Существует ли по вашему мнению процентный налог, при введении которого отечественный производитель получит преимущество, но импортный производитель не окажется вне игры?
Помимо двух перечисленных вами импортных авто, есть и другие модели автомобилей. Их по-вашему тоже не будут покупать, предпочитая отечественные автомобили?
Проще говоря, все, что он видит перед собой — что вот эта картинка вообще ничего ему не прибавит… Но врожденная скромность и воспитанность далеко не всем заказчикам позволяет набраться смелости и выгнать пинками из кабинета незадачливых дизайнеров-проектировщиков… Не его вина, что кроме игры со шрифтами и цветом он не может ничего придумать
Заказчик должен предоставить ТЗ и\или конечного пользователя будущей системы, владеющего предметной областью, который ответит на все вопросы. Если заказчик просит сделать программу, которая делает хорошо, ему через 10 минут предоставляют кнопку на всё окно с надписью «сделать хорошо», выводящей смайлик при нажатии, и заказчик вместо того чтобы объяснить почему программа не делает хорошо, просит изменить шрифт кнопки, то это в первую очередь проблема заказчика, и лишь во вторую — исполнителя, который по глупости связался с таким заказчиком. Телепатию ещё не изобрели. Нужно озвучивать цели, которые должна реализовывать программа. Если цели озвучены, можно оценить, насколько они выполнены.
А для этого нужно максимально глубоко погрузится в тему, нужно выполнить правило «10 тысяч часов», затраченных не на рисование кнопок на экране, а на постижение тонкостей и скрытой логики всех процессов в компании заказчика.
Люди столько не живут, чтобы для создания интерфейса одной программы поработать по 10 тысяч часов на каждой должности предприятия, для которого пишется софт. Собираются несколько конечных пользователей с каждой должности и рассказывают о своих проблемах и перечисляют, что им для счастья не хватает.
Но вот однажды один мудрый человек (а мне в жизни очень везет на действительно умных людей) объяснил мне все и мигом открыл глаза на этот мир
Дайте угадаю, этот «мудрый» человек был заказчиком? Советую не брать больше у него заказов.
Т.е. вы согласны, что повышение налогов на импортные авто и компьютеры не уберёт конкуренцию в России, и отказываетесь от вашего главного аргумента, почему нельзя вводить налог?
У меня не было правила о том, как много дополнительных дней я себе даю в качестве буфера. Так что я никогда не знала на 100%, насколько отдален реальный дедлайн от того, который я себе установила, поэтому я не могла позволить себе пропустить дату, записанную в моем менеджере задач.
Пробовал так делать, когда учился в школе — не помогло. Зная, что часы показывают неправильное время, и время в запасе у меня ещё есть, я неспеша собирался в школу, расеянно ища свою шапку, даже когда время на часах поджимало, вместо того, чтобы бросить её поиски, обмотать голову первым что под руку подвернётся и бежать со всех ног. В итоге опаздывал чаще, чем с показывающими верное время часами. Теряется сама суть дедлайна — ощущения надвигающегося провала с громом, молниями, и неизвестными неприятностями. Ведь срок истинного дедлайна при таком подходе неизвестен, а чтобы поверить что неприятности придут раньше истинного дедлайна, нужна или склонность к мазохизму, чтобы эти неприятности себе устроить, или какая-нибудь форма психического расстройства, чтобы в эти несуществующие неприятности поверить.
он поставил перед собой цель закончить роман в течение трех месяцев… Ивлин не завершил всю работу над проектом вовремя – он несколько раз просил об отсрочке дедлайна.
Это уже из разряда вредных советов. Инвесторы хотят услышать объективное время, т.к. они не только планируют свою деятельности исходя из ваших оценок, но и могут предпринимать реальные действия исходя из них: например, начинают договариваться о рекламе или заказывают исследование рынка. Оценки следует давать как можно более точными, или не давать их вообще. А для собственной мотивации можно поискать и другие средства.
Т.е. вы согласны, что повышение налогов на импортные авто и компьютеры уберёт конкуренцию лишь в каком то условном государстве у условных организаций, но не в России, и отказываетесь от вашего главного аргумента, почему нельзя вводить налог?
Ок, давайте ещё раз объясню. Вот смотрите, допустим ФПшная абстракция моноида: op(x, op(y, z)) = op(op(x, y), z), светофора: ТипДвиженияПешехода(СигнализироватьСветофором(МашинамНужноДвигаться)) = Стоять(), годового отчёта: СостояниеНалоговойПослеПросмотраОтчёта(ПостроитьОтчёт(Дата)) = Довольны(). Если мы доказываем, что в результате работы светофора пешеход останавливается, то мы доказываем абстракцию; если мы доказываем, что светофор периодически меняет цвет, то мы доказываем реализацию. Светофор может не менять цвет, а например пищать, но это всё равно светофор.
Приходит заказчик\аналитик, и предоставляет свои хотелки и бизнес-сценарии. Например, если у пользователя нету прав, то при попытке доступа на такую то страницу, переходить на страницу-заглушку. Вот как вы докажете, что производится переход на страницу-заглушку? Максимум, вы можете доказать, что производится попытка перевода браузера пользователя на какую то фиксированную страницу. И после того как страница-заглушка будет изменена на другую, ваше «математическое доказательство» будет неверно. Т.е. доказывается то реализация, а не абстракция.
Автор заявил, что «абстракция которую нельзя доказать — не абстракция», на что я возражаю, что вы можете доказать только низкоуровневые абстракции, которые в большинстве приложений даже не используются, потому как основные функции: доступ к данным, отображение данных, — делаются декларативно и при помощи сторонних библиотек.
Если меняются законы, должны меняться и абстракции.
Внесения изменений в программу — дело обыденное, особенно на этапе сопровождения. Например, приходит пользователь и говорит: «добавьте мне в отчёте снизу такого-то столбца сумму всех ячеек этого столбца». Абстракция отчёта от этого ни капли не изменилась, но вот её реализация изменилась. Отчёт — это предоставление определенной информации пользователю в удобной и понятной форме. При этом мы не можем даже проверить, что пользователь получил эту информацию — а вдруг он в монитор не смотрит? При этом эту информацию ему можно передавать разными способами — хоть на бипере морзянкой напискивать. Соответственно, во всём, что касается пользователя — мы не можем доказать, что добиваемся поставленной цели. Мы можем доказать, что делаем действия, которые, по нашему мнению, уместны. Доказать реализацию, но не абстракцию.
И, неожиданно, в сухом остатке в большинстве программ не остаётся больше ничего существенного и сложного, что нуждалось бы в доказательстве. Большинство программ работает следующим образом: пользователь 1)регистрирует изменения состояния чего-нибудь в системе и 2)запрашивает сводную информацию по состояниям. Так работают всевозможные erp-системы, онлайн-магазины, социальные сети, поисковики (в случае поисковиков изменения в системе регистрирует не пользователь, а паук crawler), онлайн-кинотетры, энциклопедии, сайты поиска работ, всевозможные корпоративные приложения и пр. При этом чаще всего используются декларативные средства для отображения и получения информации. Декларативно указываем базе данных, какие данные хочется получить. Декларативно указываем гриду, из какого поля брать информацию и в столбце с каким именем её отображать. Декларативно указываем в HTML, как следует отрисовать страничку. Соответственно, логики непосредственной отрисовки и получения данных в приложении нет. Конечно, можно доказать, что такая-то функция формирует такие-то данные в таком-то формате, но ведь можно формировать данные в другом формате и отдавать его другой библиотеке отображения. Т.е. опять таки доказывается и тестируется реализация, но не абстракция. Теоретически можно конечно изловчиться и доказать, что в результате работы функции, операционки и драйвера будет отрисовано нечто, что удовлетворяет неким формальным требованиям (которые практически невозможно сформулировать — дизайн графического элемента может сильно варьироваться), из чего мы сделаем вывод, что это конкретный графический элемент. Но ради чего такие сложности, если требования по отображению задаются декларативно?!
За вычетом этого, остаются функции операционного уровня. Наподобие, если нажали на такую то кнопку — отрисовать такую то формочку. Но их логика, как правило, настолько тривиальна, что не нуждается в доказательстве.
Но это, конечно, лишь только описание ситуации на практике. Если бы программирование было сосредоточено не вокруг удовлетворения нужд рядовых пользователей, а вокруг невероятно зубодробительных математических расчётов, то ситуация, вероятно, была бы несколько иной.
Насчет АвтоВАЗа —… в него государство влило кучу денег, а результата (и денег) — нет.
А теперь заявляете, что производство у нас так хорошо налажено, что если поднять налог на ввоз импортных авто на 2000, то у нашего автопрома не останется конкурентов.
В общем, как обычно противоречите самому себе. Хотите одновременно и подчеркнуть, что «ваши ничего не могут» и «у вас всё плохо», и убедить, что с этим ничего не нужно не делать, т.к. всё и так хорошо. Максимум что можно делать — предпринимать те же действия, что уже были предприняты, но не принесли результата. И ещё заявляете, что наценка на импортные товары, а именно таможенные пошлины — это аморально. Наверное, призываете отменить таможенную пошлину, что вызовет в РФ кризис.
Я не верю, что ваш ум направлен на поиск способа помочь экономике России, и что вы собираетесь жить в России. И, кстати, русофобия — это расизм.
Вы дали ссылку на реализацию шаблона «Фабрика», а не «Абстракная фабрика».
Описание того, какой тип инстанцировать, передаётся в WindsorContainer. Фабрика наследуется от интерфейса, её реализация динамически кодогенерится контейнером. Итого, есть интерфейс фабрики. Внутри фабрики есть логика, определяющая, какой конкретный тип будем инстанцировать. Реализация фабрики и её логика может различаться в разных частях программы (например, если использовать другой контейнер). Имхо, это абстрактная фабрика.
Эдвард как раз указывает на разницу к подходе к абстракциям — ФП идёт в сторону строгих определений абстракций с возможностью формальных доказательств (пусть и проводимых людьми). В типичном ООП-подходе к абстракции формальных определений нет и не может быть
Есть такая штука, как контракт. При помощи него можно описать пред-условия функции, инварианты и постусловия. Контракты не доказываются, но могут проверяться в момент исполнения. Описать факты, не относящиеся непосредственно к единичному вызову функции, через контракт не получится. Т.е. op(x, op(y, z)) = op(op(x, y), z) или another(x, op(y, z)) = op(another(x, y), z) описать через контракт не получится, но это можно сделать в summary функции, пометив тегом code. То есть средства для формального описания инвариантов в ООП есть, причём довольно давно.
То что ФП предоставляет средства для доказательства инвариантов — несомненно, здорово. Но не у всех абстракций есть эти самые инварианты. Я уже приводил пример с абстракцией «демонстрировать радость». На моём опыте у подавляющего большинства абстракций, реализуемых программистами, нет инвариантов, а те редкие инварианты, которые всё же встречаются, обычно легко вписываются в контракт. Инварианты в основном часто встречаются в структурах данных и базовых мат. операциях, которые давно реализованы на уровне языка и поведение которых всем давно известно.
Я бы не стал утверждать, что «абстракция которую нельзя доказать — не абстракция» теоретически, а уж практически — тем более.
Нельзя недооценивать возможности ФП. Чего только стоит масштабируемость ФП программ, доказательство инвариантов тоже вносит свой вклад в копилку прогресса. Но, имхо, как то уж ФП энтузиасты это слишком превозносят, вплоть до того дошли, что вне ФП абстракций нет.
Если кто-то утверждает, что его тип является моноидом, и это нельзя доказать, то этому можно поверить. Да, программист может ошибиться, но абстракция от этого не перестаёт быть абстракцией.
Какие законы можно выделить для «шаблона» «Абстрактная фабрика»?
Закон единственности ответственности: алгоритм выбора того, какой именно класс использовать, не относится ни к одному из создаваемых фабрикой классов.
Можно ли формально доказать, что ваш тип удовлетворяет этим законам?
Доказать, не нарушает ли закон единственности ответственности, без ИИ или человека, наверное, не получится. Но при помощи статического анализатора можно найти потенциальные проблемные участки. Можно ли доказать, что класс является фабрикой? Да, можно. Информация об абстракции содержится в интерфейсе. Если класс реализует интерфейс IFactory, но не реализует объявленную в нём функцию TSomeClass Create(), то возникнет ошибка компиляции. Может ли функция вернуть null, также можно формально проверить.
Можно ли написать полезную библиотеку, работающую с абстрактными фабриками?
Да, можно. Например, в Castle.WindsorContainer есть TypedFactory. Или можно написать библиотеку, которая будет вызывать TSomeClass Create() в нужный момент времени.
Проверять ошибки программиста это круто, но при чём тут абстракция?
Можно менять реализацию абстракции, не нарушая самой абстракции. А вот провозглашая доказательство абстракции частью абстракцию, имхо, мы отказываемся от абстрактного мышления. Например, есть абстракция «веселиться». Реализация: веселиться = бегать, прыгать, плясать. Есть доказательство, что при веселье происходят бег, прыжки и пляски. Но вот приходит аналитик, и заявляет, что теперь веселиться = смеяться, хлопать в ладоши. Абстракция не изменилась, но её доказательство и реализация изменились. Вывод: доказательство не часть абстракции. Смысл абстракции как раз в том и заключается, что некая общая идея отделяется от её конкретной реализации в частном случае.
Согласен, идея доказательства контракта функции на основе её исходного кода выглядит привлекательной и перспективной, но непонятно, причём тут паттерны проектирования. Паттерны борются со сложностью программы, проверки корректности программы борются с ошибками программиста.
Вариант 1. Победа над человеческой природой. Идём в спецназ, тренируем самоконтроль до тех пор, пока не сможем не давать телу отбирать контроль и отдёргивать руку от обжигающего огня. Можно демонизировать свою природу и стать одержимым идеей добить успеха в соответствии с культурно-социальной программой, но к счастью это не приведёт. Можно также уйти в медитацию на несколько лет.
Вариант 2. Делаем так, чтобы испытывать позитивные эмоции при исполнении социальной программы, т.е. при увеличении власти и накоплении материальных благ. Устраиваемся на работу, которая нравится. Награждаем себя за свои успехи. Впадаем в эйфорию при получении новой медальки или атрибута престижа.
Ну или ещё как-нибудь, тут простор для воображения большой.
Хотя, имхо, тут особой разницы нет, чьей марионеткой быть: желания за верёвочки дергают или убеждения. Хотя если за ниточки дёргают «правильные» убеждения, направленные на исполнение своего долга и увеличении счастья всего общества в целом, то это всё же немного лучше. Хорошо делать свои обязанности — пример такого «хорошего» убеждения. Хотя если это идёт вразрез с человеческой природой, а «договориться» с ней не получается, то это скорее всего приведёт к страданиям. Тут можно или пытаться исполнять свой долг и страдать, или не пытаться исполнять свой долг и страдать. А можно пойти другим путём. Постепенно «договариваться» со своей человеческой природой. Или в меньшей степени быть марионеткой. Или перестать быть марионеткой. Ну или ещё что-нибудь. Каждый сам пытается решать, для чего он живёт. Выигрывает он или проигрывает в той или иной ситуации.
Позиция автора понятна. Пытаемся качественно исполнять свои обязанности, но при этом не проявляем насилие по отношению к себе. Очень гармоничная позиция. Но она не приводит к власти и силе. Не пытаться стремиться к власти и силе — тоже означает подавлять свою человеческую природу. Надолго ли вас хватит? Что произойдёт, когда человечность возьмёт своё? Не лучше ли вам поискать ещё более гармоничную позицию? Или вы всё же сможете уйти от жажды власти и почестей? Следует ли размышлять над этими вопросами?
Люди столько не живут, чтобы для создания интерфейса одной программы поработать по 10 тысяч часов на каждой должности предприятия, для которого пишется софт. Собираются несколько конечных пользователей с каждой должности и рассказывают о своих проблемах и перечисляют, что им для счастья не хватает.
Дайте угадаю, этот «мудрый» человек был заказчиком? Советую не брать больше у него заказов.
Это уже из разряда вредных советов. Инвесторы хотят услышать объективное время, т.к. они не только планируют свою деятельности исходя из ваших оценок, но и могут предпринимать реальные действия исходя из них: например, начинают договариваться о рекламе или заказывают исследование рынка. Оценки следует давать как можно более точными, или не давать их вообще. А для собственной мотивации можно поискать и другие средства.
Т.е. вы согласны, что повышение налогов на импортные авто и компьютеры уберёт конкуренцию лишь в каком то условном государстве у условных организаций, но не в России, и отказываетесь от вашего главного аргумента, почему нельзя вводить налог?
Ок, давайте ещё раз объясню. Вот смотрите, допустим ФПшная абстракция моноида: op(x, op(y, z)) = op(op(x, y), z), светофора: ТипДвиженияПешехода(СигнализироватьСветофором(МашинамНужноДвигаться)) = Стоять(), годового отчёта: СостояниеНалоговойПослеПросмотраОтчёта(ПостроитьОтчёт(Дата)) = Довольны(). Если мы доказываем, что в результате работы светофора пешеход останавливается, то мы доказываем абстракцию; если мы доказываем, что светофор периодически меняет цвет, то мы доказываем реализацию. Светофор может не менять цвет, а например пищать, но это всё равно светофор.
Приходит заказчик\аналитик, и предоставляет свои хотелки и бизнес-сценарии. Например, если у пользователя нету прав, то при попытке доступа на такую то страницу, переходить на страницу-заглушку. Вот как вы докажете, что производится переход на страницу-заглушку? Максимум, вы можете доказать, что производится попытка перевода браузера пользователя на какую то фиксированную страницу. И после того как страница-заглушка будет изменена на другую, ваше «математическое доказательство» будет неверно. Т.е. доказывается то реализация, а не абстракция.
Автор заявил, что «абстракция которую нельзя доказать — не абстракция», на что я возражаю, что вы можете доказать только низкоуровневые абстракции, которые в большинстве приложений даже не используются, потому как основные функции: доступ к данным, отображение данных, — делаются декларативно и при помощи сторонних библиотек.
И, неожиданно, в сухом остатке в большинстве программ не остаётся больше ничего существенного и сложного, что нуждалось бы в доказательстве. Большинство программ работает следующим образом: пользователь 1)регистрирует изменения состояния чего-нибудь в системе и 2)запрашивает сводную информацию по состояниям. Так работают всевозможные erp-системы, онлайн-магазины, социальные сети, поисковики (в случае поисковиков изменения в системе регистрирует не пользователь, а паук crawler), онлайн-кинотетры, энциклопедии, сайты поиска работ, всевозможные корпоративные приложения и пр. При этом чаще всего используются декларативные средства для отображения и получения информации. Декларативно указываем базе данных, какие данные хочется получить. Декларативно указываем гриду, из какого поля брать информацию и в столбце с каким именем её отображать. Декларативно указываем в HTML, как следует отрисовать страничку. Соответственно, логики непосредственной отрисовки и получения данных в приложении нет. Конечно, можно доказать, что такая-то функция формирует такие-то данные в таком-то формате, но ведь можно формировать данные в другом формате и отдавать его другой библиотеке отображения. Т.е. опять таки доказывается и тестируется реализация, но не абстракция. Теоретически можно конечно изловчиться и доказать, что в результате работы функции, операционки и драйвера будет отрисовано нечто, что удовлетворяет неким формальным требованиям (которые практически невозможно сформулировать — дизайн графического элемента может сильно варьироваться), из чего мы сделаем вывод, что это конкретный графический элемент. Но ради чего такие сложности, если требования по отображению задаются декларативно?!
За вычетом этого, остаются функции операционного уровня. Наподобие, если нажали на такую то кнопку — отрисовать такую то формочку. Но их логика, как правило, настолько тривиальна, что не нуждается в доказательстве.
Но это, конечно, лишь только описание ситуации на практике. Если бы программирование было сосредоточено не вокруг удовлетворения нужд рядовых пользователей, а вокруг невероятно зубодробительных математических расчётов, то ситуация, вероятно, была бы несколько иной.
А теперь заявляете, что производство у нас так хорошо налажено, что если поднять налог на ввоз импортных авто на 2000, то у нашего автопрома не останется конкурентов.
В общем, как обычно противоречите самому себе. Хотите одновременно и подчеркнуть, что «ваши ничего не могут» и «у вас всё плохо», и убедить, что с этим ничего не нужно не делать, т.к. всё и так хорошо. Максимум что можно делать — предпринимать те же действия, что уже были предприняты, но не принесли результата. И ещё заявляете, что наценка на импортные товары, а именно таможенные пошлины — это аморально. Наверное, призываете отменить таможенную пошлину, что вызовет в РФ кризис.
Я не верю, что ваш ум направлен на поиск способа помочь экономике России, и что вы собираетесь жить в России. И, кстати, русофобия — это расизм.
Есть такая штука, как контракт. При помощи него можно описать пред-условия функции, инварианты и постусловия. Контракты не доказываются, но могут проверяться в момент исполнения. Описать факты, не относящиеся непосредственно к единичному вызову функции, через контракт не получится. Т.е. op(x, op(y, z)) = op(op(x, y), z) или another(x, op(y, z)) = op(another(x, y), z) описать через контракт не получится, но это можно сделать в summary функции, пометив тегом code. То есть средства для формального описания инвариантов в ООП есть, причём довольно давно.
То что ФП предоставляет средства для доказательства инвариантов — несомненно, здорово. Но не у всех абстракций есть эти самые инварианты. Я уже приводил пример с абстракцией «демонстрировать радость». На моём опыте у подавляющего большинства абстракций, реализуемых программистами, нет инвариантов, а те редкие инварианты, которые всё же встречаются, обычно легко вписываются в контракт. Инварианты в основном часто встречаются в структурах данных и базовых мат. операциях, которые давно реализованы на уровне языка и поведение которых всем давно известно.
Я бы не стал утверждать, что «абстракция которую нельзя доказать — не абстракция» теоретически, а уж практически — тем более.
Нельзя недооценивать возможности ФП. Чего только стоит масштабируемость ФП программ, доказательство инвариантов тоже вносит свой вклад в копилку прогресса. Но, имхо, как то уж ФП энтузиасты это слишком превозносят, вплоть до того дошли, что вне ФП абстракций нет.
Если кто-то утверждает, что его тип является моноидом, и это нельзя доказать, то этому можно поверить. Да, программист может ошибиться, но абстракция от этого не перестаёт быть абстракцией.
Закон единственности ответственности: алгоритм выбора того, какой именно класс использовать, не относится ни к одному из создаваемых фабрикой классов.
Доказать, не нарушает ли закон единственности ответственности, без ИИ или человека, наверное, не получится. Но при помощи статического анализатора можно найти потенциальные проблемные участки. Можно ли доказать, что класс является фабрикой? Да, можно. Информация об абстракции содержится в интерфейсе. Если класс реализует интерфейс IFactory, но не реализует объявленную в нём функцию TSomeClass Create(), то возникнет ошибка компиляции. Может ли функция вернуть null, также можно формально проверить.
Да, можно. Например, в Castle.WindsorContainer есть TypedFactory. Или можно написать библиотеку, которая будет вызывать TSomeClass Create() в нужный момент времени.
Проверять ошибки программиста это круто, но при чём тут абстракция?
Согласен, идея доказательства контракта функции на основе её исходного кода выглядит привлекательной и перспективной, но непонятно, причём тут паттерны проектирования. Паттерны борются со сложностью программы, проверки корректности программы борются с ошибками программиста.