Як ви підходите до дизайну класів в ООП?

Коли я намагаюся створити рішення OO, я, як правило, використовую моделювання CRC, в якому перераховую назви класів (іменники), що вони роблять (дієслова) та як вони співпрацюють з іншими класами.

Цей блог має нижче сказати про цей іменниково-дієслівний підхід

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

Моє запитання: чи існує краща методика моделювання для використання підходу ОО?

Справедливості, він додав до цього твердження "Забавку".

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

Якщо ви хочете спробувати тут невеликий виклик, перестаньте читати і спробуйте моделювати гру «Монополія», використовуючи англійську мову, а потім поверніться сюди.

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

Але як тільки ви почнете писати тести, ви зрозумієте, який об’єкт на сьогоднішній день є найважливішим у будь-якій грі: правила.

Пам’ятайте той маленький папірець, який ви прочитали один раз, коли ви вперше отримали гру і не спілкуєтесь знову, поки не виникне суперечка? Комп'ютеризована версія не працює таким чином. Кожна річ, яку намагається зробити гравець, комп'ютер проконсультується з правилами і побачить, чи їм це дозволяється чи ні.

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

І саме тому TDD настільки популярний для фактичного водіння дизайну. Оскільки це, як правило, швидко спрямовує ваш розумовий процес у потрібні місця:

Коли я думаю, що збираюся написати кілька тестів на свою гру «Монополія». Я можу переглянути свій набір і спробувати знайти предмети. Отже, у нас є ці шматки. Я напишу для них кілька тестів.

Можливо, у мене буде базовий клас MonopolyPiece, і кожен тип твору буде виходити з них. Почну з DogPiece. Перший тест ... ах. Насправді тут логіки немає. Так, кожен твір буде намальований по-різному, тому мені може знадобитися DogDrawer, але, поки я розгортаю гру, я просто хочу написати "D" на екрані. Я підправлю інтерфейс користувача наприкінці.

Давайте знайдемо деяку фактичну логіку для тестування. Таких будинків і готелів дуже багато, але тести на них не потрібні. Гроші, ні. Картки власності, немає. І так далі. Навіть дошка - це не що інше, як державна машина, вона не містить логіки.

Ви швидко знайдете, що у вас залишилися три речі. Картки шансу та спільноти, пара кісток та набір правил. Це будуть найважливіші частини для проектування та тестування.

Чи бачили ви це, коли ви пишете іменники та дієслова?

Насправді є чудовий приклад у «Швидких принципах та принципах принципів Роберта Мартіна», де вони намагаються скласти програму «Боулінг-карта» за допомогою TDD і знайти всілякі речі, які, на їх думку, були очевидними класами, з якими просто не варто займатися.

Я ніколи не знаходив таких методів для мене корисними. Насправді я виявив, що використання їх просто бентежить мене ще гірше. Перевірте кавоварку Роберта К. Мартіна , я також не думаю, що він використовує такий підхід.

Одне, що мене відразу турбує, - це рішення, до якого людина потрапляє у статті КПК, на яку ви посилаєтесь. Співпраця "Клієнт / Замовлення" - це не те, що я вважаю вартим, а не так, як написано. У цій моделі немає нічого цікавого про Замовника, який заслуговує статусу класу. Єдине, що цікаво бути «замовником» - це те, що є одне або більше замовлень, пов’язаних із цією Особою .

Модель коледжу також. Існує багато можливостей, які можуть і, ймовірно, повинні поділитися між студентом та професором. Крім того, що відбувається, коли у вас є професор, який відвідує заняття, як це дуже часто дозволено безкоштовно на кампусах коледжу?

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

Редагувати: Просто прочитайте половину другого блогу, і я повинен сказати, що я дуже з цим згоден. Мені доведеться прочитати решту і подивитися, що це пропонує в плані навчання.

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

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

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