Процедурный код против кода ООП

19

Я закончил проект на PHP с числом строк более 13000 в процедурном стиле [потому что я очень хорошо знаком с этим, хотя я знаю ООП], и проект работает отлично.

Но я должен преобразовать это в ООП? [ потому что мир занят ООП ]

Мой код не нуждается в какой-либо функции ООП [инкапсуляция, наследование в основном ...]!

И что же мне делать?

И какую помощь я получу, если преобразовать ее в ООП?

programming-languages programming-practices

— Sourav
источник

21

Пожалуйста, держите нас в курсе, если вам нужно изменить этот проект. Было бы интересно узнать, довольны ли вы тем, что приняли это решение, или сожалеете об этом.

— JeffO

2

Вам нужна инкапсуляция. ОО - один из способов получить это; Может быть, у вас есть другой, который работает для вас, но так или иначе вам нужно контролировать зависимости кода.

— Марчин

Как насчет анекдота для вас: несколько лет назад я работал над веб-приложением среднего размера, написанным в основном на JavaScript (не спрашивайте). Стиль кодирования был в значительной степени процедурным. Когда проект был близок к завершению, я был недоволен тем, как был написан код, и переписал значительную его часть в OOP-JavaScript. Это вызвало задержку в завершении проекта, и в итоге мы провели относительно небольшое обслуживание проекта. Я всегда задавался вопросом, стоило ли все это кодирование усилиями ;-)

— Pandincus

да, это того стоило. держать двери повторного использования открытыми всегда стоит.

— Чани,

1

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

— Камил Томшик

52

Мой код не нуждается в какой-либо функции ООП

Вы ответили на свой вопрос - если вам не нужен ООП в этом случае, и ваш проект работает, не конвертируйте его.

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

В процедурном программировании нет ничего плохого, если оно используется в соответствующем месте.

— ChrisF
источник

2

+1 из соглашения "вы должны посмотреть на использование ООП для вашего следующего проекта".

— Кэри Чоу

11

+1 да, если работает правильно, не исправляй.

— Сетзамора

4

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

— JeffO

7

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

— TMN

@ TMN - это подразумевается - я должен сделать это явным.

— ChrisF

16

Нет, и не только потому, что вам не нужен ООП.

Если ваша программа уже завершена и работает удовлетворительно, то в течение 90% времени по какой-либо причине перезаписывать готовый код будет пустой тратой времени.

ООП не все мощно, есть много мест, где ООП не следует использовать, поэтому не просто используйте его, потому что ООП является тенденцией.

— Skeith
источник

1

Под "готовым кодом" вы подразумеваете, что это работает?

— JeffO

@ Да, сэр! это прекрасно :)

— Sourav

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

— Скиф

Пожалуйста, уточните «много мест, где ООП не следует использовать».

— Сокол

3

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

— SK-logic

8

Мой общий взгляд на парадигмы (и почему ни одна из трех основных парадигм не является правильным или неправильным способом программирования):

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

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

Функциональное программирование хорошо, когда вам необходимо сильное отделение механизма от политики. Наличие функции механизма, которая принимает функцию политики, является хорошим примером. (Я узнал об этом, посмотрев на модуль std.algorithm языка программирования D ). Абстрагирование изменяемого состояния на границе между кодом политики и механизма, как правило, упрощает анализ API. Если изменяемое состояние используется частным образом в одном из них, это деталь реализации. Другой сильной стороной функционального программирования является параллелизм по очевидным причинам.

— dsimcha
источник

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

— Кевин Пено,

7

Код никогда не "нуждается в ООП". Это программисты, поскольку они способны мыслить в разных режимах, которые предполагают, что та или иная конкретная проблема «нуждается» в $ PARADIGM или лучше всего решается таким образом.

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

— Инго
источник

5

Вы должны конвертировать ваш проект в ООП только в том случае, если есть четкое указание на необходимость ООП. Возможные сценарии, в которых это может произойти (среди прочих):

расширение проекта
добавив больше разработчиков в команду

и даже в этих сценариях может не потребоваться конвертировать ваш проект в ООП.

— Тимоти Грут
источник

Хороший вопрос, но можете ли вы сказать мне, почему будет проблемой увеличить масштаб проекта или добавить больше разработчиков в команду, если это процедурный код?

— Сурав

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

— Тимоти Гроот

3

это именно то, что пришло мне в голову, когда я прочитал вопрос. он говорит, что написал 13 тысяч строк кода. Я надеюсь, что это не будет потрачено впустую, используя только один раз. и если он должен быть использован повторно, то oop станет обязательным. в противном случае это стало бы кошмаром для новых разработчиков

— Chani

4

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

— jwenting
источник

2

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

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

Это позволяет вам писать все большие и большие программы, при этом вы можете вместо этого превратить своего огромного слона в задачу размером в сотню мышей. Дополнительным бонусом является то, что вы можете взять некоторые из этих «мышей» и использовать их в других программах!

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

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

Мой совет на следующий раз: попробуйте написать свой обычный процедурный код, но создайте единый объект из вашей основной структуры данных. Посмотрите, как вы обнаружите, что работать с ним проще, чем передавать данные от функции к функции.

— gbjbaanb
источник

0

Мой код не нуждается в какой-либо функции ООП [инкапсуляция, наследование в основном ...]!

Откуда ты это знаешь?

Вам нужно поддерживать этот проект? Планируются ли новые функции? Будут ли другие люди, которые будут развиваться вместе с вами? Вы повторили себя? Код трудно понять?

Если ответ «да», то, возможно, вам следует задуматься о настройке ООП-скелета и идти по этому пути.

— vihus
источник