Я закончил проект на PHP с числом строк более 13000 в процедурном стиле [потому что я очень хорошо знаком с этим, хотя я знаю ООП], и проект работает отлично.
Но я должен преобразовать это в ООП? [ потому что мир занят ООП ]
Мой код не нуждается в какой-либо функции ООП [инкапсуляция, наследование в основном ...]!
И что же мне делать?
И какую помощь я получу, если преобразовать ее в ООП?
Ответы:
Вы ответили на свой вопрос - если вам не нужен ООП в этом случае, и ваш проект работает, не конвертируйте его.
Тем не менее, вы должны рассмотреть возможность использования ООП для вашего следующего проекта - но только если это уместно.
В процедурном программировании нет ничего плохого, если оно используется в соответствующем месте.
источник
Нет, и не только потому, что вам не нужен ООП.
Если ваша программа уже завершена и работает удовлетворительно, то в течение 90% времени по какой-либо причине перезаписывать готовый код будет пустой тратой времени.
ООП не все мощно, есть много мест, где ООП не следует использовать, поэтому не просто используйте его, потому что ООП является тенденцией.
источник
Мой общий взгляд на парадигмы (и почему ни одна из трех основных парадигм не является правильным или неправильным способом программирования):
Процедурное программирование хорошо, когда у вас есть проблема, которая проста на высоком уровне (хотя она может быть сложной на низком уровне) и вы хотите написать соответственно простой линейный код. Возможно, легче написать и понять, чем ОО и функционально, если проблема нигде не нуждается в сильном разделении. Примеры: числовой код, большинство небольших записей, большинство небольших подзадач, как только вы разбили вещи, используя OO или функционал.
Объектно-ориентированный код полезен, когда вам нужно сильно отделить проблемы, потому что у вас может быть более одной реализации некоторых проблем. Пример: самое крупное программное обеспечение для бизнеса. Например, вы можете захотеть сильно отделить бизнес-логику от логики представления, потому что они, вероятно, должны будут измениться независимо.
Функциональное программирование хорошо, когда вам необходимо сильное отделение механизма от политики. Наличие функции механизма, которая принимает функцию политики, является хорошим примером. (Я узнал об этом, посмотрев на модуль std.algorithm языка программирования D ). Абстрагирование изменяемого состояния на границе между кодом политики и механизма, как правило, упрощает анализ API. Если изменяемое состояние используется частным образом в одном из них, это деталь реализации. Другой сильной стороной функционального программирования является параллелизм по очевидным причинам.
источник
Код никогда не "нуждается в ООП". Это программисты, поскольку они способны мыслить в разных режимах, которые предполагают, что та или иная конкретная проблема «нуждается» в $ PARADIGM или лучше всего решается таким образом.
Часто бывает так, что программисты, которые знают только одну парадигму, считают, что их парадигма самая лучшая. Один размер подходит всем, и мы все должны спать в постели Прокруста, если это то или иное сейчас модно.
источник
Вы должны конвертировать ваш проект в ООП только в том случае, если есть четкое указание на необходимость ООП. Возможные сценарии, в которых это может произойти (среди прочих):
и даже в этих сценариях может не потребоваться конвертировать ваш проект в ООП.
источник
Оба могут быть хорошими, оба могут быть плохими. Но переоснащение одного так, чтобы оно выглядело как другое, никогда не было хорошей идеей.
источник
Если вы вспомните, почему ОО был изобретен, вы увидите, что ООП вообще не нужен , но иногда это делает вашу жизнь намного проще.
Еще во времена C-программирования очень большая программа могла стать довольно грязной и с ней трудно работать. Таким образом, они изобрели способы разбиения его на модульные куски. ООП использует этот подход и делает его еще более модульным, помещая данные в эти фрагменты программной логики, чтобы они были еще более отделены от остальной части кода.
Это позволяет вам писать все большие и большие программы, при этом вы можете вместо этого превратить своего огромного слона в задачу размером в сотню мышей. Дополнительным бонусом является то, что вы можете взять некоторые из этих «мышей» и использовать их в других программах!
Конечно, реальный мир не совсем такой, и повторное использование объекта так и не получило должного понимания, как это было задумано, но это не значит, что это бесполезная парадигма.
Что бесполезно, так это чрезмерная зависимость от любого стиля кодирования. Любой, кто делает ОО с тысячей крошечных, незначительных классов, на самом деле не делает это правильно - они делают кошмар обслуживания для себя (или кого-то еще). Любой, кто пишет процедурное приложение, которое имеет всего 3 функции, также усложняет жизнь. Наилучший способ - это средние базовые объекты большого размера (иногда называемые компонентами, которые, как мы надеялись, когда-то собирались), которые могут предоставить достаточное количество автономного кода и данных, которые с гораздо большей вероятностью могут быть повторно использованы в изоляции от остальной части вашего приложения.
Мой совет на следующий раз: попробуйте написать свой обычный процедурный код, но создайте единый объект из вашей основной структуры данных. Посмотрите, как вы обнаружите, что работать с ним проще, чем передавать данные от функции к функции.
источник
Откуда ты это знаешь?
Вам нужно поддерживать этот проект? Планируются ли новые функции? Будут ли другие люди, которые будут развиваться вместе с вами? Вы повторили себя? Код трудно понять?
Если ответ «да», то, возможно, вам следует задуматься о настройке ООП-скелета и идти по этому пути.
источник