Comments 3
4 из 5-и недостатков ООП на самом деле недостатки наследования. Пишите на ООП без наследования, даже подход такой есть — Composition Over Inheritance: en.wikipedia.org/wiki/Composition_over_inheritance
5-й недостаток ООП это доказательство через аналогию. Доказательством такое утверждение являться не может по определению. Аналогии — оружие демагогов в споре.
5-й недостаток ООП это доказательство через аналогию. Доказательством такое утверждение являться не может по определению. Аналогии — оружие демагогов в споре.
Я, по началу, когда только прочитал про эти недостатки, тоже возмутился. Что за нелепые нападки, подумалось мне. А потом стал вспоминать различные принципы, применяемые в ООП (например, SOLID), и мне пришла в голову мысль, что эти принципы, судя по всему, появились только потому, что было необходимо нивелировать какие-либо неудачные решения. Так что недостатки объективно существуют, как и достоинства.
Так же хотелось бы отметить, что в тексте специально отмечено, что противопоставление ООП и ФП не является целью статьи, и мне эта позиция близка. Каждый инструмент должен использоваться по назначению. Ну а для того, чтобы использовать ФП там, где это лучше всего подходит, следует хотя бы иметь представления об основах, а в основе ФП лежит математика, что меня лично несколько завораживает.
Так же хотелось бы отметить, что в тексте специально отмечено, что противопоставление ООП и ФП не является целью статьи, и мне эта позиция близка. Каждый инструмент должен использоваться по назначению. Ну а для того, чтобы использовать ФП там, где это лучше всего подходит, следует хотя бы иметь представления об основах, а в основе ФП лежит математика, что меня лично несколько завораживает.
Что толку от теории без демонстрации практических результатов?
Программирование – штука неисчерпаемая, каждый может существовать там со своими представлениями о прекрасном.
Как по мне, программирование это, прежде всего, проектирование и моделирование реальности. А потом уже инструменты, код и алгоритмы.
Первична задача, а уже под задачу выбираются язык программирования (один или несколько), соответствующие фреймворки, стили и шаблоны программирования.
Можно говорить о личных предпочтениях. Например, для меня более предпочтителен C++ / WTL плюс соответствующий опенсорс для программирования интерфейса и разработки алгоритмов. А вот для подготовки данных более привлекателен Python, хотя некоторые старые задачи выгодней поддерживать с помощью скриптов движка Visual FoxPro, современная замена которому SQLite.
А все эти рассуждения про функциональное / процедурное программирование, объекты или классы, компоненты или интерфейсы постольку поскольку. Вчера использовал одно, сегодня другое. Они все как бы вторичны по отношению к текущей задаче. Справляются – хорошо, нет – ищем другие варианты.
Как по мне лучше говорить о способах решения конкретной задачи, чем о преимуществах или недостатках конкретных инструментов и методов их использования. Например, в WTL есть мастер по созданию интерфейса приложения. Почему бы не создать некий супер-мастер по генерированию интерфейса приложения по некоторому достаточно сложному проекту? Тут нам пригодится и суперпозиция с композицией и рекурсия с циклами и вообще достаточно нетривиальные иерархические алгоритмы реализации. При этом программирование бизнес-логики или внеинтерфейсной программной логики можно вынести за пределы этого супер-мастера, в виде, допустим, поддержки внешних плагинов.
Тогда даже сложные приложения, например, по компьютерному учету, обработке данных и т.п., можно будет делать достаточно быстро и эффективно.
Программирование – штука неисчерпаемая, каждый может существовать там со своими представлениями о прекрасном.
Как по мне, программирование это, прежде всего, проектирование и моделирование реальности. А потом уже инструменты, код и алгоритмы.
Первична задача, а уже под задачу выбираются язык программирования (один или несколько), соответствующие фреймворки, стили и шаблоны программирования.
Можно говорить о личных предпочтениях. Например, для меня более предпочтителен C++ / WTL плюс соответствующий опенсорс для программирования интерфейса и разработки алгоритмов. А вот для подготовки данных более привлекателен Python, хотя некоторые старые задачи выгодней поддерживать с помощью скриптов движка Visual FoxPro, современная замена которому SQLite.
А все эти рассуждения про функциональное / процедурное программирование, объекты или классы, компоненты или интерфейсы постольку поскольку. Вчера использовал одно, сегодня другое. Они все как бы вторичны по отношению к текущей задаче. Справляются – хорошо, нет – ищем другие варианты.
Как по мне лучше говорить о способах решения конкретной задачи, чем о преимуществах или недостатках конкретных инструментов и методов их использования. Например, в WTL есть мастер по созданию интерфейса приложения. Почему бы не создать некий супер-мастер по генерированию интерфейса приложения по некоторому достаточно сложному проекту? Тут нам пригодится и суперпозиция с композицией и рекурсия с циклами и вообще достаточно нетривиальные иерархические алгоритмы реализации. При этом программирование бизнес-логики или внеинтерфейсной программной логики можно вынести за пределы этого супер-мастера, в виде, допустим, поддержки внешних плагинов.
Тогда даже сложные приложения, например, по компьютерному учету, обработке данных и т.п., можно будет делать достаточно быстро и эффективно.
Sign up to leave a comment.
Сочиняя ПО: Введение