Прямо сейчас я второй раз читаю замечательную книгу Чистый код Роберта К. Мартина, также известного как дядя Боб, и думаю, Это хорошая идея - записывать самые важные идеи, которые он пытается донести до нас. Сегодня я сосредоточусь на десятой главе.
Нам нравится сохранять в секрете наши переменные и служебные функции, но мы не фанатичны по этому поводу. Иногда нам нужно сделать переменную или служебную функцию защищенной, чтобы к ней можно было получить доступ с помощью теста.
Для нас тестовое правило. Если тест в том же пакете должен вызвать функцию или получить доступ к переменной, мы сделаем его защищенным или областью действия пакета. Однако сначала мы поищем способ сохранить конфиденциальность. Ослабление инкапсуляции всегда является крайней мерой.
Классы должны быть небольшими!
Меньший размер - это главное правило, когда дело доходит до проектирования классов. Как и в случае с функциями, наш непосредственный вопрос всегда: «Насколько мал?»
С помощью функций мы измеряли размер путем подсчета физических линий. С классами мы используем другую меру. Мы считаем обязанности.
Название класса должно описывать, какие обязанности он выполняет. Фактически, присвоение имен, вероятно, является первым способом определения размера класса. Если мы не можем получить краткое имя для класса, вероятно, он слишком велик.
Чем неоднозначнее имя класса, тем больше вероятность, что у него слишком много обязанностей. Например, названия классов, включая ласковые слова, такие как Сервис или Менеджер или Супер, часто намекают на неудачную совокупность обязанностей.
Мы также должны уметь написать краткое описание класса примерно из 25 слов без использования слов «если», «и», «или» или «но».
Принцип единой ответственности
SRP утверждает, что у класса или модуля должна быть одна и только одна причина для изменения. Этот принцип дает нам как определение ответственности, так и рекомендации по размеру класса. У классов должна быть одна ответственность, одна причина для изменения (попытка определить обязанности часто помогает нам распознавать и создавать лучшие абстракции в нашем коде).
Мы хотим, чтобы наши системы состояли из множества маленьких классов, а не из нескольких больших. Каждый небольшой класс заключает в себе единоличную ответственность, имеет единственную причину для изменения и сотрудничает с несколькими другими для достижения желаемого поведения системы.
Сплоченность
Классы должны иметь небольшое количество переменных экземпляра. Каждый из методов класса должен управлять одной или несколькими из этих переменных. В общем, чем больше переменных обрабатывает метод, тем более связным он является со своим классом. Класс, в котором каждая переменная используется каждым методом, максимально сплочен.
В общем, создавать такие максимально сплоченные классы нецелесообразно и невозможно, с другой стороны, хотелось бы, чтобы сплоченность была высокой. Когда сплоченность высока, это означает, что методы и переменные класса взаимозависимы и держатся вместе как логическое целое.
Выводы
Изменится потребности, поэтому изменится код. В OO 101 мы узнали, что существуют конкретные классы, содержащие детали реализации, и абстрактные классы, которые представляют только концепции.
Класс клиента, зависящий от конкретных деталей, подвергается риску, когда эти детали меняются. Мы можем ввести интерфейсы и абстрактные классы, чтобы помочь изолировать влияние этих деталей.
Помните, что зависимости от конкретных деталей создают проблемы для тестирования нашей системы. Если система достаточно разделена для тестирования таким образом, она также станет более гибкой и будет способствовать большему повторному использованию.
