ООП имеет смысл для небольших скриптов?

Question

Я в основном пишу небольшие скрипты на python, около 50 - 250 строк кода.Я обычно не использую какие-либо объекты, просто прямое процедурное программирование.

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

Если вы планируете использовать скрипт самостоятельно, то нет.Однако, если вы планируете import и повторно использовать некоторые из них, тогда да.Во втором случае лучше написать несколько классов, обеспечивающих необходимую функциональность, а затем выполнить условный прогон (if __name__=='__main__':) с кодом для выполнения «скриптовой» версии скрипта.

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

Answer 10

ООП это просто еще одна парадигма. Многие проблемы могут быть решены с использованием как процедурных, так и ООП.

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

Иногда это облегчает понимание и управление. Даже если код маленький.