Когда ООП лучше подходит?

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

Ответов (16)

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

Я продан ООП.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И организация не использовала Visual Source Safe или Subversion.

И мне очень жаль. Две страницы кода для входа в систему - это довольно нелепо, даже если это красиво ООП ....

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

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