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

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

Итак, я начинаю думать, что же делает этот парсер?Ну, во-первых, он (да, парсер это он. Я не знаю, сколько в моих программах женщин, но эта, безусловно, парень) собирается читать страницы, поэтому мне понадобится метод, называемый pageчитатель.Затем он найдет все данные, относящиеся к новому процессу Фробница, который мы используем.Затем он собирается переместить все ссылки о процессе Фробница, чтобы появиться рядом с графиком Пасхального кролика.Ох, теперь мне нужен метод findeasterbunny.После того, как он это сделает, он возьмет остальные журналы, удалит каждое 3-е слово и обратный порядок текста.Так что мне понадобится метод 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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

Дело в том.

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

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

Answer 7

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