class Boxer:
def punch(self, punching_bag, strength):
punching_bag.punch(strength)
class PunchingBag:
def punch(self, strength):
print "Punching bag punched with strength", strength
boxer = Boxer()
punching_bag = PunchingBag()
boxer.punch(punching_bag, 2)
Не сумнівайтеся, що punchце гарне ім'я методу у випадку з боксером. Але чи punchдобре також ім'я для методу штампування мішка? В обох випадках я маю на увазі удар як команду (тобто робити удар).
Відповіді:
Гарне емпіричне правило полягає в тому , що імена методів повинні бути дієсловами або предикати такі , що об'єкт ви називаєте їх ( selfв стандартній конвенції Python, thisв більшості інших мов) стає предметом.
Це правило file.closeє помилковим, якщо ви не працюєте з ментальною моделлю, що файл закриває сам себе, або що fileоб'єкт не представляє сам файл, а обробку файлу або якийсь проксі-об'єкт.
Мішок для пробивання ніколи не пробиває себе, так що punchingBag.punch()це не так. be_punched()технічно правильно, але некрасиво. receive_punch()може працювати, або handle_punch(). Інший підхід, вельми популярний в JavaScript, щоб лікувати такі виклики методів , як події, і конвенцій є йти з ім'ям події, з приставкою «на», так що було б on_punched()або on_hit(). Крім того, ви можете прийняти умову про те, що минулі дієприкметники вказують на пасивний голос, і за цією умовою назва методу була б справедливою punched().
Ще один аспект, який слід враховувати, чи знає мішок для пробивання насправді, що його вдарило: чи має значення це чи вдарити його, бити палицею чи наткнутися на нього вантажівкою? Якщо так, то в чому різниця? Чи можете ви звести різницю до аргументу, або вам потрібні різні методи для різних видів отриманого покарання? Один метод із загальним параметром, мабуть, є найелегантнішим рішенням, оскільки він підтримує низький ступінь зв'язку, і такий метод не слід називати punched()або handle_punch(), а щось більш загальне, як receive_hit(). За допомогою такого методу ви можете реалізовувати всілякі актори, які можуть вдарятись пробивати мішки, не змінюючи самого мішка для штампування.
Hitable.
Я думаю, що це концептуальне питання (як ми думаємо про світ). Добре сказати:
door.close()paper.fold()file.close()Дивно говорити:
bag.punch()Потрібно мати в першу чергу себе, наприклад, зброєю. Ви б, напевно, сказали:
punching_bag.move()Для програмних об’єктів добре робити те, що зазвичай роблять інші (або в реальному світі). Але я здогадуюсь, це завжди повинно мати хоч якийсь сенс, що річ робить це з собою . Ви повинні мати можливість легко уявити це, не маючи незрозумілого (як у випадку punching_bag).
Це питання смаку, я думаю. Punching bagРосійський punch()метод, принаймні, відповідає file.close()або frame.move()в сенсі зазнає дії над собою. Більше питання буде, чому Boxerвзагалі існує punch(something)метод?
Coach.sayPunchToBoxer(), Boxer.punchNearestBag()і Bag.punch(). Інакше вам доведеться здогадуватися, що буде щоразу, коли ви телефонуєте Coach.punch(). Загальне правило: якщо об'єкт, який зазнає дії, не вказаний у назві методу, то приймачем є цей об'єкт.
У вас є два різних повідомлення: одне - командувати об'єктом для удару та одне - повідомити об'єкт про його удар. Вважайте, що об'єкт Boxer, ймовірно, потребуватиме відповіді на обидва . По-різному . Це дійсно вагомий привід дати їм різні імена.
Моя схильність полягала б у збереженні punch(boxer, object, strength)та перейменуванні протилежного методу punched. Ви можете назвати це handle_punchчи щось подібне, але тоді все ще неоднозначно, чи потрібно обробляти ударну команду чи повідомлення про її удар.
defendу цьому конкретному випадку). Але мішок для штампування ніколи не буде таким двостороннім. І вже є цей файл.close () ...
defendце команда. Це одна з можливих дій, яку об’єкт може вжити у відповідь punched, але ви не хочете, щоб інші об'єкти викликали defendбезпосередньо.
Ваш підхід врешті-решт призведе до дуже зв'язаного коду.
Якщо підсумувати Еріка Ліпперта, то в ідеалі тут ви хочете, щоб боксер міг пробити багато чого іншого. Якщо мішок для перфорації є підписом функції боксера, це означає, що боксер створений з негайним знанням Все (що є перфораційним). Плюс надання удару та отримання удару - це ДУЖЕ різні речі, тому вони не повинні мати одне й те саме ім’я.
Я б скоріше моделював це як боксер, який створює удар (інший об'єкт, що містить силу атрибута удару, досяжність, напрямок тощо).
Потім у мішок для штампування таким способом, як onPunch, який отримує цей ударний об'єкт, можна обчислити вплив удару на себе.
Пам'ятаючи про це, ім'я речей має велике значення. Він повинен відповідати ментальній моделі ситуації, яку ви маєте. Якщо ви намагаєтеся пояснити, як може статися щось, що не має сенсу з першого погляду, або якщо у вас є найскладніший час називати щось, то, можливо, ваша модель неправильна і її потрібно змінити.
Важко змінити модель після того, як ви почали, люди, як правило, схиляються до реальності відповідно до моделі. Проблема в цьому полягає в тому, що, коли ви згинаєте речі, щоб вони підходили (наприклад, мішок для штампування, який може пробивати речі), світ, який ви створюєте, стає все складнішим і взаємодії стають все складнішими. Ви зрештою досягнете точки, коли додавання навіть найнезначнішої речі стає кошмаром змін та помилок. Цей концептуальний технічний борг може мати дуже круту ціну, навіть якщо початкова вартість в той час сприймалася як найдешевша річ.
Це проблема, яку я називаю плутаниною "об'єкт / предмет", і вона досить поширена.
У реченнях зазвичай є суб'єкт, який виконує дієслово на їх цільовий об'єкт .
Що стосується програмування, то єдине, що насправді робить, це комп'ютер. Або практично процес, нитка або волокно. Об'єкти за замовчуванням не анімовані. У них немає власних потоків, тому вони нічого не можуть зробити.
Це означає, що методи діють на них, вони є ціллю дії, а не тим, хто робить дію. Ось чому ми називаємо їх «об’єктами», а не «предметами»!
Коли ви говорите File.close, що файл не закривається сам, це поточний запущений потік, який закриває файл. Якщо ви скажете Array.sort, поточний запущений потік сортує масив. Якщо ви скажете HttpServer.sendRequest, поточний запущений потік надсилає запит на сервер (а не навпаки!). Аналогічним чином PunchingBag.punchозначає, що поточна ходова нитка пробиває мішок.
Це означає, що якщо ви хочете Boxerмати можливість пробивати, то він повинен бути підкласом Threadтак, щоб він міг виконувати такі речі, як штампування мішків у своїй функції ниток.
Однак іноді також є сенс сказати, що штампуючий мішок пробиває себе у тому випадку, коли у кожного об’єкта є своя нитка, ви можете уникати перегонових умов і реалізовувати виклики методів як передачі повідомлення: ви пробиваєте сумку, відсилаючи їй punchповідомлення, це пробиває нитку. Тоді він сам надсилає вам punch successfulповідомлення, але це лише детальна інформація про реалізацію.
Я погоджуюся, що "удар" - це хороша назва методу для класу Boxer, оскільки (при певному налаштуванні) його можна було б повторно використовувати для інших об'єктів. Він також точно описує, що об’єкт класу робить дію на інший об’єкт. Хоча я б перейменував метод на "doPunch", щоб більш чітко продемонструвати співвідношення.
Для класу PunchingBag я вважаю, що назва методу є занадто розпливчастим або трохи неточним щодо того, що відбувається в методі. Коли я бачу "удар", я думаю, що щось пробиває щось інше. Однак тут об'єкт PunchingBag реагує на удар від об'єкта (в даному випадку об'єкта Boxer). Отже, я б перейменував тут метод на "isPunched", щоб проілюструвати, що об'єкт реагує на удар.
Хоча це моя інтерпретація того, як я би назвав методи. Це все питання смаку та яких стандартів ви дотримуєтесь.
хмммм. Я сумніваюся, як пробиваючи мішок, як клас, тому що ви не дуже піклуєтесь про мішок для штампування - ви дбаєте про вплив та силу кулака боксерів. тому методи повинні бути про те, що стосується вимірювання та повідомлення про вплив удару. навіть якщо це походить від «мішка для штампування», найменування все одно повинно виявити відповідальність - як punchImpactMeter тощо.