Перекрывает, но при этом поведение может слегка меняться. Причем оно бывает существенно даже между 4.5.1 и 4.5.2, был уже нехороший случай конкретно с этими версиями.
Если первое, то можно и сразу тест на логику писать. если прошел — все работает, все подгружено.
Если второе, то в каком классе лежит такой тест и один ли он там?
А если третье, то это тесты самого фреймвека и они должны лежать в проекте с ним и скорее всего они там и так есть.
Но почему? Где аргументация? Почему пучок процедур должен быть лучше, чем один/два лаконичных типа? И если так, то почему тогда синглтоны выставлены как нечто плохое. Ведь пучок процедур — это по сути тоже самое, только еще и неймспейс захламляется.
Ужасов я видел тоже много, но это не значит, что нужно брать пример, или что ОПП плохое.
По поводу "абстрактности" File, то конкретно ООП никаких здесь ограничений не накладывает. И если уж на то пошло, то может быть FileDescriptor и File отдельно. Более того, так это и должно быть, если есть отличимые разные ответственности.
По поводу пользовательских/непользовательских пространств имен тоже не важно. Ну вот допустим библиотека поставляет File c ограниченными возможностями. Так кто мешает создать обертку над ним, но не в виде менеджера, а в виде "MyFile" (мысль думаю ясна) и в системе использовать уже новый тип? Так мы еще и дополнительно поможем себе, если потом поменяем/добавим в поддержку операционную систему.
А как раз в этом контексте вспомнить это вполне уместно. Такие вещи как статическая типизация и контракты кода помогают снизить кол-во необходимых проверок в тестах.
Почему-то вспомнилась эта статья Сергея — Контракты vs Юнит тесты. Там интересные размышления на эту тему.
Эм, так все правильно. Сначала пишем тест на ответ — провал. Пишем простую реализацию. И с пониманием того, что реализация не идеальна, а если придерживаться науки (я не ярый сторонник), то она вообще наиболее простая (т.е. вполне возможно, что просто возврат результата), начнут появляться новые тесты, проверяющие дополнительные св-ва системы.
По личным ощущениям тесты ради тестов куда чаще появляются как раз при TLD, из-за стремления к хорошему покрытию. При TDD такое стремление не будет так явно выражено, а по науке так его и вообще не должно быть (само по себе все хорошо покроется).
Ростов очень компактный, накладывает сложности. Но ситуация с пробками абсолютно типичная, на уровне других миллионников. И уж если сравнивать с Москвой, то в Ростове пробки крайне редко.
Про транспорт соглашусь. Но опять же, в Ростове пару штук ГАЗелей и лишь несколько ПАЗиков старого типа. Так далеко не везде.
Хз, я сюда вообще из другого города переехал (не хотелось в МосквуПитер). Договорился/прособеседовался без проблем даже не находясь в Ростове. Просто приехал и вышел на работу и не жалею.
Интерфейсы дают только полиморфизм. Все. Они ничего не гарантируют, кроме информации, что член существует. Причем, возможно, он просто бросает NotSupportedException, потому что разарботчик интерфейса плохо умеет ISP. Даже юнит тест никак не исправит эту ситуацию. Помочь может только система типов, что в данном конкретном случае слишком мало, и контракты кода, чего во многих языках просто нет, пока.
Предлагаю мыслить все же шире, во многих языках программирования вовсе нет приватного наследования, так что это как раз-таки очень частый случай. Возможно как раз это помешало вам правильно понять автора сразу.
Но и все-таки, даже останавливаясь на плюсах, если бы это был такой уж редкий кейс, не было бы private, хватило бы ptotected и код ревью.
Перекрывает, но при этом поведение может слегка меняться. Причем оно бывает существенно даже между 4.5.1 и 4.5.2, был уже нехороший случай конкретно с этими версиями.
Приложу обсуждение на GitHub: Champion "Nullable reference types"
Только для начальной проверки или тест отсается?
Если первое, то можно и сразу тест на логику писать. если прошел — все работает, все подгружено.
Если второе, то в каком классе лежит такой тест и один ли он там?
А если третье, то это тесты самого фреймвека и они должны лежать в проекте с ним и скорее всего они там и так есть.
Но почему? Где аргументация? Почему пучок процедур должен быть лучше, чем один/два лаконичных типа? И если так, то почему тогда синглтоны выставлены как нечто плохое. Ведь пучок процедур — это по сути тоже самое, только еще и неймспейс захламляется.
Ужасов я видел тоже много, но это не значит, что нужно брать пример, или что ОПП плохое.
По поводу "абстрактности" File, то конкретно ООП никаких здесь ограничений не накладывает. И если уж на то пошло, то может быть FileDescriptor и File отдельно. Более того, так это и должно быть, если есть отличимые разные ответственности.
По поводу пользовательских/непользовательских пространств имен тоже не важно. Ну вот допустим библиотека поставляет File c ограниченными возможностями. Так кто мешает создать обертку над ним, но не в виде менеджера, а в виде "MyFile" (мысль думаю ясна) и в системе использовать уже новый тип? Так мы еще и дополнительно поможем себе, если потом поменяем/добавим в поддержку операционную систему.
Так ведь это должны быть методы класса File (ну или Directory), а не другого объекта. Какие еще синглтоны здесь?
А вот тут снова вопрос про то, что называть хорошим кодом. Мне, например, нравится ответ, про тот, который хорошо тестируется.
А промежуток времени? Быть может качество пришло с полученным опытом?
А как раз в этом контексте вспомнить это вполне уместно. Такие вещи как статическая типизация и контракты кода помогают снизить кол-во необходимых проверок в тестах.
Почему-то вспомнилась эта статья Сергея — Контракты vs Юнит тесты. Там интересные размышления на эту тему.
Эм, так все правильно. Сначала пишем тест на ответ — провал. Пишем простую реализацию. И с пониманием того, что реализация не идеальна, а если придерживаться науки (я не ярый сторонник), то она вообще наиболее простая (т.е. вполне возможно, что просто возврат результата), начнут появляться новые тесты, проверяющие дополнительные св-ва системы.
По личным ощущениям
тесты ради тестовкуда чаще появляются как раз при TLD, из-за стремления к хорошему покрытию. При TDD такое стремление не будет так явно выражено, а по науке так его и вообще не должно быть (само по себе все хорошо покроется).Ну я это регулярно делаю и там и там последние 3 года. Что я должен был заметить?
Средняя же
https://ru.wikipedia.org/wiki/%D0%A0%D0%BE%D1%81%D1%82%D0%BE%D0%B2-%D0%BD%D0%B0-%D0%94%D0%BE%D0%BD%D1%83#.D0.9A.D0.BB.D0.B8.D0.BC.D0.B0.D1.82
Ростов очень компактный, накладывает сложности. Но ситуация с пробками абсолютно типичная, на уровне других миллионников. И уж если сравнивать с Москвой, то в Ростове пробки крайне редко.
Про транспорт соглашусь. Но опять же, в Ростове пару штук ГАЗелей и лишь несколько ПАЗиков старого типа. Так далеко не везде.
По вашему те же uTeam здесь публикуются, чтобы потом "по знакомству" нанимать?
Хз, я сюда вообще из другого города переехал (не хотелось в МосквуПитер). Договорился/прособеседовался без проблем даже не находясь в Ростове. Просто приехал и вышел на работу и не жалею.
А одеваться не надо? В пабы ходить не надо? На море ездить не надо? Ну и т.д.
Насколько я понял, имеется в виду не зп, а сумма, достаточная для нормальной жизни.
Интерфейсы дают только полиморфизм. Все. Они ничего не гарантируют, кроме информации, что член существует. Причем, возможно, он просто бросает
NotSupportedException, потому что разарботчик интерфейса плохо умеетISP. Даже юнит тест никак не исправит эту ситуацию. Помочь может только система типов, что в данном конкретном случае слишком мало, и контракты кода, чего во многих языках просто нет, пока.Предлагаю мыслить все же шире, во многих языках программирования вовсе нет приватного наследования, так что это как раз-таки очень частый случай. Возможно как раз это помешало вам правильно понять автора сразу.
Но и все-таки, даже останавливаясь на плюсах, если бы это был такой уж редкий кейс, не было бы
private, хватило быptotectedи код ревью.