Первоначально опубликовано в моем блоге
Далее следует мой ответ на Дело Против ООП сильно преувеличено , Мэтью Макдональд. Я поддерживаю автора в его точке зрения.
Лично мне потребовалось более десяти лет программирования, чтобы подняться и спуститься по лестнице опыта разработчика:
- Просто заставьте это работать и изучите некоторые принципы на этом пути
- Заставьте это работать, но следуйте принципам любой ценой
- Не волнуйтесь, если это не сработает, слепо следуйте принципам, несмотря ни на что.
- Наказывайте других, которые не следуют принципам
- Почему принципы все время встают у меня на пути? Разве я не должен был создать что-то, что работает?
- Научитесь экономно использовать принципы. Прагматично сосредоточьтесь на создании чего-то, что вместо этого работает.
- Просто сделай так, чтобы это сработало.
Происхождение проблемы
К чему я клоню с этим? Как и все принципы, идея объектно-ориентированного программирования (ООП) возникла как способ указать программистам, как решить конкретную проблему , а не как единственный способ решения всех проблем . Тот факт, что разработчики иногда обжигаются, используя его, имеет мало общего с ООП, как и с упорным стремлением человеческого мозга сделать проблемы проще, чем они есть на самом деле. О том, чтобы заставить их поместиться в универсальную обувную коробку.
Во время зарождения ООП кодовые базы начали увеличиваться в размерах и усложняться. Концепция, которую мы сегодня называем Стандартной библиотекой или SDK technology XYZ, еще не существовала. Для того чтобы они могли быть разработаны без сотен дублирований, возникла необходимость в способах инкапсуляции общей логики и данных. Именно так родились классы (инкапсуляция). Классы позволяли нескольким независимым экземплярам (объектам) взаимодействовать друг с другом, разделяя общую функциональность через своих предков (наследование). Чтобы еще больше упростить повторное использование кода, one предоставил способы безопасной работы с объектами, не зная явно о реализации, лежащей в основе их поведения (полиморфизм).
ООП быстро захватила мир программирования штурмом и позволила создать многие основополагающие технологии, на которые мы полагаемся сегодня. Это был ключевой момент, который заставил некоторых поверить, что он может стать решением для все проблемы программирования.
Приложения
Как отмечает автор статьи, в ООП нет ничего плохого, когда оно используется надлежащим образом для создания правильных вещей. Видите ли, одна вещь, которой вас редко научит какой-либо курс или практика программирования, заключается в том, что разработка библиотек требует иного подхода к программированию, чем разработка приложений для конечных пользователей . Библиотекам нужны глубокие иерархии и византийские уровни инкапсуляции, чтобы гарантировать, что основная функциональность не меняется, а используется повторно как можно больше раз. Библиотеки имеют, возможно, неопределенное число потребителей, и после их создания могут быть расширены только путем добавления функциональности, которой раньше не существовало, или путем изменения логики, скрытой за слоями абстракции. Нарушение абстракции требует изменения всех возможных потребителей библиотеки.
Приложения, с другой стороны, постоянно меняются. Это их самое нормальное поведение. Проблемы, которые приложения пытаются решить, постоянно меняются; на фундаментальном уровне ничто во Вселенной никогда не остается неизменным. Почему же тогда практика программирования учит нас обращаться с приложениями так, как если бы они были библиотеками? Это фундаментальный грех – пытаться применить принцип повторного использования и изоляции компонентов к проблеме, которая изменится к тому времени, когда будет разработано решение для нее. Я не говорю, что излагать абстракции и придерживаться принципов – это плохо. Это действительно помогает при выявлении определенных частей приложения, которые выдержали испытание временем. До тех пор применение принципов в отношении динамически меняющейся проблемы похоже на попытку поймать солнечный свет в зеркале, не двигая зеркало ни на дюйм, ожидая, пока на него упадет солнечный свет.
Как заключает Макдональд, в последнее время наблюдается распространение многопарадигмальных языков программирования. Те, которые содержат подмножество ООП без принудительного его использования, но позволяют программисту прибегать к другим методам, например, Функциональному программированию (FP), когда оно лучше соответствует поставленной задаче. Знание того, когда следует придерживаться определенного принципа, но прагматично отбрасывать его там, где он неприменим, – вот что отличает опытных разработчиков от остальных.
Оригинал: “https://dev.to/preslavrachev/my-reply-to-the-case-against-oop-is-wildly-overstated-4od9”