Как объяснить концепции объектно-ориентированного программирования 6-летнему ребенку

1656589575 kak obyasnit konczepczii obektno orientirovannogo programmirovaniya 6 letnemu rebenku

Александр Петков

Замечали ли вы, как на собеседовании всегда задают одни и те же штампованные вопросы снова и снова?

Я уверен, что вы понимаете, что я имею в виду.

Например:

Где ты видишь себя пять лет спустя?

или, еще хуже:

Что вы считаете своей величайшей слабостью?

Уф… дай мне перерыв. Я считаю ответ на этот вопрос большой слабостью! Во всяком случае, не моя точка зрения.

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

Отвечая, будьте осторожны, поскольку вы можете раскрыть то, о чем потом пожалеете.

Сегодня я хочу поговорить о подобном вопросе в мире программирования:

Какие основные принципы объектно-ориентированного программирования?

Я был с обеих сторон этого вопроса. Это одна из тем, которые задают так часто, что вы не можете позволить себе не знать.

На него обычно приходится отвечать младшим и начальным разработчикам. Потому что интервьюер легко может сказать три вещи:

  1. Готовился ли кандидат к этому собеседованию?
    Бонусные баллы, если вы сразу услышите ответ, это свидетельствует о серьезном подходе.
  2. Прошел ли кандидат этап обучения?
    Понимание принципов объектно-ориентированного программирования (ООП) показывает, что вы вышли за рамки копирования и вставки из учебного пособия – вы уже видите вещи с более высокой точки зрения.
  3. Понимание кандидата глубоко или поверхностно?
    Уровень компетентности по этому вопросу часто равен уровню компетентности на большинство других предметов. Доверься мне.
9mzHbZ-kiW9wJnVKRlhZqPotx9diwe0omWXX
Как выглядит разработчик исходного уровня после решения этого вопроса!

Четыре принципа объектно-ориентированного программирования инкапсуляция, абстракция, наследование, и полиморфизм.

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

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

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

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

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

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

Скажем, мы создаем крошечную игру Sims. Есть люди, а есть кот. Они общаются друг с другом. Мы хотим применить инкапсуляцию, поэтому мы инкапсулируем всю «кошачью» логику в a Cat класс. Это может выглядеть так:

M4t8zW9U71xeKSlzT2o8WO47mdzrWkNa4rWv
Можно кормить кота. Но вы не можете напрямую изменить, насколько голодна кошка.

Здесь «состояние» кота частные переменные mood, hungry и energy. Он также имеет частный метод meow(). Он может называть его, когда захочет, другие классы не могут указать кошке, когда мяукать.

Что они могут делать, определено в публичные методы sleep(), play() и feed(). Каждый из них как-то изменяет внутреннее состояние и может вызвать meow(). Таким образом осуществляется связь частных государственных и публичных методов.

Это инкапсуляция.

Абстракция

Абстракцию можно рассматривать как естественное расширение инкапсуляции.

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

Абстракция – это концепция, направленная на облегчение этой проблемы.

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

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

Подумайте – кофеварка. Он делает многое и издает странные звуки под капотом. Но все, что вам нужно сделать это добавить кофе и нажать кнопку.

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

Еще один пример абстракции из реальной жизни?
Подумайте, как вы используете свой телефон:

hiX0NQOcZFShroq-a3FM5pFP2LV4UUI5mLle
Мобильные телефоны сложны. Но пользоваться ими просто.

Вы взаимодействуете со своим телефоном, используя всего несколько кнопок. Что происходит под капотом? Вам не нужно знать – детали реализации скрыты. Нужно знать краткий набор действий.

Изменения внедрения – например, обновление программного обеспечения – редко влияют на абстракцию, которую вы используете.

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

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

Но знаете ли вы, какая еще одна проблема в дизайне ООП?

Объекты часто очень схожи. Их разделяет общая логика. Но они не есть полностью так же. тьфу…

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

Это означает, что вы создаете (дочерний) класс путем производного от другого (родительского) класса. Таким образом, мы формируем иерархию.

Дочерний класс повторно употребляет все поля и способы родительского класса (общая часть) и может воплотить свои собственные (неповторимая часть).

Например:

ZIm7lFjlrKeMWxcH8fqBapNkuSJIxW9-t9yf
Частный учитель – это тип учителя. Любой учитель – это тип Человека.

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

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

Полиморфизм

Мы перешли к самому сложному слову! Полиморфизм на греческом означает «много форм».

Итак, мы уже знаем силу наследования и с радостью им пользуемся. Но возникает проблема.

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

Это можно решить с помощью полиморфизма.

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

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

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

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

8GySv1U8Kh9nVVyiTqv5cDuWZC7p0uARVeF0
Треугольник, круг и прямоугольник теперь можно использовать в одной коллекции

Имея эти три фигуры по наследству от родителей Figure Interface позволяет создать список смешанных triangles, circlesи rectangles. И относиться к ним как к однотипным объектам.

Затем, если этот список пытается вычислить поверхность элемента, будет найден и выполнен правильный метод. Если элемент треугольник, треугольник CalculateSurface() это называется. Если этот круг — то круг CalculateSurface() это называется. И так дальше.

Если у вас есть функция, оперирующая фигурой, используя ее параметр, вам не нужно определять ее трижды – один раз для треугольника, круга и прямоугольника.

Вы можете определить его один раз и принять a Figure как аргумент. Независимо от того, передаете ли вы треугольник, круг или прямоугольник — пока они реализуются CalculateParamter()их тип не имеет значения.

Надеюсь, это помогло. Вы можете непосредственно использовать эти же объяснения на собеседовании.

Если вам что-то еще трудно понять, не стесняйтесь спрашивать в комментариях ниже.

Что дальше?

Быть готовым ответить на один из классических вопросов интервью – это отлично, но иногда вас никогда не вызывают на собеседование.

Далее я остановлюсь на том, что работодатели хотят видеть в младшем разработчике и как выделиться из толпы при поиске работы.

Следите за обновлениями.

PWiBgy57Ye32At-VBM3qIcWdVJQ01Td-ILKl
Вам понравилось прочитанное? Если хочешь поддержать меня, можешь купить кофе 🙂

Добавить комментарий

Ваш адрес email не будет опубликован.