Обновить
26
ApeCoder@ApeCoder

Разработчик

6
Подписчики
Отправить сообщение
Но вас же никто не заставляет использовать несовместимые. Какие хотите — такие и берете.

А сторонние библиотеки не будут фрагментированы по используемым системам типов? Или это не страшно?

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

На хаскелле порог вхождения и задачи отличаются от таковых для жабы, ИМХО

Система типов — костыль для языков, в которых нет мощной макросистемы.

Наверное вы имели ввиду "встроенные системы типов"?


Типы по ссылке выше написаны именно на макросах. Более того — там есть макробиблиотека, которая позволяет легко писать свои системы

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

Почему расширенный наследованный класс не может требовать от вызывающего кода больше, чем базовый класс? Или вообще другого кода?

Потому, что тогда код который работает с базовым классом не сможет работать с расширенным.


Я не могу вызвать метод гав у животного, потому что его (метода) нет. У животного этот метод не определен. И это разумно. Но он есть у собаки.

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

Надо либо не обобщать либо обобщать корректно.
Квадрат это прямоугольник.
Но не "Изменяемый квадрат это изменяемый прямоугольник".
Квадраты и прямоугольки могут быть вообще константами.


В-общем, в википедии ж все написано про то, что с этим делать :)

Итого


  • IFoo это на самом деле "какая-то фигня для тестирования" а не "Foo вообще"
  • Foo это "Foo вообще" (но пользователь использует IFoo в качестве "Foo вообще")
  • Тест подсовывает неименованную частичную реализацию IFoo

Лично я предпочитаю так не делать. По поводу моков была продуктивная дискуссия c lair

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

Получается что даже тот код, который использует интерфейс, а не реализует, связан с тем, что это именно интерфейс. Т.е. убрав эту I можно было бы уменьшить compile time dependency

Тесты это другой код.


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

Не явлюятся ли моки другой реализацией?

А как в интерфейс добавить реализацию?

Имхо это костыль:


  • Классы, префиксы энамы и прочее — это типы и находятся в одном адресном пространстве. Их не надо разделять.
  • Получается что даже тот код, который использует интерфейс, а не реализует, связан с тем, что это именно интерфейс. Т.е. убрав эту I можно было бы уменьшить compile time dependency
  • Если у нас класс называется так же как интерфейс, это значит, что мы что-то не выразили в имени (IList это список вообще, а List — это конкретная реализация, которая уже не список вообще, но называется как список вообще. До дженериков ее назвали ArrayList — что, имхо, более явно отличает абстрактный список от конкретной реализации)

Для даунстрима Derive a specific test class per implementer выполняет даунстримщик.

Там же написано — каждый наследник может иметь свой конструктор + дополнительно свой набор каких-то еще тестов. Абстрактный тест вызвает абстрактный factory method для создания конкретной реализации.


К тому же какие-то ассерты тоже могут быть абстрактными

Так и для абстрактых классов придется делать то же самое. Или что-то типа Code.Contracts

Некоторые советуют дополнять реализацию абcтрактными тестами

Спасибо. Был еще какой-то compatibility toolkit, который анализировал работу приложения и и настраивал конфиг с какими-то шимами, чтобы оно вообще думало, что под админом но работало с виртуализированными реестрами и файловой системой. Но я не пробовал.

Он КАРМАк. Так что надо опасаться за карму.

Я так делал. Правда я настроил просто:


  • нельзя выполнять оттуда, куда можно писать
  • нельзя писать туда, откуда можно выполнить

НО


  • есть OneDrive который хотел отбновляться в профиле
  • при апгрейде с 8.1 на 10 я в редакторе политик не увидел SRP, а они работали. В реестре пришлось убивать.
  • есть программа Атсрал (для связи с налоговой ИП) которая стоит у одного и пользователей и требует вообще админских прав. (она же, кстати, с собой тащит SQL Server 2005)

Похоже есть какой-то баланс между безопасностью и легкостью обновления и совместимостью. Если включить по умолчанию уровень безопасности чтобы нельзя было скачать и выполнить код, то часть ПО отвалится (помните, сколько было воплей, когда вышла виста? Часть из них была именно из-за этого).


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


Вообще мне было бы интересно почитать статью настоящего админа, про то, как это настроить и админить, и много ли геморроя требуется для поддержки

А на JS/VBA нельзя написать шифровальщик?


Интересно было бы сформулировать правила, чтобы безопасность была бы примерно как на айпеде:


  • Нельзя записывать и менять, то, что можно запустить
  • Нельзя запускать, то, что пользователь может изменить.

Т.е. все скрипты и прочее должны или вообще не запускаться или не иметь возможности быть измененным пользователем.


Едиственное, это требует поддержки от всего ПО. Так как мы не знаем Shutuka.XYZ — это скрипт или файл с данными.

Чтобы запустить powershell со скриптом шифровальщиком, разве не надо сначала запустить что-то еще, что запустит это скрипт? А это что-то еще не может причинить сравнимый вред, например просто путем стирания данных?

Это все зависит от языка и задачи. На ассемблере без goto вообще никак. В функциональных языках "дополнительные функции" создаются вообще на лету.

Информация

В рейтинге
Не участвует
Откуда
Россия
Дата рождения
Зарегистрирован
Активность