Объектно-ориентированное мышление слишком сложно для вас

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

Вы не одиноки, если считаете ООП сложным и утомительным. Простой поиск в Google “почему ООП так сложно” показывает тонну разочарованных желающих стать разработчиками.

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

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

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

Объектно-ориентированное программирование, ОО-мышление, DDD, ссылочные и стоимостные типы, паттерны проектирования, принципы SOLID, чистый код, полиморфизм, наследование и инкапсуляция (три столпа ООП). И это лишь некоторые из них.

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

Неудивительно, что любой новичок будет ошеломлен, если начнет изучать код на языке ООП.

Объектно-ориентированное программирование требует развитого мышления.

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

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

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

Я понимаю, почему многие разработчики утверждают, что ООП – это “плохо”.

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

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

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

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

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

Поймите, что паттерны проектирования ООП – это уход от безумия, вызванного if-else.

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

Переход от умения использовать только if-else к более правильным подходам, таким как полиморфизм, является явным признаком того, что вы развиваете свои навыки и расширяете репертуар кодирования. Однако такой переход вызывает некоторое сопротивление изменениям.

Итак, как вы можете совершенствоваться?

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

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

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

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

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