Практическое использование ООП - PullRequest
Новая
       69

Практическое использование ООП

9 голосов
/ 19 ноября 2009

У меня недавно была дискуссия с коллегой, который не фанат ООП . Мое внимание привлекло то, что он сказал:

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

Мы в небольшой компании, разрабатывающей небольшие проекты для сайтов электронной коммерции и недвижимости.

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

Ответы [ 13 ]

0 голосов
/ 20 ноября 2009

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

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

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

0 голосов
/ 19 ноября 2009

Мало того, что это делает

  • программирование проще / удобнее в обслуживании в текущей ситуации для других людей (и для вас)
  • Это уже позволяет упростить операции CRUD базы данных (создание, обновление, удаление).

Вы можете найти больше информации об этом, ища: - Java: Hibernate - Dot Net: Entity Framework

Узнайте даже, как LINQ (Visual Studio) может НАМНОГО упростить вашу жизнь в программировании.

  • Кроме того, вы можете начать использовать шаблоны проектирования для решения реальных проблем (шаблоны проектирования - все о ОО)

Возможно, даже с небольшой демонстрацией весело демонстрировать:

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

.ps. Я попытался написать это в стиле PSEUDO:)

ОО путь

Код, который вы звоните: io.file.save (objectsCollection.ourFunctionForSaving ())

объекты классаCollection

функция ourFunctionForSaving () в виде строки

String _Objects 

   for each _Object in objectsCollection
         Objects &= _Object & "-"
   end for

return _Objects метод окончания

NON-OO Way

Не думаю, что напишу не ооо код. Но подумай:)

СЕЙЧАС ДАЕМ СКАЗАТЬ

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

И скажем, мы хотели бы добавить функцию загрузки, сколько кода вам нужно написать? В OO-способе вам нужно только добавить метод New Sub, который может разбить все данные на параметры (это происходит один раз).

Пусть ваш коллега подумает об этом:)

0 голосов
/ 19 ноября 2009

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

Хороший дизайн не зависит от использования специфических для ОО языковых функций, хотя обычно их лучше всего использовать.

Страница:
...