С объектно-ориентированным программированием я столкнулся в 1993 году, когда перешел с обычного Pascal на Object-версию. Позже я работал с C++, Java, php, JavaScript из которых только в Java было сразу чётко понятно «здесь только объекты и никаких шагов в сторону».
Обычно работа начинается не с долгого изучения теории, а от понимания проблемы до поиска путей для её решения. Поэтому для создания сайтов на стороне сервера использовался php, на стороне клиента определенную функциональность выполнял javascript.
Для других задач, соответственно, — другие языки. То что в javascript «всё — объекты» я понял не сразу. Да, было такое дело.
И до этого меня всегда мучали вопросы типа «как бы использовать один общий код или данные, только расширяя функциональность?», «а что если функция с таким именем уже существует?».
Уже позже, когда я менял работу и приходил на собеседования, мне задавали вопросы про «полиморфизм» и «инкапсуляцию».
Эти термины были сухими и не содержали в себе глубокого практического смысла.
В объектно-ориентированном программировании (ООП) для меня имелся смысл в следующем:
Как только я выяснил, что в php и javascript использовать ООП возможно, то я стал его применять.
Минусов в ООП я вижу толко два: надо хорошо продумывать структуру объектов (уметь проектировать) и ресурсы вычислительных машин более затратны.
Да, еще нужны знания, а на их upgrade почти никогда нет времени. Впрочем, это скорее шутка, чем серьезное препятствие.
Минусы я перечислил на тот случай, чтобы они были. А то ведь без минусов картина не будет объективной.
Плюсов гораздо больше:
Это были четыре главных, которые в итоге: сокращают время разработки и поддержки проекта, разгружают мозг от «непрофильного шума» и отодвигают границы, когда проект превращается в «кашу».
В последнее время на Хабре я стал чаще встречать статьи написанные в стиле «процедурное vs ООП».
Наверное это реальная проблема (ООП — за/против) для людей, раз такие темы возникают. Но лично я, при возможности, выбираю ООП.
Мне так удобнее и легче работать. Только важно понимать, что ООП это, всего лишь, инструмент.
А для использования инструмента всегда должна быть квалификация определенного уровня.
Кстати, Hanspeter Moessenboeck в 1993 году уже рассмотрел плюсы и минусы в своей статье «Costs and Benefits of OOP».
Обычно работа начинается не с долгого изучения теории, а от понимания проблемы до поиска путей для её решения. Поэтому для создания сайтов на стороне сервера использовался php, на стороне клиента определенную функциональность выполнял javascript.
Для других задач, соответственно, — другие языки. То что в javascript «всё — объекты» я понял не сразу. Да, было такое дело.
И до этого меня всегда мучали вопросы типа «как бы использовать один общий код или данные, только расширяя функциональность?», «а что если функция с таким именем уже существует?».
Уже позже, когда я менял работу и приходил на собеседования, мне задавали вопросы про «полиморфизм» и «инкапсуляцию».
Эти термины были сухими и не содержали в себе глубокого практического смысла.
В объектно-ориентированном программировании (ООП) для меня имелся смысл в следующем:
- Жизненное пространство объектов с четкими границами и своей внутренней суверенной демократией
- Возможность расширять уже существующие наработки (сделанные раньше), не меняя работающей логики и не ломая проект
Как только я выяснил, что в php и javascript использовать ООП возможно, то я стал его применять.
Минусов в ООП я вижу толко два: надо хорошо продумывать структуру объектов (уметь проектировать) и ресурсы вычислительных машин более затратны.
Да, еще нужны знания, а на их upgrade почти никогда нет времени. Впрочем, это скорее шутка, чем серьезное препятствие.
Минусы я перечислил на тот случай, чтобы они были. А то ведь без минусов картина не будет объективной.
Плюсов гораздо больше:
- чёткая карта проекта (да она просто есть! — «города»-объекты внутри «страны»-проекта) — снижение сложности понимания «как это работает»
- возможность многократного использования уже готовых «кубиков»
- более быстрое и ясное понимание своего(спустя годы) и чужого (ООП) кода, его сопровождение.
- Защита внутренних алгоритмов и данных от непроизвольного изменения — «черные ящики»
Это были четыре главных, которые в итоге: сокращают время разработки и поддержки проекта, разгружают мозг от «непрофильного шума» и отодвигают границы, когда проект превращается в «кашу».
В последнее время на Хабре я стал чаще встречать статьи написанные в стиле «процедурное vs ООП».
Наверное это реальная проблема (ООП — за/против) для людей, раз такие темы возникают. Но лично я, при возможности, выбираю ООП.
Мне так удобнее и легче работать. Только важно понимать, что ООП это, всего лишь, инструмент.
А для использования инструмента всегда должна быть квалификация определенного уровня.
Кстати, Hanspeter Moessenboeck в 1993 году уже рассмотрел плюсы и минусы в своей статье «Costs and Benefits of OOP».
