Я в основном пишу небольшие скрипты в python, около 50 - 250 строк кода. Обычно я не использую никаких объектов, просто простое процедурное программирование.
Я знаю основы ООП, и раньше я использовал объект на других языках программирования, но для небольших скриптов я не вижу, как объекты улучшат их. Но, возможно, это только мой ограниченный опыт работы с ООП.
Я пропустил что-то, не пытаясь использовать объекты, или ООП просто не имеет большого смысла для небольших скриптов?
Я использую любую парадигму, которая лучше всего подходит для данной проблемы - будь то процедурный, ООП, функциональный,... размер программы не является критерием, хотя (с небольшим отрывом) большая программа может с большей вероятностью воспользоваться преимуществами сильных сторон ООП - несколько экземпляров класса, подклассификация и переопределение, специальные перегрузки метода, шаблоны проектирования ООП и т.д. Любая из этих возможностей вполне может произойти в небольшом script, только несколько более высокая вероятность того, что это произойдет в более крупном.
Кроме того, я ненавижу инструкцию global, поэтому, если это потребует естественный процедурный подход, я почти всегда переключусь на ООП - даже если единственным преимуществом является возможность использовать квалифицированное имя вместо barename, для которого потребуется global.
Определенно нет необходимости "пытаться усерднее" в целом - просто спросите себя, "есть ли здесь возможность использовать (a) несколько экземпляров (и т.д.)", и это скоро станет второй натурой, т.е. вы будете выявить возможности без необходимости сознательно напоминать себе каждый раз, чтобы их искать, и в результате ваше программирование улучшится.
Объектно-ориентированное программирование, полезное для представления систем как объектов реального мира (и, надеюсь, упрощает понимание крупной программной системы), не является серебряной пулей для каждого решения (несмотря на то, что некоторые люди учат).
Если ваша система не использует то, что предоставляет ООП (такие вещи, как абстракция данных, инкапсуляция, модульность, полиморфизм и наследование), тогда было бы бессмысленно брать на себя все накладные расходы на выполнение ООП. Однако, если вы обнаружите, что по мере роста вашей системы эти вещи становятся для вас более серьезными, тогда вам может потребоваться перейти к решению ООП.
Изменить. В качестве обновления вы можете захотеть перейти в Википедию, чтобы прочитать статьи по различным критике ООП. Помните, что ООП - это инструмент, и так же, как вы не использовали бы молот для всего, ООП не следует использовать для всего. Рассмотрим лучший инструмент для работы.
Если вы планируете использовать script независимо, то нет. Однако, если вы планируете import его и повторно использовать некоторые из них, то да. Во втором случае лучше написать несколько классов, обеспечивающих требуемую функциональность, а затем выполнить условный запуск (if __name__=='__main__':) с кодом для выполнения версии script script.
Одной из неудачных привычек, разработанных с помощью oop, является Objectophrenia - заблуждение об обнаружении объектов в каждом фрагменте кода, который мы пишем.
Причина, по которой это происходит, объясняется тем, что мы верим в существование теоремы об унифицированных объектах.
Каждый фрагмент кода, который вы пишете, вы начинаете рассматривать его как шаблон для объектов и как они вписываются в нашу личную схему вещей. Несмотря на то, что это может быть маленькой задачей, мы получаем соблазн вопросом - это то, что я могу разместить в моем репозитории классов, который я мог бы использовать и в будущем? Я вижу шаблон здесь с кодом, который я ранее написал, и с кодом, который мой объект ясновидения говорит мне, что я когда-нибудь напишу? Могу ли я структурировать текущую задачу в один из этих шаблонов.
Это раздражающая привычка. Часто лучше не иметь его. Но когда вы обнаружите, что каждый бит кода, который вы пишете, каким-то образом попадает в шаблоны, и вы реорганизуете/перестраиваете эти шаблоны, пока не покрываете большинство ваших потребностей, вы склонны испытывать чувство удовлетворения и достижения.
Проблемы начинают появляться, когда программист получает бредовое (компульсивное обсессивно-объектно-ориентированное расстройство) и не понимает, что существуют исключения из шаблонов и попытка чрезмерного манипулирования шаблонами для покрытия большего числа случаев неверна. Это похоже на мою одержимость детства, пытаясь покрыть кусок хлеба полностью маслом или вареньем, каждое утро я завтракал. Иногда бывает лучше оставить объектно-ориентированное восприятие и просто выполнить задачу под рукой быстро и грязно.
Принятая промышленная пословица 80-20 может быть хорошей мерой. Используя эту поговорку иначе, чем обычно воспринимается, мы можем сказать, что 80% времени имеют объектно-ориентированное восприятие. 20% времени - быстро и грязно.
Будьте погружены в объекты, но в конечном итоге вы должны противостоять его потреблению.
Вероятно, вы еще не сделали достаточно программирования, потому что если у вас есть, вы увидите все шаблоны, которые вы сделали, и вы также начнете верить в шаблоны, которые вы еще не применили. Когда вы начинаете видеть такие видения объектофрении, пришло время быть осторожным, чтобы не потреблять их.
Мой опыт заключается в том, что любой чисто процедурный script длиннее нескольких десятков строк становится трудно поддерживать. Во-первых, если я устанавливаю или изменяю переменную в одном месте и использую ее в другом месте, и эти два места не могут поместиться на один экран, проблема будет следующей.
Ответ, конечно же, заключается в том, чтобы затянуть область действия и сделать другие части вашего приложения более инкапсулированными. ООП является одним из способов сделать это и может быть полезным способом моделирования вашей среды. Мне нравится OOP, поскольку я нахожу, что могу мысленно перескакивать от того, как будет работать внутри конкретного объекта, подумать о том, как объекты будут работать вместе, и я остаюсь более здравым.
Однако ООП, конечно, не единственный способ сделать ваш код более инкапсулированным; другим подходом будет набор небольших, хорошо названных функций с тщательно определенными входами и выходами и мастер script, который вызывает эти функции по мере необходимости.
Я пропустил что-то, не пытаясь использовать объекты, или ООП просто не имеет большого смысла для небольших скриптов?
Объекты купят вам инкапсуляцию и повторное использование (через наследование). Ничто не может быть очень полезно при написании небольших скриптов. Когда вы написали коллекцию похожих сценариев или вы многократно меняете свои сценарии, возможно, вам стоит подумать о том, где могут помочь объекты.
OOP - это инструмент для управления сложностью кода, 50-250 строк кода редко бывают сложными. Большинство сценариев, которые я написал, в основном процедурные. Так что да, для небольших скриптов просто идет процедурное программирование.
Обратите внимание, что для значительно сложных сценариев ООП может быть более уместным, но все же нет жесткого и быстрого правила, в котором говорится, что для них используется ООП. Тогда это вопрос личных предпочтений.
Используйте правильный инструмент для правильной работы. Для небольших скриптов, которые не требуют сложных структур данных и алгоритмов, для объектно-ориентированных концепций, скорее всего, не будет.
В вашем случае я бы сказал, что ООП будет полезно, только если это сделает скрипты более читабельными и понятными. Если нет, вам, вероятно, не нужно беспокоиться.
ООП - это еще одна парадигма. Многие проблемы могут быть решены с использованием как процедурного, так и ООП.
Я использую OOP, когда вижу ясный смысл наследования в коде, который я пишу, его проще управлять общим поведением и общими атрибутами.
Иногда это позволяет легко понять и управлять. Даже если код небольшой.
Еще одно преимущество ООП заключается в том, чтобы сообщать о намерениях (будь то другие разработчики, менеджеры или вы сами в будущем). Если script достаточно мал, где он может быть полностью передан в нескольких предложениях, тогда ООП, по-моему, не обязательно.
Использование ООП для нескольких сотен строк кода редко имеет смысл. Но если ваш script полезен, он, вероятно, будет расти довольно быстро, потому что новые функции будут добавлены. Если это так, лучше начать кодирование ООП, как он будет платить в долгосрочной перспективе.
ООП - это то, что вы получаете, если добавить полиморфизм поверх модульного программирования.
Последний из них способствует низкому сочетанию, инкапсуляции, разделению ответственности и некоторым другим концепциям, которые обычно производят код, который является коротким, выразительным, поддерживаемым, гибким, расширяемым, многоразовым и надежным.
Это не столько вопрос о размере, сколько о длительности жизненного цикла программного обеспечения. Если вы напишете какой-либо код, насколько это возможно, если он достаточно сложный, что вы не хотите его переписывать, когда ваши требования меняются, важно, чтобы он соответствовал вышеупомянутым критериям.
OOP упрощает модульное программирование тем, что оно разработало решения для реализации концепций, продвигаемых модульным программированием, и что полиморфизм позволяет действительно низкое сцепление посредством инъекции зависимостей.
Мне лично проще использовать ООП для достижения модульности (и, в частности, повторного использования), но, я думаю, это вопрос привычки.
Сделать это в одном предложении. ООП не поможет вам в решении данной проблемы лучше, чем процедурное программирование, но вместо этого даст решение, которое легче применить к другим проблемам.
Это действительно зависит от того, что script - это то, что он делает, и как вы думаете о мире.
Лично после того, как script сделал это через 20-30 строк кода, я обычно могу найти способ, который ООП имеет для меня больше смысла (особенно в Python).
Например, скажем, я пишу script, который анализирует файл журнала. Ну, концептуально я могу представить эту машину "анализатора журналов"... Я могу бросить в нее все эти листы бумаги, и она будет сортировать их, вырезать части из некоторых страниц и вставлять их на другой и, в конце концов, передать мне хороший отчет.
Итак, я начинаю думать, ну, что делает этот парсер? Ну, во-первых, он (да, парсер - это он. Я не знаю, сколько из моих программ - женщины, но это, определенно, парень), чтобы читать страницы, поэтому мне понадобится метод, называемый страницей читатель. Затем он найдет все данные, относящиеся к новому процессу Frobnitz, который мы используем. Затем он собирается переместить все ссылки на процесс Фробницца, чтобы появиться рядом с графиком Пасхи Банни. Ооо, теперь мне нужен метод 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
Это действительно надуманный пример, и, честно говоря, вероятно, не такая ситуация, в которой я бы использовал ООП... но это действительно зависит от того, что мне легче всего понять в тот конкретный момент времени.
Прежде всего - что вы подразумеваете под объектами? В функциях Python есть объекты, и вы, скорее всего, используете их.:)
Если по объектам вы имеете в виду классы и экземпляры, то я бы сказал что-то очевидное: нет, нет оснований говорить, что использование их делает ваш код лучше сам по себе. В небольших сценариях не будет никакого рычага, исходящего из сложного дизайна OO.
"Script" означает "последовательный" и "процедурный". Это определение.
Все объекты, с которыми работает ваш script, - это - объекты - объекты. Все программирование включает объекты. Объекты уже существуют в контексте, в котором вы пишете script.
Некоторые языки позволяют четко идентифицировать объекты. Некоторые языки четко не идентифицируют объекты. Объекты всегда. Это вопрос о том, делает ли язык понятным или неясным.
Так как объекты всегда, я нахожу, что это помогает использовать язык, который позволяет четко идентифицировать объекты, их атрибуты, методы и отношения. Даже для коротких "скриптов" я нахожу, что явные объекты и язык OO помогают.
Точка такова.
Нет никакого полезного различия между "процедурным", "Script" и "OO".
Это просто сдвиг акцента. Объекты всегда. Мир по своей сути объектно-ориентирован. Реальный вопрос: "Используете ли вы язык, который делает объекты явными?"
как тот, кто выполняет множество скриптов, если вы понимаете, что ваш код может в какой-то момент выйти за пределы 250 строк, чтобы перейти к oop. Я использую много vba и vbscript, и я согласен с тем, что все, что находится под 100 строками, обычно довольно простое, и тратить время на планирование хорошего дизайна oop - это просто отходы.
Сказано, что у меня есть один script, который дошел до 500 строк + и оглядывался назад, потому что я не делал этого, и это быстро превратилось в нечестивый беспорядок спагетти. так что теперь что-нибудь более 200 строк, я убедился, что у меня есть хороший план oop раньше времени