Три вещи, которые я узнал из книги Сэнди Мец как программист, не использующий Ruby
[из глав 1–4]
Я не профессиональный Ruby программист. Я даже не программист на Ruby. Я изучал кодирование в средней школе, и, будучи выпускником инженерного факультета, у меня было несколько классов программирования на C и ассемблере (для микроконтроллеров… давным-давно *). И я пишу код для развлечения. Я выучил Python (edX) и Octave (coursera) среди других языков. Я очень благодарен за то, что живу в эпоху Интернета и что есть люди, которые любезно дают каждому бесплатное образование мирового уровня.
Недавно я смотрел один из выступлений Санди Мец под названием Ничто не является чем-то. Это поразило меня. Она рассказала о своих догадках - как думать о коде, используя философию, ориентированную на сообщения. Цель состоит в том, чтобы упростить код, что сделает ваше приложение лучше и вашу жизнь. Я читал об Agile и немного практиковался в объектно-ориентированном программировании, но мой разум все еще был сильно запрограммирован, чтобы мыслить функциями и процедурами. Будучи программистом-любителем, у меня не было опыта в кошмарах обслуживания, но ее выступление заставило меня понять, что Agile может быть полезен и для меня. Написание кода с твердой философией дизайна также будет полезно для моих личных проектов (и моего рассудка!), Даже если я не программист по профессии. Научиться писать более простой и чистый код - это не только практический навык, но и философия мышления. Это полезно для структурирования мыслей и их четкого выражения.
Не имея никакого опыта работы с Ruby - ни единой строчки «привет, мир»!, я взял ее книгу и начал ее читать. Примерно через час чтения, к концу четвертой главы, я решил отложить книгу. Мне следует усвоить то, что я узнал, может быть, применить их по-своему. Я так рада, что решила прочитать эту книгу.
В следующих нескольких абзацах я напишу о ключевых концепциях, которые я изучил в первых четырех главах, - концепциях, которые больше всего нашли у меня отклик. Каждая глава содержит столько ценной информации, что я бы не стал их все обсуждать.
Читать книгу! Конечно, вам могут больше понравиться другие идеи, которые вы сочтете более важными, но я пишу о своем личном опыте чтения этой книги.
1. У КЛАССА ДОЛЖНА БЫТЬ ОДНА И ТОЛЬКО ОДНА РАБОТА.
Класс в максимально возможной степени должен делать наименьшее возможное полезное дело. У класса есть обязанности, которые выполняют свою задачу. Это важно, потому что приложения, которые легко изменить, состоят из классов, которые легко использовать повторно. Класс с различными обязанностями трудно использовать повторно. Это связано с тем, что, если вы хотите повторно использовать некоторые, но не все его поведение, почти всегда невозможно получить только то, что вам нужно. Наличие большего количества обязанностей означает, что класс также может быть связан с другим кодом. Это нехорошо по причинам, о которых я расскажу позже.
Классы, которые делают что-то одно, изолирующее это от остальной части вашего приложения, позволяют вносить изменения без последствий и повторно использовать без дублирования.
Есть несколько способов определить, несет ли класс единственную ответственность или он содержит поведение, принадлежащее какому-то другому. Один из способов - притвориться разумным и допросить его. Перефразируйте каждый из его методов в вопрос и определите, имеет ли смысл задавать такой вопрос. Как описано в книге, например, «Пожалуйста, мистер Гир, каково ваше соотношение?» кажется разумным, в то время как «Пожалуйста, мистер Гир, какое у вас расстояние?» , похоже, стоит на шаткой почве, и «Пожалуйста, мистер Гир, какой у вас размер шин?» просто смешно.
Другой способ - попытаться описать этот класс одним предложением. Если он отвечает только за одну вещь, то его должно быть просто описать. Если в нем используются слова «и» или «или», вы, скорее всего, не пройдете этот тест. Класс очень сплочен, когда все внутри него связано с его главной целью.
2. КЛАСС ДОЛЖЕН ЗНАТЬ ДОСТАТОЧНО ДЛЯ СВОЕЙ РАБОТЫ И НИЧЕГО БОЛЬШЕ.
ТАКЖЕ, ЗАВИСИТЕ ОТ ВЕЩЕЙ, МЕНЯЮЩИХСЯ МЕНЬШЕ, ЧЕМ ВАС.
Взаимодействие между объектами неизбежно. Один объект не знает всего, поэтому он должен разговаривать с другими. Поскольку мы разработали объекты с отдельными обязанностями, каждый объект взаимодействует друг с другом для выполнения более сложных задач. Чтобы работать друг с другом, объекты должны знать кое-что о других. Однако знание создает зависимости. Объект зависит от другого, если всякий раз, когда один объект изменяется, другой может быть вынужден измениться вместе с ним. Чем больше у объектов зависимостей или чем больше они знают друг друга, тем сложнее изменить класс, не затрагивая другие классы. Также сложнее предсказать поведение приложения.
Есть много способов распознать зависимости. Объект является зависимым, если:
- Он знает имя другого класса и ожидает его существования.
- Он знает имя сообщения (функции), которое он намеревается отправить кому-то другому, кроме себя (и / или аргументы этого сообщения, и / или порядок этих аргументов)
Конечно, мы не можем помочь, но у нас есть некоторая степень зависимости, но многое, вероятно, не нужно. Существуют методы минимизации зависимостей, при которых класс должен знать достаточно, чтобы выполнять свою работу, а не что-то еще. Есть несколько способов минимизировать зависимости и кодировать таким образом, чтобы объекты могли быстро адаптироваться к неожиданным изменениям. Ниже обсуждаются некоторые из них, которые, на мой взгляд, являются наиболее важными.
Внедрение зависимостей может означать перемещение создания экземпляра класса B, с которым класс A взаимодействует, за пределы класса. Таким образом, класс A знает только, что он содержит класс, который отвечает на определенное сообщение M. Классу A не важно, содержит ли он экземпляр класса B, C или D, только то, что этот экземпляр отвечает на определенное сообщение M. Просто поскольку класс знает, что ему нужно отправить сообщение M экземпляру, это не означает, что ему нужно знать, что это за класс.
Изоляция зависимостей может означать создание экземпляра класса B на основе его собственного явно определенного метода внутри класса A. Он может создавать этот экземпляр лениво, когда ему нужно сделать что-то, что требует взаимодействия с ним.
Вы также можете изолировать уязвимые внешние сообщения (сообщение, отправленное кому-то, кроме себя). Определите методы внутри класса A, которые взаимодействуют исключительно с сообщениями другим классам, и вызывают этот метод вместо отправки внешних сообщений внутри метода с другой целью.
Вы также можете изменить направление зависимости, сделав B зависимым от A, а не A зависимым от B. с большей вероятностью изменится.
3. СПРОСИТЕ «ЧТО» ВМЕСТО СКАЗАТЬ «КАК».
ОБЪЕКТЫ ДОЛЖНЫ ДОЛЖНЫ БЫТЬ ДОЛЖНЫ ДОВЕРИТЬСЯ. ОБЪЕКТЫ ДОЛЖНЫ БЫТЬ СПОСОБНЫ ДЛЯ СОТРУДНИЧЕСТВА С ДРУГИМИ, НЕ ЗНАЯ, КТО ОНИ И ЧТО ОНИ ДЕЛАЮТ.
В четвертой главе Сэнди Мец подчеркивает, что, хотя приложение состоит из классов, для создания кода, который легко изменять и поддерживать, мы должны больше заботиться о том, как объекты взаимодействуют друг с другом (дизайн, ориентированный на сообщения). Это проявляется в моделях общения. Лучше приложение, в котором шаблоны сообщений явно ограничены (как показано справа). Для этого мы классифицируем методы в классе на два: общедоступные и частные. Публичные методы должны раскрывать свою основную ответственность и должны быть вызваны другими. Таким образом, они не должны меняться по собственной прихоти, что позволяет другим безопасно зависеть. С другой стороны, частные методы обрабатывают детали реализации и, как таковые, не должны использоваться другими объектами. Сэнди Мец продолжает давать нам много хороших советов о том, как найти и определить эти методы, включая использование диаграмм последовательности (Unified Modeling Language Diagrams).
Один из ключевых моментов, который мне нравится в этой главе, заключается в том, что объекты должны взаимодействовать друг с другом на основе доверия. Если мы называем то, что объекты знают друг о друге, «контекстом», тогда мы должны стремиться к независимости от контекста, поскольку это только делает объекты более запутанными друг с другом. Объект должен иметь возможность сотрудничать с другими, не зная, кто они и что делают. Объекты должны спрашивать «что» вместо того, чтобы говорить «как».
Приведенный ею пример интересен. Поездка вот-вот отправится, и необходимо убедиться, что все велосипеды, которые планируется использовать, находятся в исправном состоянии. Для этого объект TRIP может взаимодействовать с объектом MECHANIC.
Три диаграммы (из книги) ниже изображают три возможных способа взаимодействия Trip и Mechanic в порядке увеличения «объектно-ориентированности».
На первой диаграмме Поездка говорит Механику «Я знаю, что хочу, и я знаю, как вы это делаете». Во втором: «Я знаю, что хочу, и я знаю, что вы делаете». На последней диаграмме «Я знаю, чего хочу, и верю, что вы сделаете свой вклад».
Это слепое доверие к последней диаграмме позволяет объектам сотрудничать, не привязывая себя к контексту.
