Ранее я обсуждал
карты CRC и раскрыл
большой секрет, заключающийся в том, что важнейшая вещь о карте CRC заключается в том, что она заставляет вас явно подумать и записать ответственность вашего класса, и что способность определять намерения класса таким образом является критически важной для создания жизнеспособного имени. Я твердо верю, что четко определенная ответственность и доброе имя равносильны хорошему программному обеспечению, поэтому этот блог содержит несколько рекомендаций, которые могут оказаться полезными.
При определении ответственности класса главное правило — придерживаться принципа единой ответственности, как клея, и вы можете сделать это, придумав
одно краткое предложение, которое четко раскрывает намерения вашего объекта. Два предложения обычно подразумевают две обязанности, а три предложения подразумевают три обязанности и т.д. ‘,’ но ‘или’ или ‘. Это не так просто, как кажется, потому что английский язык — слабая и ненадежная сущность, поэтому иногда требуется несколько попыток.
В моих первых двух блогах этой серии «
Что такое имя и
классификация»Я упомянул плохо названный класс с именем: XMLDataProcessor, поэтому в качестве примера я попытаюсь исправить его имя, определив его ответственность.
Название XMLDataProcessor особо не раскрывает никаких намерений, и я ранее сказал, что есть несколько вопросов, которые мы могли бы задать этому классу. Например:
- Какие данные XML?
- Из какой ленты?
- Какая обработка это делает?
Теперь давайте предположим, что ответы …
- Какие данные XML? Пользовательский график из Twitter.
- Из какой ленты? Данные доступны с простого URL-адреса Twitter, который выглядит примерно так:
https://api.twitter.com/1/statuses/user_timeline.xml?include_entities=true&include_rts=true&screen_name=BentleyMotors&count=2
- Какая обработка это делает? Он читает данные XML и преобразует данные элементов <Time> и <Text> (которые являются твитами) в массив bean-компонентов.
Итак, подводя итог, мы можем в качестве первой попытки получить что-то вроде этого:
Этот класс отвечает за … чтение канала Twitter. Он разбирает XML. Он извлекает элементы <Text> и <Time> и преобразует результат в список простых bean-компонентов.
Обратите внимание на первую часть предложения «Этот класс отвечает за …». Это всегда хороший способ начать определять ответственность класса.
ОДНАКО , и это большой, однако, вопрос «Из какой подачи?» это поддельный вопрос. XMLDataProcessor не должен заботиться о том, из какого источника поступают данные, в противном случае мы действительно нарушили бы правило единой ответственности. Необходимо передать данные для
«обработки» в удобной форме, такой как поток. Это означает, что мы можем отбросить немного о фиде Twitter из нашего определения, хотя этот факт следует отметить, поскольку он действительно хороший указатель на дизайн коллабораторов XMLDataProcessor.
Кроме того, наша первая попытка определить ответственность нашего класса слишком многословна. Это три предложения, а третье содержит соединение «и». Так что попробую еще раз …
Этот класс отвечает за преобразование элементов <Text> и <Time> в Twitter XML в список bean-компонентов.
Это намного лучше, ответственность за объект была определена с помощью одного предложения и без каких-либо соединений (я все еще использовал слово ‘и’; однако, в этом случае это как разделитель списка).
Определив ответственность нашего класса, теперь мы можем придумать хорошее имя. Список кандидатов может включать: TweetConvertor, TweetXmlToBeanConvertor, TweetXmlToBeanParser или TweetXmlParser — я позволю вам выбрать своего любимого. Смысл этого в том, что назвать класс намного проще, если вы знаете, почему он существует и что он делает.
Чтобы повторить ключевой момент из моего последнего блога:
Идея постоянного пересмотра названия класса и сравнения его с его ответственностью является ключом к хорошему именованию объекта.
Последнее, что нужно сделать, это использовать
eclipse для переименования класса …
… кое-что, что некоторые разработчики немного сдерживают; однако, классы должны быть безжалостно переименованы. Это может вызвать небольшую путаницу, но в долгосрочной перспективе ваше программное обеспечение и проект будут намного лучше.
Подводя итог, я согласен, что названия большинства классов, которые вы напишете, будут довольно очевидными, и что большинство из нас пройдут через ментальные махинации выше, даже не задумываясь об этом. Тем не менее, будут случаи, когда название класса не совсем ясно, и лучший способ решить эту проблему — определить его ответственность с кристально ясной ясностью.