Это конец октября. Я закончил свой учебный курс по кодированию в The Firehose Project почти месяц назад и с тех пор почти не вел блог. Я был относительно занят своей работой на полную ставку и недавно начал работать разработчиком на полставки (моя первая работа в отрасли!). Это, плюс много путешествий в сентябре и октябре, означало, что я немного отложил личное обучение и ведение блога.

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

Я начну с некоторых основ объектно-ориентированного программирования.

В начале моего буткемпа я изучил некоторые основы ООП высокого уровня. В какой-то момент я прочитал статью-мнение о том, что attr_accessors в Rails — это зло, и не совсем понял, почему, не потратив много времени на тему ООП, вместо этого пил из Firehose, чтобы научиться создавать базовые приложения CRUD Rails.

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

Основы инкапсуляции

Идея инкапсуляции заключается в том, что состояние объекта (хранящееся в переменных экземпляра) приватно. Это означает, что вы не можете получить доступ к свойствам вне класса. Но что вообще означает «вне класса»? Это вопрос, который на какое-то время сбил меня с толку в моем понимании инкапсуляции. Вот пример:

В приведенном выше примере строка 11 вызовет ошибку (см. ниже), потому что «тип» не является методом в классе покемонов, а состояние ранга Чармандера не является общедоступным.

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

Методы общедоступного класса могут получить доступ к состоянию объекта или изменить его

Один из двух способов получить доступ к состоянию объекта или изменить его — использовать общедоступные методы класса. Следуя нашему примеру с покемонами, ниже приведены два метода (строки 13–15 и 19–21), которые позволяют пользователю просматривать статистику покемонов и обновлять уровень покемонов соответственно.

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

attr_accessor, attr_reader, attr_writer

Еще один способ сделать состояние объекта общедоступным — использовать «геттеры и сеттеры»: attr_reader, attr_writer и attr_accessor.

  • attr_reader позволяет просматривать заданные переменные экземпляра
  • attr_writer позволяет их обновлять.
  • attr_accessor — это просто комбинация обоих вышеперечисленных.

Помните вызов pokemon.type и получение этого сообщения об ошибке?

Если мы изменим код, чтобы он выглядел так, как показано ниже (обратите особое внимание на строку 3), pokemon.type больше не будет вызывать ошибок. Спасибо за это методу attr_accessor. По сути, это дало нам разрешение просматривать и обновлять состояние покемонов вне метода.

Как я упоминал выше, существуют мнения о том, хороши ли «геттеры и сеттеры», и я не буду здесь вдаваться в них.

Что дальше?

Я надеюсь, что этот пост был полезен для разъяснения очень высокоуровневых основ инкапсуляции! Я продолжу эту серию на тему покемонов, чтобы охватить больше принципов ООП — абстракции, наследования и полиморфизма — в ближайшее время!