Как и было обещано в моей последней статье, это будет серия, призванная помочь людям пройти путь от нуля до героев в разработке iOS.

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

Когда я начал писать этот сериал, у меня тогда еще не было целевой аудитории. Когда я начал это планировать, я понял, что есть набор навыков и базовые знания, которыми в целом должен обладать каждый, кто начинает свой путь в качестве разработчика.

Примечание

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

Вождение автомобиля и объектно-ориентированное программирование

Я знаю, что сравнивать машины с программированием довольно странно, но выслушай меня, прежде чем поджечь мне волосы.

Абстракция

Итак, первая концепция ООП - это абстракция. В английском словаре «абстракция означает работу с идеями, а не с событиями». Конкретное событие может иметь несколько деталей и других обстоятельств, влияющих на окружающую среду, которые в конечном итоге привели к этому событию, в то время как идея - это скорее теория того, как некоторые события соотносятся с их аналогичными аналогами.

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

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

Полиморфизм

Вторую концепцию ООП может быть немного сложно понять, но я постараюсь сделать ее как можно проще. На английском языке полиморфизм означает «состояние, которое встречается в нескольких различных формах».

В мире автомобилей автомобиль может использовать бензин или дизельное топливо или даже природный газ в качестве топлива. Конечно, нужно внести несколько изменений в двигатель, чтобы он мог с этим справиться. это означает, что он должен «полиморфизировать» среду горения в желаемое состояние, чтобы работать с различными типами топлива.

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

Инкапсуляция

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

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

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

Наследование

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

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

Когда создается экземпляр класса, все доступные свойства этого класса могут быть легко доступны через созданный экземпляр. Например, при быстром создании переменной типа String она автоматически получает доступ к методу uppercased (), который специфичен для String класс.

Наследование также включает любые расширения, определенные для класса. Например, я всегда использую небольшую функцию под названием toDouble (), которую я сделал для преобразования String в Double, если она удовлетворяет некоторым условиям. когда String используется в модуле, который имеет эту функцию расширения, он автоматически получает к ней доступ.

Резюме ООП

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

Чистый код и техническое обслуживание автомобиля

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

Очистка моторного отсека помогает обнаружить потенциальные проблемы с самого начала. Например, скопившаяся смазка скроет потенциальную проблему утечки масла. Эта утечка масла может повредить все ремни в двигателе, если они будут оставаться рядом с маслом слишком долго. Скопившаяся пыль забьет воздушный фильтр, и его, возможно, придется менять чаще. Если воздушный фильтр не был заменен или очищен должным образом, пыль и другие мелкие частицы попадут в цилиндры, где они сгорят, а их прах покроется липким маслом. Эти покрытые маслом частицы затем будут прилипать к поршням или стенкам цилиндра, что, в свою очередь, сокращает ожидаемый срок службы двигателя.

У всех этих проблем была одна первопричина - не чистка моторного отсека.

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

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

Отступ

Современные IDE или текстовые редакторы достаточно умны, чтобы понимать, что вы используете их для написания фрагмента кода. Раньше (изо всех сил старались не звучать здесь как дедушка) отступы приходилось делать вручную.

Обычно люди использовали кнопку Tab на клавиатуре, но даже тогда этого было недостаточно. Некоторым людям нравилось использовать большее пространство, когда они заходили глубже. Другим нравилось использовать фиксированное пространство, независимо от того, на каком уровне они находятся, и даже на этом проблемы не закончились. Некоторым нравилось использовать 4 пробелов, а другим нравилось использовать 8 пробелов. Этот спор так и не был разрешен, и я сомневаюсь, что он когда-нибудь разрешится, но была достигнута договоренность о том, что все, что вы используете, следует придерживаться на протяжении всего вашего проекта.

Ниже приведен пример кода с неправильным отступом.

Вот тот же код, но с правильным отступом.

Теперь я считаю, что, будучи молодым разработчиком, вы понимаете, насколько важно использовать правильные и последовательные отступы. Я знаю, что код с плохим отступом может выглядеть «красивее», но он не так удобочитаем, как код с правильным отступом. Причина его удобочитаемости - постоянный отступ.

Именование

Именование лежит в основе хорошего чистого кода. Я никогда не смогу это подчеркнуть, но хороший разработчик называет свои переменные так, как если бы они называли своих детей. При именовании переменных следует соблюдать несколько правил соглашения:
1. Описательные имена
2. Отсутствие избыточности
3. Случаи верблюда

Описательные имена

Когда вы разрабатываете свой код, вы знаете, о чем думаете, знаете, что делает каждая переменная, и знаете, как все взаимосвязано. Давайте перенесемся на пару дней вперед и посмотрим, как все будет читаться. Абсолютная чушь. Следующий пример ясно показывает, почему важны описательные имена.

Глядя на приведенные выше имена, можно легко догадаться, что означают первая и вторая переменные. Вариант cusnam можно угадать как имя клиента, поскольку это строка, имеющая некоторое сходство. Вторую переменную cusage можно угадать, используя ту же методологию. Теперь, глядя на третью переменную, почти невозможно угадать, что это такое, если у вас нет хороших дедуктивных навыков. Это должно было означать пол клиента. Готов поспорить, вы никогда этого не ожидали.

Как разработчик вы пишете код для решения проблемы. Вы пишете это не для того, чтобы проверить умение дедукции другого разработчика. Ниже приведен пример того, как имя переменной может быть описательным.

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

Без избыточности

Глядя на наш пример ненужных сокращений, мы могли ясно видеть, что использование customer в наших именах переменных привело к ощущению повторения. Мы уже знаем, что этот класс называется клиент, тогда зачем мне говорить, что это имя клиента, а это его возраст и т. Д.? Это в основном то, что означает быть избыточным. Усовершенствованную версию класса Customer можно найти ниже.

Случай верблюда

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

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

Существует два типа регистров верблюда:
1. UpperCamelCase
2. lowerCamelCase
Основное отличие состоит в том, что первая буква в потоке слов может быть или не быть заглавной. UpperCamelCase традиционно зарезервирован для имен классов, в то время как lowerCamelCase зарезервирован для имен методов и переменных.

Ниже приведен пример, не относящийся к случаям с верблюдами.

А вот тот же пример, но на этот раз мы рассмотрим подходящие случаи с верблюдами.

Подводить итоги

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

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

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

Спасибо всем и не забудьте подписаться на меня в LinkedIn и Twitter, чтобы я был в курсе следующих новостей.

Изменить: не удалось правильно встроить суть github, поэтому на этот раз я отредактировал ее правильно.

Edit: Следующая статья вышла.