Процедурный подход не выдерживает конкуренции с функциональным и объектно-ориентированным, разве что в случаях где важна производительность (я про программы написанные на си).
И вы немного не правы. не «Классы-процедуры», а объекты, которые ни в коем случае не процедуры, т.к. объекты можно динамически связывать, в отличие от процедур.
Вообще то классы, да и вообще ООП было придумано как ещё один способ структурирования кода.
Не совсем. Парадигмы программирования, такие как ФП и ООП придуманы для работы с кодом на более высоком уровне абстракции. А для структурирования придумали современные управляющие конструкции (if,while,for..) и модульность.
Имеет ли смысл делать папку всего с одним вложенным листочком?
Имеет. Объект в ООП, как и функция в ФП, это способ динамического связывания кода.
В том и дело что относится. Принцип у вас нарушен)
Класс Rectangle хранит данные прямоугольника и позволяет вычислить его площадь. А может при рисовании не надо использовать площадь? А может для вычисления площади надо подтянуть ещё одну зависимость (ну вдруг мы считаем площадь прямоугольника в многомерном искривлённом пространстве, для чего нужна отдельная библиотека)?
А делая поля публичными, вы просто увеличиваете зависимость между классами. Даже если вы сделаете геттеры, зависимость смягчится, но сохранится. Должен ли класс, который рисует, зависеть от класса. который вычисляет ненужное ему значение? Или он должен зависеть от более атомарного, лучше даже интерфейса, который олицетворяет собой только прямоугольник и ничего лишнего?
Вопрос на засыпку: x и y, которые логичнее было бы назвать w и h, у вас приватные. Как presenter узнает ширину и высоту прямоугольника, чтобы его нарисовать?
В ходе размышлений о MVC, я пришёл к выводу, что, то MVC что в вебе, можно выделить в отдельную ветвь как минимум по способу работы с событиями. Если в графических приложениях у нас происходит множество событий, и на них должны реагировать множество представлений, то в серверном MVC есть одно событие — http запрос. Второго события, на которое могут реагировать представления просто нет. т.к. как такового объекта представления, который живёт в течение нескольких событий не существует.
Да я и сам уже несколько недель втайне от своего основного ЯП, по вечерам встречаюсь с clojure. И как раз поэтому могу сказать что нельзя просто так взять и сразу написать что-то адекватное на cjojure, так же, как это можно было бы сделать с более привычными языками.
А вы уверены что написание тестов на clojure будет быстрее чем на родном для разработчика языке? Если для перехода с php на java или js надо привыкнуть к синтаксису и учесть нюансы, то для того чтобы свободно писать на clojure, необходимо хорошенько так сдвинуть мозг.
Однако не отрицаю, что clojure'вский repl положенный на разные предметные области даёт очень резкий вау-эффект, и экономит кучу времени.
Думаю много проблем в области ООП растут из того, что «умные делают а глупые учат». 99% всех объяснений ооп содержат в себе те самые 3 столпа, когда на самом деле их не три. Это лишь попытка систематизировать свойства ООП. И эта попытка стала очень популярной и отсюда куча однотипных и неверных примеров наследования. Да, вначале это кажется чем-то божественным, но потом, оказывается что надо отринуть привычное и делать композицию. Это кажется противоестественным потому что везде учат наследовать.
«Аня едет в трамвае с работы и читает новости…»
А рядом сидит сурового вида парень в толстовке с капюшоном, который ворует чужие сессии через раздачу заражённого jquery с подогнанным хешем.
И вы немного не правы. не «Классы-процедуры», а объекты, которые ни в коем случае не процедуры, т.к. объекты можно динамически связывать, в отличие от процедур.
Не совсем. Парадигмы программирования, такие как ФП и ООП придуманы для работы с кодом на более высоком уровне абстракции. А для структурирования придумали современные управляющие конструкции (if,while,for..) и модульность.
Имеет. Объект в ООП, как и функция в ФП, это способ динамического связывания кода.
Класс Rectangle хранит данные прямоугольника и позволяет вычислить его площадь. А может при рисовании не надо использовать площадь? А может для вычисления площади надо подтянуть ещё одну зависимость (ну вдруг мы считаем площадь прямоугольника в многомерном искривлённом пространстве, для чего нужна отдельная библиотека)?
А делая поля публичными, вы просто увеличиваете зависимость между классами. Даже если вы сделаете геттеры, зависимость смягчится, но сохранится. Должен ли класс, который рисует, зависеть от класса. который вычисляет ненужное ему значение? Или он должен зависеть от более атомарного, лучше даже интерфейса, который олицетворяет собой только прямоугольник и ничего лишнего?
Одного только этого достаточно, чтобы сказать, что польза от данного текста скорее отрицательна.
Корпоративные ИС создаются жить долго, а изменяться часто.
Ну или у вас много свободного времени.
Однако не отрицаю, что clojure'вский repl положенный на разные предметные области даёт очень резкий вау-эффект, и экономит кучу времени.
А рядом сидит сурового вида парень в толстовке с капюшоном, который ворует чужие сессии через раздачу заражённого jquery с подогнанным хешем.