История изменений
Исправление system-root, (текущая версия) :
Данные важнее, чем код
По моему опыту, самая серьёзная проблема ООП заключается в том, что оно мотивирует игнорировать архитектуру модели данных и применять бестолковый паттерн сохранения всего в объекты
Почему в голове автора нельзя одновременно НЕ_игнорировать архитектуру модели данных и при этом хранить всё в объектах без потери производительности при кодировании и не создавая бестолковых вещей?
Мотивирование к сложности
При проектировании архитектуры данных в явном виде результатом обычно является минимальный необходимый набор структур данных, обслуживающих цель нашего ПО.
Если мыслить в категориях абстрактных классов и объектов, то грандиозность и сложность абстракций сверху ничем не ограничивается
Головой она ограничивается, временем и ресурсами.
Это никак не мешает мне создать абстракцию для сущностей предметной области которые объединяют общие свойства. Например, у всех моих сущностей есть ID и UUID, почему я не могу сделать абстракцию и наследование? Это автоматом создаст FizzBuzz Enterprise Edition или чёрную дыру или вызовет сатану? Нет.
Повсюду графы
ООП-проекты обычно выглядят не как качественно спроектированные хранилища данных, а как огромные спагетти-графы объектов, указывающих друг на друга, и методы, получающие огромные списки аргументов.
Я использую ORM для простоты работы с хранилищем и никогда не передаю в методы никакие аргументы кроме классов объектов над которыми нужно выполнить работу. То, что иногда вложенность может быть огромной - вполне решаемо, как минимум в Java и не вызывает проблем.
Задачи поперечных срезов
Вообще не понимаю о чём говорит автор, в моём манямирке class Monster вообще не знает никаких особых методов взаимодействия с другими классами. Для этого у меня есть сервисы.
Шизофреническая инкапсуляция объектов
Можно использовать такую метафору: я нацепляю на левый карман висячий замок, чтобы правая рука не могла ничего из него взять.
Если он один в проекте - это реально звучит как правда. Только в твой левый карман пытается залезть ещё с десяток пограммистов анальщиков с желанием закрыть таск не разобравшись в сайдэффектах.
На одинаковые данные можно смотреть по-разному
Если данные программы, например, хранятся в табличном, ориентированном на обработку данных виде, то можно создать два или более модулей, каждый из которых работает с той же структурой данных, но различным образом. Если данные разбиты на объекты с методами, то это больше невозможно.
Создай ещё один сервис или метод в существующем сервисе с отличной обработкой тех же данных. В чём проблема?
Низкая производительность
Ой всё. Пока никто не подтвердил, что производительность твоего ПО низкая - её достаточно.
Исходная версия system-root, :
Данные важнее, чем код
По моему опыту, самая серьёзная проблема ООП заключается в том, что оно мотивирует игнорировать архитектуру модели данных и применять бестолковый паттерн сохранения всего в объекты
Почему в голове автора нельзя одновременно НЕ_игнорировать архитектуру модели данных и при этом хранить всё в объектах без потери производительности при кодировании и не создавая бестолковых вещей?
Мотивирование к сложности
При проектировании архитектуры данных в явном виде результатом обычно является минимальный необходимый набор структур данных, обслуживающих цель нашего ПО.
Если мыслить в категориях абстрактных классов и объектов, то грандиозность и сложность абстракций сверху ничем не ограничивается
Головой она ограничивается, временем и ресурсами.
Это никак не мешает мне создать абстракцию для сущностей предметной области которые объеденяют общие свойства. Например, у всех моих сущностей есть ID и UUID, почему я не могу сделать обстракцию и наследование? Это автоматом создаст FizzBuzz Enterprise Edition или чёрную дыру или вызовет сатану? Нет.
Повсюду графы
ООП-проекты обычно выглядят не как качественно спроектированные хранилища данных, а как огромные спагетти-графы объектов, указывающих друг на друга, и методы, получающие огромные списки аргументов.
Я использую ORM для простоты работы с хранилищем и никогда не передаю в методы никакие аргументы кроме классов объектов над которыми нужно выполнить работу. То, что иногда вложенность может быть огромной - вполне решаемо, как минимум в Java и не вызывает проблем.
Задачи поперечных срезов
Вообще не понимаю о чём говорит автор, в моём манямирке class Monster вообще не знает никаких особых методов взаимодействия с другими классами. Для этого у меня есть сервисы.
Шизофреническая инкапсуляция объектов
Можно использовать такую метафору: я нацепляю на левый карман висячий замок, чтобы правая рука не могла ничего из него взять.
Если он один в проекте - это реально звучит как правда. Только в твой левый карман пытается залезть ещё с десяток пограммистов анальщиков с желанием закрыть таск не разобравшись в сайдэффектах.
На одинаковые данные можно смотреть по-разному
Если данные программы, например, хранятся в табличном, ориентированном на обработку данных виде, то можно создать два или более модулей, каждый из которых работает с той же структурой данных, но различным образом. Если данные разбиты на объекты с методами, то это больше невозможно.
Создай ещё один сервис или метод в существующем сервисе с отличной обработкой тех же данных. В чём проблема?
Низкая производительность
Ой всё. Пока никто не подтвердил, что производительность твоего ПО низкая - её достаточно.