Коли в Python, коли я повинен використовувати функцію замість методу?

Дзен Python заявляє, що робити лише один спосіб - але часто я стикаюся з проблемою вирішення питання про те, коли використовувати функцію, а не коли використовувати метод.

Візьмемо тривіальний приклад - об’єкт ChessBoard. Скажімо, нам потрібен певний спосіб отримати всі законні кроки короля, доступні на дошці. Чи пишемо ми ChessBoard.get_king_moves () чи get_king_moves (chess_board)?

Ось кілька пов’язаних питань, які я подивився:

• Чому пітон використовує "магічні методи"?
• Чи є причина, що для рядків Python немає методу довжини рядка?

Відповіді, які я отримав, були значною мірою непереконливими:

Чому Python використовує методи для деяких функцій (наприклад, list.index ()), але функціонує для інших (наприклад, len (список))?

Основна причина - історія. Функції використовувались для тих операцій, які були загальними для групи типів і призначені для роботи навіть для об'єктів, у яких взагалі не було методів (наприклад, кортежі). Також зручно мати функцію, яку можна легко застосувати до аморфної колекції об’єктів, коли ви використовуєте функціональні функції Python (map (), apply () та ін.).

Насправді реалізація len (), max (), min () як вбудованої функції насправді менше коду, ніж реалізація їх як методів для кожного типу. Можна посперечатися щодо окремих випадків, але це частина Python, і зараз зробити такі фундаментальні зміни вже пізно. Функції повинні залишатися, щоб уникнути масового зламу коду.

Хоча цікаво, вище сказане насправді не говорить про те, яку стратегію слід прийняти.

Це одна з причин - за допомогою власних методів розробники можуть вільно обирати іншу назву методу, наприклад, getLength (), length (), getlength () чи що завгодно. Python застосовує суворе іменування, щоб можна було використовувати загальну функцію len ().

Трохи цікавіше. Я вважаю, що функції в певному розумінні є пітонічною версією інтерфейсів.

Нарешті, від самого Гвідо :

Якщо говорити про здібності / інтерфейси, то змусило мене задуматися про деякі наші "негідні" назви спеціальних методів. У мовній довідці йдеться: "Клас може реалізувати певні операції, які викликаються спеціальним синтаксисом (наприклад, арифметичні операції або підписка та розрізання) шляхом визначення методів зі спеціальними іменами". Але є всі ці методи зі спеціальними іменами на кшталт __len__або __unicode__які, здається, передбачені для вигоди вбудованих функцій, а не для підтримки синтаксису. Імовірно, в Python на основі інтерфейсу ці методи перетвориться на регулярно названі методи на ABC, так що __len__це стане

class container:
  ...
  def len(self):
    raise NotImplemented

Хоча, обмірковуючи це ще раз, я не бачу, чому всі синтаксичні операції не просто викликатимуть відповідний нормально названий метод на певному ABC. <Наприклад, " ", імовірно, може викликати " object.lessthan" (або, можливо, " comparable.lessthan"). Таким чином, ще однією перевагою була б здатність відхилити Python від цієї дивної дивацтва, що мені здається поліпшенням HCI .

Гм. Я не впевнений, що згоден (цифра, що :-).

Є два біти "обгрунтування Python", які я хотів би пояснити спочатку.

Перш за все, я вибрав len (x) над x.len () з причин HCI ( def __len__()прийшов набагато пізніше). Насправді є дві взаємопов'язані причини, обидві ІСІ:

(a) Для деяких операцій позначення префікса просто читається краще, ніж постфікс - операції з префіксом (і інфіксом!) мають давню традицію в математиці, яка подобається нотаціям, коли візуальні матеріали допомагають математику думати про проблему. Порівняйте легкий , з яким ми перепишемо формулу , як x*(a+b)в x*a + x*bдо незграбності робити те ж саме з використанням вихідного OO позначення.

(b) Коли я читаю код, який говорить, len(x)я знаю, що він запитує про довжину чогось. Це говорить мені про дві речі: результат - ціле число, а аргумент - якийсь контейнер. Навпаки, коли я читаю x.len(), я вже повинен знати, що xце якийсь контейнер, що реалізує інтерфейс або успадковує клас, у якого є стандарт len(). Зауважте, що ми час від часу виникаємо плутанини, коли у класу, який не реалізує відображення, є метод get()чи keys()метод, або щось, що не є файлом, має write()метод.

Говорячи те ж саме по-іншому, я бачу 'len' як вбудовану операцію . Мені б не хотілося цього втрачати. Я не можу точно сказати, чи ти це мав на увазі чи ні, але "def len (self): ...", безумовно, звучить так, що ти хочеш знищити його звичайним методом. Я на цьому рішуче -1.

Другий біт обґрунтування Python, який я пообіцяв пояснити, є причиною, чому я обрав спеціальні методи, щоб виглядати, __special__а не просто special. Я передбачив безліч операцій, які класи можуть захотіти переосмислити, деякі стандартні (наприклад, __add__або __getitem__), деякі не такі стандартні (наприклад, підберезники __reduce__довгий час взагалі не підтримували код C). Я не хотів, щоб ці спеціальні операції використовували звичайні назви методів, тому що тоді вже існуючі класи або класи, написані користувачами без енциклопедичної пам'яті для всіх спеціальних методів, могли б випадково визначити операції, які вони не мали на увазі здійснити , з можливими катастрофічними наслідками. Іван Крстіч пояснив це більш лаконічно у своєму повідомленні, яке надійшло після того, як я все це написав.

- - Гуїдо ван Россум (домашня сторінка: http://www.python.org/~guido/ )

Я розумію це в тому, що в деяких випадках позначення префікса просто має більше сенсу (тобто, Duck.quack має більше сенсу, ніж квак (Duck) з мовної точки зору.), І знову ж таки, функції дозволяють "інтерфейси".

У такому випадку, я думаю, було б реалізувати get_king_moves виходячи виключно з першої точки Гуйдо. Але це все ще залишає багато відкритих питань щодо скажімо, реалізація класу стеків та черг з подібними методами push та pop - чи це вони повинні бути функціями чи методами? (тут я б здогадався про функції, тому що мені дуже хочеться сигналізувати про push-pop інтерфейс)

TLDR: Чи може хтось пояснити, якою має бути стратегія вирішення питання щодо використання функцій проти методів?

Моє загальне правило таке - операція виконується на об'єкті чи об'єкті?

якщо це робиться об'єктом, це повинна бути операція-член. Якщо це може застосовуватися і до інших речей, або робиться об'єктом чогось іншого, тоді це повинна бути функція (або, можливо, член чогось іншого).

При впровадженні програмування традиційно (хоч і невірно реалізовувати) опис об'єктів з точки зору реальних об'єктів, таких як автомобілі. Ви згадуєте качку, тож підемо з цим.

class duck: 
    def __init__(self):pass
    def eat(self, o): pass 
    def crap(self) : pass
    def die(self)
    ....

У контексті аналогії "об'єкти - це реальні речі", "правильним" є додавання методу класу для всього, що об'єкт може зробити. Тому скажіть, що я хочу вбити качку, чи я додаю .kill () до качки? Ні ... наскільки я знаю, тварини не здійснюють самогубства. Тому, якщо я хочу вбити качку, я повинен це зробити:

def kill(o):
    if isinstance(o, duck):
        o.die()
    elif isinstance(o, dog):
        print "WHY????"
        o.die()
    elif isinstance(o, nyancat):
        raise Exception("NYAN "*9001)
    else:
       print "can't kill it."

Віддаляючись від цієї аналогії, чому ми використовуємо методи та класи? Тому що ми хочемо містити дані та сподіваємось структурувати наш код таким чином, щоб він був повторним та розширеним у майбутньому. Це підводить нас до поняття капсулювання, яке дуже дороге для OO-дизайну.

Принцип інкапсуляції - це дійсно те, до чого це зводиться: як дизайнер ви повинні приховувати все про внутрішню реалізацію та клас, до яких не обов'язково отримувати доступ будь-який користувач чи інший розробник. Оскільки ми маємо справу з екземплярами класів, це зводиться до "які операції мають вирішальне значення в цьому випадку ". Якщо операція не є конкретною інстанцією, то вона не повинна бути функцією-членом.

TL; DR : що сказав @Bryan Якщо він працює над екземпляром і потребує доступу до даних, що є внутрішніми для екземпляра класу, це повинна бути функцією-членом.

Використовуйте клас, коли хочете:

1) Виділіть викликовий код від деталей реалізації - скориставшись абстракцією та інкапсуляцією .

2) Коли ви хочете бути заміненими іншими об'єктами - скористайтеся поліморфізмом .

3) Коли ви хочете повторно використовувати код для подібних об'єктів - скористайтеся спадщиною .

Використовуйте функцію для дзвінків, які мають сенс для багатьох різних типів об'єктів - наприклад, вбудовані функції len і repr застосовуються до багатьох видів об'єктів.

Коли говорити, вибір іноді зводиться до питання смаку. Подумайте з точки зору того, що найбільш зручно і читабельно для типових дзвінків. Наприклад, що було б краще (x.sin()**2 + y.cos()**2).sqrt()чи sqrt(sin(x)**2 + cos(y)**2)?

Ось просте правило: якщо код діє на один екземпляр об'єкта, використовуйте метод. Ще краще: використовуйте метод, якщо немає вагомих причин писати його як функцію.

У вашому конкретному прикладі ви хочете, щоб він виглядав так:

chessboard = Chessboard()
...
chessboard.get_king_moves()

Не думайте про це. Завжди використовуйте методи, доки ви не скажете собі, що "це не має сенсу робити це методом", і в цьому випадку ви можете зробити функцію.

Я зазвичай думаю про предмет як людина.

Атрибути - ім’я людини, зріст, розмір взуття тощо.

Методи та функції - це операції, які людина може виконувати.

Якщо операцію може зробити будь-яка людина, не вимагаючи нічого унікального для цієї конкретної людини (і не змінюючи нічого в цій конкретній особі), то це функція і повинна бути записана як така.

Якщо операція діє на людину (наприклад, їжа, прогулянка, ...) або вимагає чогось унікального для цієї людини, щоб долучитися до неї (наприклад, танці, написання книги, ...), то це повинен бути метод .

Звичайно, не завжди банально перекладати це на конкретний об’єкт, з яким ти працюєш, але я вважаю, що це хороший спосіб продумати це.

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

Все, що є частиною основної абстракції того, "що ти можеш зробити з річчю ", як правило, має бути методом. Це, як правило, включає все, що може змінити річ , оскільки внутрішній стан даних зазвичай вважається приватним і не є частиною логічної ідеї "що ти можеш зробити з річчю ".

Коли ви приходите до підвищення операцій на рівні, особливо якщо вони пов'язані з кількох речей , я вважаю , що вони, як правило , найбільш природно виражені як функції, якщо вони можуть бути побудовані з громадської абстракції речі без необхідності спеціального доступу до внутрішніх (якщо вони » повторні методи якогось іншого об'єкта). Це має велику перевагу в тому, що коли я вирішу повністю переписати внутрішні відомості про те, як працює моя річ (не змінюючи інтерфейс), у мене є лише невеликий набір методів для перезапису, а потім усі зовнішні функції, написані в рамках цих методів буде просто працювати. Я вважаю, що наполягати на тому, що всі операції з класом X - це методи класу X, призводять до надскладних класів.

Це залежить від коду, про який я пишу. Для деяких програм я моделюю їх як сукупність об'єктів, взаємодія яких породжує поведінку програми; тут найважливіша функціональність тісно поєднана з одним об’єктом і так реалізується в методах, з розсіюванням корисних функцій. Для інших програм найважливіший матеріал - це набір функцій, що управляють даними, а класи використовуються лише для реалізації природних "типів качок", якими маніпулюють функції.

Можна сказати, що "за умови неоднозначності відмовтеся від спокуси здогадатися".

Однак це навіть не здогад. Ви абсолютно впевнені, що результати обох підходів однакові, оскільки вони вирішують вашу проблему.

Я вважаю, що лише добре мати декілька способів досягнення цілей. Я покірно сказав би вам, як це робили інші користувачі, використовувати той, хто "смачніше" / відчуває себе більш інтуїтивно , з точки зору мови.