Как разработать дизайн с использованием CRC-карт?
=================================================

Мне всегда было интересно, как люди используют карты CRC (class responsiblity collaboration). Я читал о них в книгах, нашел неясную информацию в Интернете, но так и не понял. Я думаю, что кто-то должен сделать видео с YouTube, показывающее сеанс с картами CRC, так как одна из моих книг описала это как очень сложную формулировку в тексте, что ее следует "обучать тому, кто ее уже овладевает". К сожалению, я не знаю никого, кто использует CRC-карты, и я хотел бы узнать больше.

 UPDATE
-------

Любые ссылки на видеоролики, показывающие людей, разрабатывающих эту технику, будут оценены.

 

Я постараюсь дать ответ.
Таким образом, карты CRC обычно используются для моделирования в объектно-ориентированной среде, чтобы лучше понять систему, которая должна быть разработана (но я думаю, что вы уже знаете).
Карты CRC приходят в самом конце, когда вы приедете непосредственно перед фактической реализацией. Различные шаги для достижения этого уровня могут быть следующими:

* Отправной точкой является выполнение требования. Привлечение клиента рано и постоянно предлагается здесь (взгляните на подходы Agile, то есть на экстремальное программирование).
* Затем требования могут быть смоделированы либо с использованием диаграмм Use Case (UML), либо с рассказами пользователей (гибкий подход к экстремальному программированию). Ключевая проблема здесь заключается в том, чтобы найти нужные объекты. Конечно, это зависит от того, в каком домене вы находитесь. Если вы перейдете к "жесткому" пути, вы можете применить такие методы, как "извлечение существительного". Таким образом, вы анализируете документ спецификации и извлекаете все существительные (включая составные имена и имена с прилагательными). Проанализируйте их все и отбросьте нерелевантные.
* Как только у вас есть правильные существительные → объекты, вы можете начать создавать свои CRC-карты. Итак, что сделано на сессии CRC? Основная задача - найти и назначить обязанности ваших (ранее) найденных объектов, которые затем помещаются на небольшие карточные карты (наши карты CRC). "Обязанности" - это главным образом основные функции конкретного объекта, а часть "сотрудничества" - это необходимые другие объекты для выполнения определенных функций (это зависимости между различными объектами в вашей модели). Важные моменты для определения обязанностей - это то, что обязанности распределяются хорошо на всей системе каким-то сбалансированным образом. Еще один очень важный момент - избегать дублирования ответственности между объектами (это помогает картам CRC).   
 Сессия CRC должна начинаться с встречи" мозгового штурма", активно обсуждаемой среди разработчиков, и ее следует выполнять непосредственно на фактических карточках.

Надеюсь, я смог как-то помочь вам.

С уважением,   

Juri

 

Трудно суммировать в ответе SO, но я попробую. Одной из задач проектирования объектов является балансирование мышления с общей точки зрения с мышлением с точки зрения отдельного объекта. Вам нужна общая перспектива, чтобы завершить вычисление, но вам нужна индивидуальная перспектива для эффективного разделения логики и данных.

Поддержание этого баланса - это когда появляются карты CRC. Когда они сидят на столе, вы можете посмотреть на вычисления в целом. Однако, когда вы берете одну карту, вы физически, кинестетически поощряетесь взглянуть на этот объект - у меня есть эта небольшая часть этого вычисления, чтобы ограничить ресурсы, как я ее выполню?

Со временем способность одновременно удерживать обе перспективы, кажется, впитывается в мозг. Все меньше и меньше записывается на карточках. Затем карты пустые. Через некоторое время люди просто указывают, где будет карта, если они будут беспокоиться о том, чтобы взять пустую с стека. В конце концов, люди имеют преимущества стиля мышления, не требуя карточек. При разговоре с кем-то, кто не справился с балансом, вытаскивание карт с картами может быть полезной коммуникационной помощью.

Самая большая слабость, которую я нахожу в карточках, - отсутствие обратной связи. Вы можете одурачить себя тем, как будет выглядеть код. Я предлагаю использовать карты только до тех пор, пока не появится интересный вопрос, перейдите к тестам/коду для подтверждения, а затем возобновите проектирование.

Уорд и я сделали видеоролик примерно 15 лет назад о сессии дизайна, но я не нашел его в Интернете нигде, и у меня нет копии. Я не уверен, что это было бы полезно в качестве инструмента обучения в любом случае. Я не знаю других видеороликов, но они могут быть интересными, особенно если вам нужно сравнить несколько разных стилей дизайнера.

 

перейдите в [источник](http://c2.com/doc/oopsla89/paper.html) - Кент Бек, Уорд Каннингем, когда-либо слышали о них?

 

Я думаю, что ваше выражение "Я не знаю никого, кто использует CRC-карты", в значительной степени подводит итог состоянию CRC-карт в разработке. Карты CRC, на мой взгляд, были шагом на пути от традиционного, ориентированного на планирование развития до гибкого развития. Мир двинулся дальше. Вместо того, чтобы сосредоточиться на использовании карт CRC, я бы исследовал такие методы, как [TDD](https://en.wikipedia.org/wiki/Test-driven_development), которые могут использовать такие методы, как UML и CRC-карты, как промежуточные артефактов, но которые концентрируются на коде, и, более конкретно, на тестах. Это направление, которое изобретатели карт CRC взяли, и я бы рекомендовал вам также принять.

 

Самый простой способ использовать их по моему мнению, не впадая в беспорядок, - записать небольшие CRC-карты в заголовки файлов следующим образом:

```
///////////////////////
//* CRC CARD
//*  Class: UISliderEvent
//*  Responsability: Event that holds the value and id of a Slider movement
//*  Collaborators: UISlider, UIEvent
//////////////////////

```

Затем каждый раз, когда вам нужно добавить функцию, проверьте свою карточку и убедитесь, что вы не нарушаете никаких контрактов, которые вы указали в ней. Например, внезапно, в зависимости от UIMouseEvent, например, что нигде на Карте, поэтому его нет-нет, чтобы включить его.

 

В своей книге [Object Design: роли, обязанности и сотрудничество](http://books.google.co.uk/books?id=vUF72vN5MY8C&lpg=PP1&dq=inauthor%3ARebecca%20inauthor%3AWirfs%20inauthor%3ABrock&pg=PA61#v=onepage&q=&f=false), опубликованные в 2003 году [Ребекка Вирфс-Брок](http://wirfs-brock.com/) и Алан МакКин обсуждают CRC-карты в деталях. Они действительно подчеркивают разницу, которую он делает для всей процедуры, что это должно быть очень осязаемым опытом, и это ослабляет людей, которые думают, что они проходят вокруг физического объекта, пытаясь выработать дизайн/требование.

Подзаголовок этой главы предполагает, что использование карт является частью фазы "исследовательского проекта", поэтому, вероятно, это происходит до того, как сделать много кодировок, но я не вижу причин, по которым вы не будете возвращаться к ним в каждая итерация Agile-проекта и напоминание о себе, где вы думали, что собираетесь идти и пересматриваете это, если это необходимо (как группа, конечно).

Кажется, я помню, что они даже предлагают пропустить мяч вокруг комнаты, так что только человек, у которого есть мяч, может говорить, поэтому, возможно, это не так много карт CRC, как заставить всех в комнате говорить о ролях и ответственность объектов, которые имеют значение?

Если вы хотите прочитать практическое исследование CRC-карт в действии (в дополнение к оригинальной бумаге Кента и Уорда, конечно), посмотрите [Карточка CRC-карты](http://books.google.co.uk/books?id=SGOyQai2TboC&lpg=PP1&pg=PA73#v=onepage&q=&f=false).