ООП имеет смысл для маленьких сценариев?

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

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

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

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

«Скрипт» означает «последовательный» и «процедурный». Это определение.

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

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

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

Дело вот в чем.

Нет полезного различия между «процедурным», «скриптовым» и «ОО».

Это просто смещение акцента. Объекты всегда там. Мир по своей сути объектно-ориентирован. Настоящий вопрос: «Используете ли вы язык, который делает объекты явными?»

Это действительно зависит от того, что это за сценарий, что он делает и как вы думаете о мире.

Лично после того, как сценарий прошел 20-30 строк кода, я обычно могу найти способ, которым ООП имеет для меня больше смысла (особенно в Python).

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

Тогда я начинаю думать, а что делает этот синтаксический анализатор? Ну, во-первых, он (да, синтаксический анализатор - это он. Я не знаю, сколько моих программ - женщины, но эта определенно парень) будет читать страницы, поэтому мне понадобится метод под названием page читатель. Затем он найдет все данные, относящиеся к новому процессу Фробница, который мы используем. Затем он собирается переместить все упоминания о процессе Фробница рядом с графиком «Пасхальный кролик». Ох, теперь мне нужен метод findeasterbunny. После того, как он это сделает, он возьмет остальные журналы, удалит каждое третье слово и поменяет порядок текста на обратный. Так что мне также понадобятся метод thirdwordremover и метод textreversal . Итак, пустой класс оболочки будет выглядеть так:

class LogParser(Object):
    def __init__(self):
         #do self stuff here
    def pageReader(self):
         #do the reading stuff here, probably call some of the other functions
    def findFrobnitz(self):
         pass
    def findEasterBunny(self):
         pass
    def thirdWordRemover(self):
         pass
    def textReversal(self):
         pass

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прежде всего - что вы подразумеваете под объектами? В Python функции - это объекты, и вы, скорее всего, их используете. :)

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

как человек, который делает много скриптов, если вы понимаете, что ваш код может в какой-то момент выйти за пределы 250 строк, начните делать oop. Я использую много vba и vbscript и соглашусь, что все, что меньше 100 строк, обычно довольно просто, и тратить время на планирование хорошего oop-дизайна - пустая трата времени.

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

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

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

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

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

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

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

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