Когда ООП лучше подходит? [закрыто]

Поскольку я начал изучать объектно-ориентированное программирование, я часто читаю статьи / блоги, в которых говорится, что функции лучше, или не все проблемы следует моделировать как объекты. Из ваших личных программных приключений, когда вы думаете, что проблема лучше решается ООП?

29 oop
9.08.2008 08:51:27
16 ОТВЕТОВ
РЕШЕНИЕ

Нет жесткого и быстрого правила. Проблема лучше решается с помощью ООП, когда вы лучше решаете проблемы и мыслите в ОО-менталитете. Объектная ориентация - это еще один инструмент, который появился благодаря попыткам сделать вычисления лучшим инструментом для решения проблем.

Тем не менее, это может обеспечить лучшее повторное использование кода, а также может привести к более аккуратному коду. Но довольно часто эти высоко оцениваемые качества, в сущности, не имеют реальной ценности. Применение ОО-методов к существующему функциональному приложению может вызвать много проблем. Умение заключается в изучении множества различных техник и применении наиболее подходящих для решения проблемы.

ОО часто называют Nirvana-подобным решением для разработки программного обеспечения, однако во многих случаях неуместно применять его к рассматриваемой проблеме. Довольно часто это может привести к чрезмерному проектированию проблемы для достижения идеального решения, когда часто это действительно не нужно.

По сути, ООП - это не объектно-ориентированное программирование, а отображение объектно-ориентированного мышления на языке программирования, способном поддерживать ОО-методы. Методы ОО могут поддерживаться языками, которые по сути не являются ОО, и есть методы, которые вы можете использовать в функциональных языках, чтобы воспользоваться преимуществами.

Например, я занимаюсь разработкой ОО-программного обеспечения уже около 20 лет, поэтому я склонен мыслить в терминах ОО при решении проблем, независимо от языка, на котором я пишу. В настоящее время я реализую полиморфизм с использованием Perl 5.6, который изначально не поддержать это. Я решил сделать это, поскольку это сделает обслуживание и расширение кода простой задачей настройки, а не проблемой разработки.

Не уверен, что это понятно. Есть люди, которые трудны в ОО-суде, и есть люди, которые трудны в Функциональном суде. А потом есть люди, которые попробовали и то, и другое, стараясь извлечь лучшее из каждого. Ни то, ни другое не является идеальным, но оба имеют некоторые очень хорошие черты, которые вы можете использовать независимо от языка.

Если вы пытаетесь изучать ООП, не просто концентрируйтесь на ООП, но попробуйте использовать объектно-ориентированный анализ и общие принципы ООП для всего спектра решения проблемы.

29
6.07.2018 06:19:42
почему Perl 5,6 человек? и я почти уверен, что Perl может сделать полиморфизм, по крайней мере, я думаю, что книга «Объектно-ориентированный Perl» описывает это. ОО Perl действительно мощная, хотя и очень уродливая.
xenoterracide 6.11.2010 13:25:12
Perl 5.6 потому что это была инфраструктура компаний. Чтобы обновить его в то время, потребовалось бы массовое изменение большого количества серверов и всей инфраструктуры поддержки. Все изменилось сейчас, спустя 2 года.
Xetius 6.11.2010 20:31:28

Я думаю, что это лучше всего подходит, когда вы моделируете что-то связанное с состояниями и связанными действиями с этими состояниями. Я думаю, это немного расплывчато, но я не уверен, что здесь есть идеальный ответ.

Особенность ООП заключается в том, что она позволяет инкапсулировать и абстрагировать данные и информацию, что является настоящим благом в построении большой системы. Вы можете сделать то же самое с другими парадигмами, но ООП особенно полезен в этой категории.

Это также зависит от того, какой язык вы используете. Если это язык с богатой поддержкой ООП, вы, вероятно, должны использовать это в своих интересах. Если этого не произойдет, то вам может понадобиться найти другие механизмы, которые помогут разбить проблему на более мелкие, легко тестируемые части.

5
9.08.2008 09:07:27

Я продан ООП.

Каждый раз, когда вы можете определить концепцию для проблемы, она может быть заключена в объект.

Проблема с ООП состоит в том, что некоторые люди злоупотребляли ею и делали свой код еще более трудным для понимания. Если вы внимательно относитесь к тому, что вы помещаете в объекты и что вы помещаете в сервисы (статические классы), вы выиграете от использования объектов.

Просто не помещайте в объект то, что не принадлежит объекту, потому что вам нужно, чтобы ваш объект сделал что-то новое, о чем вы не думали изначально, проведите рефакторинг и найдите лучший способ добавить эту функциональность.

4
9.08.2008 12:34:42

В некоторых местах, где ОО не так хорош, вы имеете дело с «наборами» данных, как в SQL. ОО имеет тенденцию усложнять операции на основе множеств, поскольку на самом деле она не предназначена для оптимального пересечения двух множеств или надмножества двух множеств.

Кроме того, бывают случаи, когда функциональный подход имеет больше смысла, например, этот пример взят из MSDN :

Рассмотрим, например, написание программы для преобразования XML-документа в другую форму данных. Хотя, безусловно, можно было бы написать программу на C #, которая анализировала бы XML-документ и применяла различные операторы if, чтобы определить, какие действия следует предпринять в различных точках документа, возможно, более совершенным подходом является написание преобразования в виде расширяемой таблицы стилей. Программа преобразования языка (XSLT). Неудивительно, что в XSLT есть большая полоса функционализма.

1
9.08.2008 14:11:47

Я считаю, что это помогает думать о данной проблеме с точки зрения «вещей».

Если проблема может рассматриваться как наличие одной или нескольких «вещей», где каждая «вещь» имеет ряд атрибутов или фрагментов информации, которые относятся к ее состоянию, и количество операций, которые могут быть выполнены над ней - тогда ООП это, вероятно, путь!

1
9.08.2008 14:17:22

Я старый таймер, но также давно запрограммировал ООП. Я лично против использования ООП только для того, чтобы его использовать. Я предпочитаю, чтобы у объектов были конкретные причины существования, чтобы они моделировали что-то конкретное и чтобы они имели смысл.

Проблема, с которой я сталкиваюсь со многими новыми разработчиками, заключается в том, что они не имеют представления о ресурсах, которые они потребляют, с кодом, который они создают. При работе с большим объемом данных и доступе к базам данных «идеальная» объектная модель может быть худшей вещью, которую вы можете сделать для производительности и ресурсов.

Мой итог: если это имеет смысл как объект, то запрограммируйте его как объект, если учесть влияние производительности / ресурсов на реализацию вашей объектной модели.

8
19.09.2008 12:10:09

Ключом к изучению объектно-ориентированного программирования является изучение шаблона проектирования. Изучая шаблоны проектирования, вы сможете лучше видеть, когда нужны классы, а когда нет. Как и все, что используется в программировании, использование классов и других возможностей языков ООП зависит от вашего дизайна и требований. Как и алгоритмы Шаблоны проектирования - это концепция более высокого уровня.

Шаблон проектирования играет ту же роль, что и алгоритмы для традиционных языков программирования. Шаблон проектирования расскажет вам, как создавать и комбинировать объекты для выполнения некоторых полезных задач. Как и лучшие алгоритмы, лучшие шаблоны проектирования достаточно универсальны, чтобы их можно было использовать для решения множества общих проблем.

1
19.09.2008 12:21:05
ИМХО большинство людей, использующих ООП, не изучают шаблоны проектирования в течение очень долгого времени после (или никогда) ... может быть, шаблоны проектирования иллюстрируют правильное использование ООП, но определенно не ключ - понимание принципов инкапсуляции, полиморфизма и наследования суть
Gishu 28.03.2009 07:06:25
Для процедурных программ алгоритмы имеют решающее значение, чтобы научиться составлять разнородные операторы и функции для выполнения полезной работы. Шаблоны проектирования выполняют ту же роль для ООП. Алгоритмы обучения и шаблоны проектирования - самая важная вещь для изучения их соответствующих методов программирования.
RS Conley 28.03.2009 19:27:23

На мой взгляд, это больше вопрос о вас как о личности. Некоторые люди думают лучше с функциональной точки зрения, а другие предпочитают классы и объекты. Я бы сказал, что ООП лучше подходит, когда оно соответствует вашей внутренней (субъективной) ментальной модели мира.

1
13.10.2008 16:59:36

Это зависит от проблемы: парадигма ООП полезна при разработке распределенных систем или фреймворков с множеством сущностей, живущих во время действий пользователя (например, веб-приложение).

Но если у вас есть математические проблемы, вы предпочтете функциональный язык (LISP); для систем, критичных к производительности, вы будете использовать ADA или C и т. д.

Язык ООП полезен, потому что он также использует, вероятно, сборщик мусора (автоматическое использование памяти) при запуске программы: вы программируете на C много времени, вы должны отладить и исправить проблему памяти вручную.

0
4.02.2009 15:29:08

Объектно-ориентированный код и процедурный код имеют разные точки расширяемости. Объектно-ориентированные решения упрощают добавление новых классов без изменения существующих функций (см. Принцип Open-Closed), а процедурный код позволяет добавлять функции без изменения существующих структур данных. Довольно часто разные части системы требуют разных подходов в зависимости от ожидаемого изменения.

1
28.04.2009 14:41:25

ООП полезно, когда у вас есть вещи. Розетка, кнопка, файл. Если вы заканчиваете класс в er, это почти всегда функция, которая притворяется классом. TestRunner, скорее всего, должна быть функцией, которая запускает тесты (и, вероятно, называется run tests).

0
29.10.2010 13:46:25

Существует 5 критериев, следует ли отдавать предпочтение объектно-ориентированному, а не объектно-ориентированному, функциональному или процедурному коду. Помните, что все эти стили доступны на всех языках, это стили . Все они написаны в стиле «Должен ли я поддержать ОО в этой ситуации?»

Система очень сложна и имеет примерно 9 тыс. LOC (просто произвольный уровень). - По мере усложнения систем преимущества, получаемые благодаря инкапсуляции сложности, значительно возрастают. С ОО, в отличие от других методов, вы склонны заключать в себе все большую и большую сложность, что очень ценно на этом уровне. Объектный или процедурный должен быть одобрен до этого. (Это не защищает какой-то конкретный язык. OO C, на мой взгляд, соответствует этим функциям больше, чем OO C ++, языку с печально известной репутацией неглубоких абстракций и возможностью есть в магазинах даже с одним посредственным / упрямым программистом на обед).

Ваш код не является операцией над данными (т.е. базируется на базе данных или на основе математики / анализа). Код на основе базы данных часто проще представить в процедурном стиле. Код на основе анализа часто проще представить в функциональном стиле.

Ваша модель - это симуляция чего-то (ОО превосходит симуляции).

Вы делаете что-то, для чего полезна диспетчеризация OO на основе объектных подтипов (иначе вам нужно отправить сообщение всем объектам определенного типа и различных подтипов и получить соответствующую, но разную реакцию от всех них) ,

Ваше приложение не является многопоточным, особенно в кодовой базе неработающего типа задачи. OO довольно проблематично в многопоточных программах, требующих разных потоков для выполнения разных задач. Если ваша программа структурирована с одним или двумя основными потоками и многими рабочими потоками, выполняющими одну и ту же вещь, запутанный поток управления программами OO легче обрабатывать, поскольку все рабочие потоки будут изолированы в том, что они касаются, и их можно рассматривать как монолитный участок кода. Рассмотрим любую другую парадигму на самом деле. Функциональность превосходит многопоточность (отсутствие побочных эффектов - огромное преимущество), а объектно-ориентированное программирование может дать вам преимущество с некоторой инкапсуляцией ОО, однако с более прослеживаемым процедурным кодом в критических разделах вашей кодовой базы. Процедурные конечно выделяется и в этой области.

4
6.11.2010 13:42:41

Лично я считаю, что ООП практически необходима для любого крупного приложения. Я не могу представить, чтобы программа содержала более 100 тысяч строк кода без использования ООП, это был бы кошмар обслуживания и проектирования.

0
6.11.2010 16:41:04

Я говорю вам, когда ООП плохо.

Когда архитектор пишет действительно сложный, недокументированный код ООП. Уходит на полпути через проект. И во многих его общих фрагментах кода, которые он использовал в различных проектах, отсутствует код. Слава богу за .NET Reflector.

И организация не работала с Visual Source Safe или Subversion.

И мне жаль. 2 страницы кода для входа в систему довольно нелепы, даже если это мило OOPed ....

-1
22.11.2010 18:26:31

OO позволяет размещать логику, связанную с объектом, в одном месте (классе или объекте), чтобы его можно было отделить и упростить отладку и обслуживание.

Я заметил, что каждое приложение представляет собой комбинацию ОО и процедурного кода, где процедурный код - это клей, который связывает все ваши объекты вместе (по крайней мере, код в вашей основной функции). Чем больше вы можете превратить ваш процедурный код в ОО, тем проще будет поддерживать ваш код.

1
3.12.2010 00:37:43

Почему ООП используется для программирования:

  1. Его гибкость - ООП действительно гибок с точки зрения реализации использования.
  2. Это может уменьшить ваши исходные коды более чем на 99,9% - может показаться, что я преувеличиваю, но это правда.
  3. Реализовать безопасность намного проще - мы все знаем, что безопасность является одним из важнейших требований, когда речь заходит о веб-разработке. Использование ООП может облегчить реализацию безопасности в ваших веб-проектах.
  4. Это делает кодирование более организованным - все мы знаем, что Чистая Программа - это Чистое Кодирование. Использование ООП вместо процедурных делает вещи более организованными и систематизированными (очевидно).
  5. Это помогает вашей команде легко работать друг с другом - я знаю, что у некоторых из вас были / были опытные командные проекты, а некоторые из вас, ребята, знают, что важно иметь один и тот же метод, реализации, алгоритм и т. Д. И т. Д. И т. Д.
1
10.04.2013 16:17:58