Когда переключиться с процедурного на ООП?

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

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

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

источник

2010-12-13 babonk

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

PHP - это гибридный язык. Если вы создаете приложения только процедурные или все-ООП, то вы используете его неправильно и, скорее всего, генерируете нестандартные API. – mario

@mario: Это интересно. Есть ли доступные материалы для чтения? – Jonah

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

источник

2010-12-13 22:35:30 Jonah

Должен согласиться с этим. Если вы просто имеете дело с 10-строчными командами или эквивалентными, убедитесь, что просто используйте несколько строк процедурного кода и выполняйте эту работу, но за все, что вы намереваетесь использовать некоторое время, чтобы другие могли поддерживать или иметь какой-либо значительный размер (всего более 100 строк кода), я бы сказал, что вам лучше инвестировать в oop. – DarinH

Я предполагаю, что этот вопрос с точки зрения/парадигмы новичка. Как только программист имеет опыт написания объектно-ориентированного кода, вы можете, конечно, автор проекта с самого начала использовать эту архитектуру. На самом деле, я бы сказал, что подход «сверху вниз» может сэкономить вам огромное количество времени на крупных проектах.

Для сценария снизу вверх, который вы начертите, я бы сказал, что вам придется это почувствовать. Ссылка this wikipedia статья для получения дополнительной информации о различных подходах, в общем говоря.

Специфического для PHP, я бы сказал, что вы могли бы использовать этот подход для миграции:

Возьмите столько кода, как вы можете (то есть: функция, связанная с) и поместите их в включают в себя файлы.
Создайте контейнерный класс для этого файла. Вы можете начать с использования всех функций, вызвав их в порядке static или даже используя статический (singleton) класс.
Постепенно преобразовать в парадигму экземпляра вместо глобальной информации/статической функции, которая является плохой процедурной программой.

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

источник

2010-12-13 22:36:26 zanlok

Я не уверен, что согласен с вами. Я видел много кодов wannabe-OO, которые создали точный способ, которым вы его описали. К сожалению, это не позволяет понять основные принципы ООП. Главное, чтобы понять, что такое объект, что он может делать, чего он не может/не должен делать и т. Д.Для OO существует больше возможностей, чем повторное использование кода. Кроме того, я не согласен с тем, что процедурное программирование является плохим. Каждая программа OO также имеет код процедуры. В большинстве случаев OO зависит от процедурного кода для работы (т. Е. PHP кодируется на C, а также Java). – netcoder

Я тоже работал над одним проектом. Дело было скорее в том, что оно не было адекватно трансформировано, чем то, что оно не было направлено в правильном направлении. GOTO не «всегда» плохо, либо - так скажите некоторые. У процедурного программирования может быть место, я бы согласился с этим. И еще не найти пути в проекты, которые я возглавляю, хотя :) – zanlok

p.s. делая больше C# в последнее время, чем когда-либо, и после того, как преимущества сильно типизированной системы становятся очевидными, а также модель с большей архитектурой, большинство, вероятно, согласятся, что OO стала волной будущего по какой-то причине? – zanlok

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

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

источник

2010-12-13 22:36:39

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

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

источник

2010-12-13 22:37:42 GolezTrol

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

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

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

источник

2010-12-13 22:39:46

_ «Повторное использование кода часто немного лучше с языками ООП» _; Я считаю, что это очень легко. Особенно движущиеся библиотеки между фреймворками. – Jonah

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

Это зависит от поставленной задачи, но, сделав так, вот что я думаю о:

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

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

В случае сомнений используйте то, с чем вам удобно.

источник

2010-12-13 22:48:22 bitcruncher

Очень редко можно изменить стиль программирования текущего проекта.

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

проверка, например, this very interesting book на OO кодирования в ANSI-C

источник

2010-12-13 22:55:32

Когда переключиться с процедурного на ООП?

ответ

Смежные вопросы