То что вы говорите не зависит от парадигмы программирование. Если проект пишется кое как, не думая о развитии, и реюзе, какую парадигму авторы бы не использовали, хоть объекто-аспектно-функциональное программирование, получится говнокод.
И наоборот, если понимать требования, куда проект будет двигаться дальше (присутствует стратегия развития), то даже на асме можно добиться реюза, но все таки лучше если это будет современный ОО язык.
>«ужасные? extends и? super из Java» заменены на ковариантные и контравариантные типовые параметры. Они дают всю необходимую гибкость и при этом сохраняют все прелести статической типизации.
? extends и? super это фактически урезанные existential types, они по своей мощности сильнее in и out параметров.
>Не более чем последний абзац в пункте «Нарушение инкапсуляции», а именно выделение объектов с данными с простым интерфейсом и нескольких объектов с поведением, обрабатывающие эти данные. Вместо перегруженного интерфейса у объектов с данными «на все случаи жизни».
Так а зачем перегружать интерфейс? Неужели нельзя писать в нормальном стиле?
>1) ФП. Учитывая приводимую в пример scala ФП и ООП не исключают друг друга.
ООП и ФП не очень уживаются друг с другом. Например отваливается полный тайп инференс, и систему типов приходится делать намного сложнее. Вспомните ужасные? extends и? super из Java. Вобщем-то из вещей на которые часто жалуятся в Скале, самое распространенное это сложная и замедляющая компилятор система типов.
>3) Поведенческие классы и классы с данными. Да, не канонический подход, но удобный и давно используемый в ООП.
Что вы подразумеваете под поведенческими классами и классами с данными? По моему, в ООП уже давно принято все классы разделать на 2 категории, value objects, immutable объекты и entities, которые mutable.
Ну вообще, методами написания совта до C++, софт получался сильно дороже и намного менее надежным, чем сейчас. Вспомните windows, word, и прочую хренотень.
Вообще evernote содержит в себе evernote clipper, который доступен в виде плагина для всех нормальных браузеров, и который умеет просто брать и сохранять веб страницу. www.evernote.com/about/trunk/items/evernote-clippers
Статика это не плохо, плохо это глобальный стейт. Extension методы стейта не имеют, так что вполне кошерны.
Для инициализации и деинициализации тестов во всех известных мне тестовых фрейворках есть средства, и сложного в них ничего нет.
И наоборот, если понимать требования, куда проект будет двигаться дальше (присутствует стратегия развития), то даже на асме можно добиться реюза, но все таки лучше если это будет современный ОО язык.
? extends и? super это фактически урезанные existential types, они по своей мощности сильнее in и out параметров.
>Не более чем последний абзац в пункте «Нарушение инкапсуляции», а именно выделение объектов с данными с простым интерфейсом и нескольких объектов с поведением, обрабатывающие эти данные. Вместо перегруженного интерфейса у объектов с данными «на все случаи жизни».
Так а зачем перегружать интерфейс? Неужели нельзя писать в нормальном стиле?
ООП и ФП не очень уживаются друг с другом. Например отваливается полный тайп инференс, и систему типов приходится делать намного сложнее. Вспомните ужасные? extends и? super из Java. Вобщем-то из вещей на которые часто жалуятся в Скале, самое распространенное это сложная и замедляющая компилятор система типов.
>3) Поведенческие классы и классы с данными. Да, не канонический подход, но удобный и давно используемый в ООП.
Что вы подразумеваете под поведенческими классами и классами с данными? По моему, в ООП уже давно принято все классы разделать на 2 категории, value objects, immutable объекты и entities, которые mutable.
ООП привело к тому что код стал намного более реюзабельным, чем когда-либо, и производительность программистов заметно выросла.
Говорится что ООП это плохо, при этом как писать без ООП не говориться.