Когда перейти с процедурного на ООП?

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Редко бывает полезно изменить стиль программирования текущего проекта.

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

проверьте, например, эту очень интересную книгу о кодировании ООANSI-C

Answer 6

Это зависит от задачи, но, выполнив и то, и другое, вот о чем я бы подумал:

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

2. Считаете ли вы, что проблема, на которую вы нападаете, предсказуема и повторяется?лучше всего выполнить задачу, выполнив следующие шаги для ее решения или применяя алгоритмы?

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

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

Answer 7

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

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

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