Неплохо ли использовать функции в ООП?

Я новичок в программировании. Недавно я прочитал:

Ваша программа должна иметь почти все функции, инкапсулированные в функции или методы класса

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

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

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

Мой сценарий следует в основном по этой схеме:

class Tumblr(object): def __init__(self, user): self.user = user def get_posts(self): """Use tumblr api to return a user's posts.""" return client['blog']['posts'] def parse_images(self): """Returns images.""" images = [] for post in posts: if 'image' in post: images.append(post['image']) return images def parse_videos(self): """Returns videos.""" def main(): # this is a function, and thus not OOP? 

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

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

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

3 Solutions collect form web for “Неплохо ли использовать функции в ООП?”

Мех, нет.

Наличие функции main() настолько вездесущей и требуемой на некоторых языках, что использование этого в качестве запуска для запуска в порядке – что-то где-то должно сказать «идти». Хотя, это pythonic, чтобы реализовать это как

 class YourObjectHere(object): ###blahblahblah your code here ... ... def main(): MyObj = YourObjectHere(*args, **kwargs) OtherObj.do_stuff_with_obj(MyObj) #etc etc etc ... ... if __name__ == '__main__': main() 

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

Глубокая последовательность последовательна, конечно, но в первую очередь это глупо. Сделайте то, что вам нужно сделать, но посмотрите на язык, чтобы убедиться, что вы не просто дублируете усилия. См. https://www.youtube.com/watch?v=o9pEzgHorH0 для отличного видео о том, что при написании класса это плохая идея – первое правило обычно является, если объект имеет два метода, а один из них __init__() , вероятно, это не должен быть класс.

Не следует писать классы, когда функции достаточно. Перефразирован из дзен Питона ;

  • Простой лучше, чем сложный.
  • Практичность превосходит чистоту.

В Python вы можете использовать множество методов программирования; процедурный, объектно-ориентированный, функциональный. У всех есть свои силы и недостатки. Но все они используют их.

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

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

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

Ваша программа должна иметь почти все функции, инкапсулированные в функции или методы класса

Обратите внимание на слово «почти». Это твоя лазейка.

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

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

  • Частные члены в Python
  • Действительно ли сделать расширение collection.namedtuple?
  • Как все работает, даже объект?
  • Python меняет сам наследуемый класс
  • UnicodeDecodeError: кодек 'ascii' не может декодировать байт 0xea в позиции 8: порядковый номер не в диапазоне (128)
  • Перегрузка метода для разных типов аргументов в python
  • Родительский класс Python для доступа к дочерним частным переменным
  • Итерация над атрибутами объекта в python
  • Python - лучший язык программирования в мире.