Написание лучших приложений на машинописном тексте
Предисловие
Найти нового разработчика, которому пожилые люди могут с уверенностью доверить передачу части своего кода, - непростая задача. Почему? Потому что найти нового разработчика, который действительно может написать отличное программное обеспечение, может быть почти таким же обычным делом, как найти четырехлистный клевер - составленный статистикой в моей голове, ха-ха. Было ли это последнее утверждение полностью сфабриковано или нет, обсуждается в разделе комментариев ниже, но если вы новый разработчик и хотите писать отличное программное обеспечение, добро пожаловать в первую часть моего блога. серия о том, как лучше писать приложения на Typescript.
Как читать
Эта серия блогов представляет собой серию статей, читаемых по порядку. Моя цель - сделать это составным источником чтения, где, надеюсь, мы обсудили любую предварительную информацию в предыдущей статье, чтобы мы могли начать добавлять эти различные инструменты в наш набор инструментов, когда мы начнем исправлять наш существующий код основывается на одной статье за раз.
Моя мотивация, стоящая за этой серией
Что побудило меня начать серию статей об объектно-ориентированном машинописном тексте, так это то, что я учился на собственном опыте, и мне потребовались годы, чтобы наконец по-настоящему понять. Я пришел к выводу, что быть инженером-программистом - это гораздо больше, чем просто программист на выходных, наблюдатель за учебными пособиями и последователь курса. Но быть настоящим инженером означает уметь находить решение проблемы и структурировать структуру, в которой это решение будет решено. А хорошее понимание принципов ООП сделает вас еще на один шаг ближе к тому, чтобы стать тем великим инженером, которым вы надеетесь стать.
Чему вы можете ожидать научиться
После прочтения этой статьи вы можете поспорить, что поразите всех своих друзей по CS Grad своими новыми знаниями о том, что именно такое инкапсуляция, как ее правильно использовать и почему она должна быть больше не вариантом, а требованием ВЕЗДЕ в коде :)
Инкапсуляция - очень простая концепция; это процесс обеспечения точной защиты определенных данных (свойств), передаваемых между вашим приложением.
И это честно! Очень простая, но очень действенная концепция, о которой следует помнить при программировании. С учетом сказанного, давайте перейдем к исходному коду и посмотрим, как это применимо в реальном мире.
Довольно простой пример
В этом блоге, чтобы быстро разобраться в этой теме, мы собираемся реализовать базовый класс Bank Member только со сберегательным счетом.
Для начала у нас есть класс BankMember, который принимает начальный баланс сберегательного счета и несколько методов: один для внесения средств, а другой - для снятия средств. Все очень просто, правда?
Давайте вместе с нашим старым добрым другом Чаком перейдем к файлу index.ts и посмотрим, как все это складывается воедино.
Здесь наш друг Чак открывает у нас счет и начинает с очень щедрых 3000 долларов наличными. И он уже хочет внести еще. Давайте посмотрим на этот сценарий в действии.
Прохладный! Работает по плану. А как насчет вывода?
Идеально! Это было супер быстро и легко. Мы можем создавать новых участников банка, вносить и снимать. Мы уже можем пойти дальше и отправить наш код нашему банковскому клиенту!
Или мы можем…?
На первый взгляд кажется, что наш код работает отлично. Здесь не нужны модульные тесты;) Но что, если наш клиент неправильно использует наш исходный код? Или, что еще хуже, что, если наш клиент откроет свое приложение для использования в других сторонних приложениях, и они злонамеренно изменят баланс счетов. Взгляните ниже.
Вы видите ошибку, которую мы, как разработчики, косвенно внедрили в исходный код? Мы не обеспечиваем никакой защиты данных, представленных в нашем классе, поэтому любой, у кого есть доступ к экземпляру BankMember, может свободно изменять значение этого члена saveBalance.
В приведенном выше примере Чак вполне мог вывести 1650 долларов, потому что у него только что был остаток в 3150 долларов. Но без его ведома, банковское приложение, которое он использует для управления своими финансами, принадлежит мошеннической компании, которая ворует у всех своих пользователей. Итак, давайте посмотрим, как мы можем стать лучшими разработчиками и использовать инкапсуляцию, чтобы решить эту проблему всего несколькими строками кода!
Частные, защищенные, геттеры и сеттеры
Ключом к инкапсуляции является понимание того, как управление доступом к членам в сочетании с методами getter и setter может быть использовано в ваших интересах.
Частные: к закрытым членам можно получить доступ только в пределах того класса, в котором они были определены. Внешние клиенты, а также наследующие классы неавторизованы.
Защищено: к защищенным членам можно получить доступ только в пределах класса, в котором они были определены, а также наследующих суперкласс. Посторонние клиенты не авторизованы.
Получатели: это особый тип метода, единственная цель которого - предоставить косвенный доступ для чтения к клиентскому коду частному или защищенному члену, использование которого им запрещено. Доступные только для чтения свойства становятся возможными при использовании без его аналога setter.
Сеттеры: это особый тип метода, единственная цель которого - предоставить непрямой доступ на запись к клиентскому коду частному или защищенному члену, использование которого им иным образом запрещено. Доступные только для записи свойства становятся возможными при использовании без его аналога getter.
Готовы еще немного кода? Давайте посмотрим, как применить этот жаргон.
Кто-нибудь сказал, что ошибка бесплатна?
Теперь, когда мы видим недостатки отсутствия инкапсуляции нашего кода и знаем основные принципы реализации инкапсуляции, давайте перевернем хмурый взгляд Чака) :(
Реализация инкапсуляции
Вы видите изменения? Мы сделали наше свойство _savingsBalance закрытым и добавили к нему подчеркивание, чтобы обозначить его частный тип доступа. (общепринятое соглашение). Затем, что наиболее важно, мы создали общедоступный метод получения, который наши внешние клиенты могут использовать для использования в своих приложениях. Взгляните на наш новый файл index.ts, в котором происходило все это безумие.
Посмотрите, насколько умен машинописный текст, чтобы уловить тот факт, что свойство saveBalance доступно только для чтения? Вы также заметили, насколько хорош машинописный текст для выдачи ошибки до времени компиляции? Думаю, они не хотели бы, чтобы мошенническая банковская компания тратила свое время на компиляцию кода, который не работал бы, а? : /
Краткое примечание о геттерах и сеттерах в машинописном тексте
В отличие от некоторых других языков, хотя мы определяем геттеры и сеттеры как методы в нашем классе, мы не используем На самом деле они используются как методы вне класса, а просто как обычные свойства класса. Это отличная вещь, которую делает для нас машинописный текст, потому что мы используем ключевые слова get и set, прежде чем определять метод. Подробнее об этом читайте по ссылке ниже.
На сеттерах
Итак, в этом примере нет необходимости иметь сеттер, потому что у нас нет свойства, которое было бы полезно для наших клиентов, чтобы иметь доступ для записи. Но в этом случае давайте продолжим и снова включим возможность записи в наше свойство saveBalance.
Просто и легко, мы создаем метод set, который принимает переменную того же типа, что и свойство, которое мы устанавливаем, и сбрасываем свойство. Взглянем.
Мы больше не получаем ошибку "только чтение", и мы на этом закончили! (Просто не забудьте удалить ненужный метод установки)
Выход
Как мы только что видели, инкапсуляция данных, содержащихся в классах, которые мы пишем, больше не должна быть «только здесь»; Инкапсуляция - это принцип объектно-ориентированного программирования, который следует использовать в каждом учебном курсе, который вы пишете, с сегодняшнего дня до того дня, когда вы уйдете на пенсию в качестве разработчика. Инкапсуляция обеспечивает важный уровень защиты наших бесценных данных и дает нам дополнительную уверенность в том, что мы хорошо выспимся и не будем беспокоиться о мошеннических банковских компаниях, с которыми, к сожалению, столкнулся Чак.
Благодарим за чтение. Следите за моей следующей статьей, в которой будет обсуждаться следующий принцип ООП в нашем списке, Абстракция!
