C++ был первым объектно-ориентированным языком программирования. Он был создан путем смешивания C с Simula, который был изобретен Аланом Кеем. В этой статье я поделюсь некоторыми полезными принципами, которым меня научили при написании программ ООП.
- Используйте наследование для совместного использования поведения
- Создавайте глубокие иерархии наследования
- Предоставьте геттер для каждого частного участника
- Изменчивое состояние – ваш друг
- Класс должен быть чем-то, к чему вы можете прикоснуться
- Вы можете прикоснуться к бобам
- ООП – это единственная парадигма тебе когда-нибудь понадобится
Без лишних слов, давайте начнем!
1. Используйте наследование для совместного использования поведения
Как мы все знаем, наследование – лучший способ поделиться поведением и уменьшить дублирование кода (в конце концов, если вы не СУХОЙ, вы ВЛАЖНЫЙ).
Допустим, у вас есть класс Parrot , который может говорить , и a Говорить И Произносить По буквам , который также может говорить . Очевидно, что они оба должны наследовать от общего базового класса, чтобы вам не приходилось дублировать метод talk ! |/| класс Parrot расширяет AbstractBaseTalker и класс Speakandspell расширяет AbstractBaseTalker
Поскольку мы так успешно использовали наследование для решения этого дублированного кода, разве это не заставляет вас хотеть использовать more наследование? Что ж, вам повезло, потому что наша следующая лучшая практика ООП – это:
2. Создавайте глубокие иерархии наследования
Чем больше кода вы пишете, тем больше риск дублирования. Таким образом, по мере роста вашего приложения это означает, что глубина и длина ваших цепочек наследования также должны расти.
(Хотя я предпочитаю думать о них не как о “цепях”, что звучит так, будто вы находитесь в подземелье, а скорее как о “твиззлерах наследования”, потому что твиззлеры длинные, как цепи, но вкусные, а не как цепи.)
3. Предоставьте геттер для каждого частного участника
Как мы все знаем, в ООП, когда элемент данных является закрытым, это означает, что мы должны каким-то образом предоставить другим объектам доступ к элементу! Это означает, что вы всегда должны добавлять средство получения для своих участников личных данных. Это известно как инкапсуляция.
О, и не забудьте также добавить установщики для всех участников личных данных, потому что:
4. Изменчивое состояние – ваш друг
В реальном мире все меняется. И поскольку ООП – это все о том, чтобы брать объекты, существующие в реальном мире, и превращать их непосредственно в код, это означает, что наши кодовые объекты тоже должны измениться! Оставьте прошлое позади и выбросьте осторожность на ветер, потому что ООП освободит вас от беспокойства о том, чем что-то использовалось было. Все, что имеет значение, – это то, что есть сейчас.
Когда я сказал: “ООП – это все, что нужно для того, чтобы брать объекты, существующие в реальном мире, и превращать их непосредственно в код”, я не шутил:
5. Класс должен быть чем-то, к чему вы можете прикоснуться
ООП – это все, что связано с моделированием реального мира. Каждое приложение должно быть похоже на видеоигру, полную маленьких объектов, которые рождаются, резвятся, размножаются и в конечном итоге умирают. Вы не можете создать такое приложение, если ваши классы представляют собой нематериальные вещи. Каждый класс должен быть представлением чего-то, что вы можете потрогать! Как Пользователь , Домашнее животное , Автомобиль , и Площадь *.
Соблюдение этого означает, что ваше приложение будет более удобным в обслуживании, потому что буквально все, что Пользователь когда-либо мог сделать (или сделал с ними), теперь будет находиться в одном удобном для поиска месте!
* Главное, чтобы квадрат был сделан из бетона, или краски, или веток, или чего-то еще. Абстрактные формы – это не выход. Смотрите следующий совет о том, что делать, если вам действительно нужно работать с абстрактными формами.
6. Вы можете прикоснуться к бобам
Если вам действительно нужно написать код для чего-то неосязаемого (например, Счастье , Красный или Процедура Увольнения Сотрудника ), вы должны закончить имя класса с помощью Bean , потому что вы можете прикоснуться к бобам! Этот трюк гарантирует, что каждый класс в вашем приложении представляет собой нечто осязаемое. Больше никаких абстракций Счастье просто витает в эфире; Счастье Быть - это то, что вы действительно можете почувствовать, увидеть и попробовать на вкус.
Factory также хорош для этого, потому что factory – это тоже то, к чему вы можете прикоснуться. Но фабрики большие, сложные, вонючие и опасные, так что вам решать, хотите ли вы всю эту атмосферу в своей кодовой базе.
Но этот последний урок, который мне преподали об ООП, является самым важным:
7. ООП – это единственная парадигма тебе когда-нибудь понадобится
Если вы смешаете ООП с функциональным программированием или используете структуры массивов, призрак Джеймса Гослинга (изобретателя C++) найдет вас и устроит вам хорошую взбучку, как в том романе Диккенса. Потому что то, что ты делаешь, по сути, портит Рождество для всех нас.
Я надеюсь, вам понравился этот совет. Теперь идите вперед и кодируйте! И самое главное, примерно через 3-4 года, пожалуйста, напишите сообщение в блоге о том, как я обещал вам, что ООП решит все ваши проблемы, но на самом деле это просто помогло вам создать огромный беспорядок в виде спагетти. Это важная часть пути ООП.
Это сатира…
…или так оно и есть? Просматривая Интернет, вы могли бы подумать, что именно так преподавали ООП. Существует множество сообщений в блогах, в которых используются ужасные примеры, такие как class Dog расширяет Pet . Наследование вводится сразу после ключевого слова class , сеттеров и геттеров предостаточно, и люди относятся к C++ и Java так, как будто у них есть что-то общее с Smalltalk, Ruby или Python.
Образование в области ООП нуждается в реформировании, сейчас . Сэнди Мец не может сделать все это сама!
Я написал этот пост, потому что часто вижу плохие аргументы о том, почему ООП – отстой. ООП действительно отстой во многих вещах – но по веским причинам, а не по плохим причинам. Если бы ООП-образование было лучше, тогда, возможно, люди могли бы обсуждать эти вещи с большим смыслом и меньшим количеством глупостей.
И, возможно, если бы у людей было более ясное представление о преимуществах и недостатках ООП, не стесненных ужасными советами, подобными 7 пунктам выше, они были бы менее горькими и разочарованными, когда достигли неизбежных пределов одной парадигмы. И менее наивен и оптимистичен в отношении следующей горячей парадигмы, какой бы она ни была.
Фото автора Скотт Грэм на Расплескать . И да, однажды я видел, как кто-то писал о том, что Симуляла была изобретена Аланом Кеем.
Оригинал: “https://dev.to/crabmusket/how-i-learned-oop-a-nightmare-4hdc”