Что должно быть ОО, а что не должно? - PullRequest
5 голосов
/ 07 октября 2008

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

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

Ответы [ 7 ]

5 голосов
/ 07 октября 2008

Реальный мир полон объектов.

Полезно, чтобы мир программного обеспечения соответствовал реальному миру.

«А как насчет« системных утилит »? Они имеют дело только с абстракциями, такими как сокеты, процессы и файловые системы». Они звучат как вещи для меня. У них есть атрибуты и поведение, у них есть ассоциации.

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

Я использую ОО, потому что у меня очень маленький мозг, и я должен научиться жить в его пределах. ОО - опора, которая помогает мне бороться с программированием. Если бы я был умнее, богаче и лучше выглядел, мне не понадобилась бы помощь, и я мог бы писать не OO-программы. К сожалению, я не умный. Без определений классов, чтобы изолировать ответственность и структурировать архитектуру, я бы по-прежнему писал бы однофайловые варианты "hello world".

3 голосов
/ 07 октября 2008

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

Код OO также запутывает то, что вам не нужно знать. Например, мне не нужно знать, какой у меня алгоритм сортировки, пока он не замедлит меня или я уже не программирую для высокопроизводительной среды.

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

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

2 голосов
/ 07 октября 2008

Я согласен с большинством вышеизложенного (или ниже?), Что ОО существует для упрощения сложных задач и разработки программного обеспечения.

Тем не менее, во многих случаях он слишком преувеличен. Я не могу сказать вам, сколько раз мне хотелось, чтобы в Visual Studio была кнопка Unrefactor, чтобы понять смысл кода и поместить все базовые классы в один файл для удобства чтения.

2 голосов
/ 07 октября 2008

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

Конечно, проблема в том, что мы редко знаем с уверенностью, что система не будет расти.

0 голосов
/ 08 ноября 2008

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

0 голосов
/ 07 октября 2008

Я не могу думать ни о чем, кроме хранимых процедур. Получите себе копию Reflector и используйте ее, чтобы взглянуть на библиотеку .NET Framework как на хороший учебный урок. С другой стороны, на рынке существует множество книг по C ++ и ОО, так как это уже давно.

0 голосов
/ 07 октября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...