Содержание
Просто о сложном: что такое объектно-ориентированное программирование (ООП)?
Объектно-ориентированное программирование — это шаблон проектирования ПО, позволяющий решать задачи разработчика с точки зрения взаимодействия объектов. При этом большая часть объектно-ориентированных языков, например, Ruby, Python, Java, C++ наследуют на основе классов. Если говорить о JavaScript, то в нём ООП реализуется через прототипное наследование.
Наиболее удачное и популярное определение ООП звучит следующим образом — это методология программирования, которая основана на представлении программы в виде совокупности ряда объектов, причём каждый из этих объектов — это экземпляр определённого класса.
На сегодняшний день ООП — наиболее распространённый метод разработки ПО. Но использование этого метода предполагает понимание ряда принципов. О них и поговорим.
Сущность, определения и принципы ООП
Для освоения этих методов разработки вы должны знать четыре главные особенности.
Вместе они образуют сущность данного программирования. А понимание сущности ООП, как известно, не что иное, как ключ к становлению профессионального и успешного разработчика. Давайте рассмотрим эти определения подробнее.
Наследование
Это механизм, позволяющий описать новый класс на основании родительского (существующего). Причём функциональность и свойства родительского класса заимствуются новым.
Иными словами, когда вы применяете наследование в программировании, отпадает необходимость реализовывать общий базовый функционал прочих классов, так как вполне достаточно применить наследование, благодаря которому ваш класс сразу будет обладать нужными родительскими знаниями.
Для чего нужно наследование в ООП, и какие преимущества оно даёт программированию? Главный плюс — повторное использование кода. Как правило, методы и поля, описанные в родительских классах, можно переиспользовать в классах-потомках. В результате:
— приходится писать меньше кода;
— повышается качество кода, он упрощается.
При этом сам механизм довольно гибок, поэтому недостающую в потомках функциональность всегда можно дописать отдельно.
Абстракция
Тут всё предельно просто. При абстракции выделяются главные и наиболее значимые характеристики предмета, одновременно с этим отбрасываются второстепенные и незначительные.
Простой пример: представьте, что мы создаём картотеку сотрудников компании. Естественно, мы вносим их основные характеристики: дату рождения, ИНН, ФИО, номер социального страхования. Разумеется, нас не интересуют ни рост, ни цвет глаз, ни длина волос. То есть мы абстрагируемся от ненужной информации.
А что если нужно создать картотеку модельного агентства? Согласитесь, что здесь ситуация кардинально меняется и вряд ли нам понадобится индивидуальный номер налогоплательщика, а вот данные о внешности будут очень кстати.
Инкапсуляция
Этот термин для объектно-ориентированного программирования означает ограничение доступа к каким-либо данным, то есть ограничивается возможность изменения этих самых данных.
Проще говоря, есть «капсула», в которую мы «прячем» важные параметры, когда не хотим, чтобы кто-либо их менял.
Поясним термин на примере вашего имени. Его знают друзья, коллеги, родственники. Но они не могут изменить ваше имя, т. к., согласно методу ООП, у них нет к этому доступа. Всё потому, что изменения «инкапсулированы» в паспортном столе и только вы сами можете что-либо подправить. Пример инкапсуляции в объектно-ориентированном программировании — модификаторы доступа, геттеры-сеттеры и т. д.
Полиморфизм
Полиморфизм позволяет работать с несколькими типами таким образом, как будто это один и тот же тип. И поведение объектов в данном случае будет разным и зависит от того, к какому типу они принадлежат. В общем, полиморфизм указывает, какую версию метода текущего объекта необходимо запустить. Также полиморфизмом называют способность функции обрабатывать данные разных типов. Пример — автомат на вокзале, принимающий для оплаты как наличные, так и банковские карты.
Причины появления объектно-ориентированного программирования
Некоторые задаются вопросом, а почему вообще возник метод ООП? Вроде бы и работающие инструменты у программистов были, и процедурные языки, и методов реализации хватало.
Тем не менее пришло время, когда без ООП стало невозможно быстро и качественно решать поставленные задачи. Во многом это связано с усложнением этих самых задач. Усложнились типы данных, возникла необходимость делить задачу на части. В итоге программы стали представлять собой древа с кучей ветвлений и вариантов работы. Реализовать всё это, используя лишь процедурное программирование, стало весьма сложным и малореалистичным.
Программирование — это сложно / Хабр
Большинство новичков в программировании рано или поздно сталкивается с такой чарующей фразой: «Программирование — это просто, ему может научиться любой». Эта фраза сопровождается угрожающим сообщением о том, что людям, занимающимся гейткипингом, надо прекратить.
Этой статьёй я хочу сказать, что это неправда. Программирование — это сложно, оно не для каждого, и хотя сейчас им может заняться каждый, большинству определённо не стоит писать код.
Программирование легкодоступно
Когда глупые люди говорят, что программировать просто, что им может заниматься каждый, они на самом деле имеют ввиду доступность сферы программирования. Если у вас есть простейшее средство доступа к Интернету, то достаточно легко получить доступ к ресурсам для изучения. Ни одна из наук не доступна настолько, как компьютерная наука, и большинство работ по ней выложено в открытый доступ — компьютерная наука процветает в Интернете, и хотя отдельные её ветви закрыты, большинство контента доступно свободно и процветает благодаря этой доступности. Вы можете скачивать компиляторы, редакторы, IDE, даже получить доступ к документации, обсуждать с другими людьми свои проблемы, и так далее. Это огромное сообщество, уровень гостеприимности и открытости которого несравним с любой другой наукой в истории человечества.
И в самом деле, вам не нужно знать много, некоторые программы можно написать буквально через полчаса знакомства с программированием. Программирование доступно настолько, насколько не доступна ни одна другая наука.
Но легкодоступность не означает простоту изучения. Если я могу смешать три ингредиента и сделать омлет, то это не делает меня шеф-поваром. Я могу готовить несколько блюд, но никогда не скажу, что готовка — это просто. Приготовление пищи — это сложная задача, требующая терпения и внимания к деталям, много знаний и опыта.
Программирование — это любопытное сочетание творчества и точных наук; но никто и никогда не говорил, что творчество — это «просто». Некоторые вещи легко осваиваются некоторыми людьми, другие сложны для понимания.
Некоторые аспекты программирования просты
Да, в этом можно не сомневаться: отдельные аспекты просты. Существуют вещи, которые вы можете сделать, в конечном итоге получив, например, скелет приложения для блога.
Любой (под опытным руководством) может сделать профессионально выглядящую веб-страницу за первые часы изучения HTML. Можно легко задать вопрос и найти решение на StackOverflow, можно запросто скопипастить решение на свои веб-страницы.
Существует множество туториалов для начинающих, даже для абсолютных новичков, и некоторые из них созданы новичками. Программирование — в высшей степени гостеприимная к новичкам область.
Однако для разных людей простыми бывают разные вещи. То, что мне кажется невероятно сложным, другим кажется невероятно простым. То, что кажется простым, становится проблемой для других. Нет консенсуса о том, что для кого легко, но для всех есть простые вещи, зависящие от того, по какому пути обучения они шли. Тем не менее…
Большинство аспектов программирования сложно
Такова правда: если человек начинает делать нечто более сложное, чем простая веб-страница или простая демо-программа, всё становится сложным, и чем больше вещей соединяется воедино, тем более сложной и утомительной становится задача.
И именно этого вам не скажет лжец, уверяющий, что «программирование — это просто». Решать программные головоломки сложно, особенно, когда они не задумывались как головоломки.
На самом деле, при правильном подходе большинство аспектов программирования сложно, даже если поначалу и кажется простым. Причина в том, что у вас есть сложные фрагменты, которые нужно объединить и заставить их работать. И сложнее всего, когда человеку приходится писать эти сложные фрагменты с нуля. Всё кажется простым, потому что мы видим людей с пяти-, десяти- и двадцатилетним опытом, делающих вещи, которые просты для них, потому что в процессе их создания они совершили все возможные мыслительные ошибки, обеспечив таким образом себе защиту от этих ловушек.
Но нет ни одного программиста, не потратившего весь день на баг, который устраняется каким-то глупым исправлением, например, добавлением символа ;, или заменой < на <=. Никто не говорит вам, новичку, о таких моментах несправедливости мира, когда вы сталкиваетесь с багом в библиотеке или багом аппаратных ограничений.
Самозванство и мошенническое позитивное мышление
Как часто вы слышали о синдроме самозванца? Если вы слушаете выступление на тему «программирование — это просто», то, вероятно, слышали о нём, и часто на эти темы говорят одни и те же люди. Синдром самозванца — это когда человек чувствует себя недостаточно компетентным для работы, за которую ему платят, и ощущает, что он не заслужил свой успех; но слышали ли вы о случаях, когда люди на самом деле сталкивались с кажущимся непродуктивным топтанием на месте, при котором им приходится исправлять или совершенствовать результаты собственной работы, или когда они не могут быстро найти ответ на Stack Overflow. Чаще всего я слышу о самозванцах в программировании, когда их терпение лопается, когда они больше не могут соответствовать нереалистичным стандартам, которые они создали для себя, когда они не могут двигаться вперёд со скоростью, к которой привыкли. (У меня есть собственные претензии к синдрому самозванца, но об этом в другой раз.
)
Угар позитивности, мифологии «всё просто» не говорит вам ни слова о тех моментах, когда всё становится невероятно сложным, когда требуется прилежная работа и постоянные усилия. Когда вам не могут дать ответа другие люди, то остаётесь только вы и код других людей или, что хуже всего, ваш код. В такие моменты иногда приходится переосмысливать целые архитектуры, потому что некоторые аспекты не прошли проверку реальностью.
Я сказал, что сфера программирования плодородна для новичков, и это правда. Но то, что плодородно для злаков, плодородно и для сорняков, и для них особенно. Нам нужно говорить о таких людях, пользующихся преимуществами плодородной почвы. А поскольку в этой сфере множество новичков, то там есть множество людей, пользующихся ими.
Это происходит множеством различных способов; некоторые из таких людей даже не осознают, что делают это, они просто инстинктивные деляги, продающие свои навыки по слишком большой цене. Обычно они выглядят так: двухлетний опыт работы в сфере разработки ПО, пишут книги и раздают советы, иногда за приличную цену.
Мы встречаем их на конференциях, их рекламируют в статьях или в других медиа, иногда они разыгрывают карту «культурного разнообразия» (diversity), иногда — карту успешного новичка, продвигая себя и пользуясь доверчивостью толп начинающих.
И чтобы создавать ложный имидж в этой сфере, даже не нужно быть абсолютным лжецом. Достаточно играть с чувствами людей. Например, говорить им нечто ошибочное, что люди хотят слышать. Нужно подобрать ключевые слова, которые будут льстить большинству аудитории; «программирование» — это одно из них, потому что программирование — крайне размытое понятие, а получить звание «программист» желают многие, так же, как и звание «сениор», к которому стремятся люди, мечтающие стать сениорами в свои двадцать с небольшим лет. Нужно найти ярлык, лестный вашей аудитории, и применить его к ней. Именно так мы получаем лозунг «программирование — это просто» (это не так), или «HTML — это язык программирования» (это не так), или «программирование — это мастерское пользование поиском в Google/StackOverflow».
Чтобы подчеркнуть своё утверждение, затем вы демонстрируете врага. «Не позволяйте никому говорить, что это неправда» — простой, но эффективный способ внушить аудитории образ мышления «вы против враждебного мира». Неплохо также использовать словечко «гейткиперы», ведь рассуждения о привилегиях и людях, охраняющих их от аудитории, привлекательны. Они не дают вам подняться, они несправедливы, они лгут о трудностях, они заставляют вас заниматься сложной, скучной работой. Такая методика применима не только к программированию, это простая техника манипуляции толпой — если есть враги, то это простой способ сплотить аудиторию против них. Но какой бы ни была эта методика, основная задача манипулятора — размытость содержимого сообщения, чтобы было сложно его опровергнуть.
Давайте обсудим мои примеры. На объяснение лозунга «программирование — это просто» мне уже понадобилось 1385 слов, а статья ещё не закончена. Объяснить «HTML — это язык программирования» в чём-то сложнее из-за нечёткого значения термина «программирование».
Строго говоря, HTML не является реальным программированием, это язык представления разметки. Он является неполным описанием того, как выглядит и что содержит веб-страница. HTML — обязательный для любого связанного с вебом проекта инструмент, но он не используется изолированно, программирование происходит не на нём. Но если кто-то говорит вам, что HTML — это язык программирования, то обычно защищает своё заявление тем, что гейткиперы ограничивают значение слова «программирование». При этом говорящие это редко заинтересованы в изучении истинного значения собственных слов. Как я говорил, «программист» — это звание, и подобно другим почётным званиям, оно заставляет людей, особенно некомпетентных, защищать его.
Иллюзия «я могу сделать то же, что и ты»
С заявлением «программирование — это мастерское пользование поиском в Google/StackOverflow» всё сложнее. Потому что это и правда, и ложь одновременно. Мастерское владение поиском в вебе — очень важный навык современного разработчика.
Я учился в мире, где этого ещё не было, где не существовало Google, где человеку нужно было изучать документацию и иногда читать сотни страниц, чтобы понять, как всё работает. И это если документация была; в противном случае приходилось только пробовать, терпеть неудачу и пробовать снова. Однако сегодня пробовать не нужно, существуют готовые тулкиты, библиотеки или языки программирования (и даже их коммерческие версии), чётко заточенные на поиск ответа. Документация теперь предназначается не для чтения пользователями, а для индексации поисковыми движками и для того, чтобы люди работали с ней при помощи поисковых движков. Однако больше всего современные инструменты полагаются на сайт ответов Stack Overflow.
На самом деле, зависимость людей от Stack Overflow — это, вероятно, самое пугающее, что произошло с сообществом программистов за последние 10 лет. Stack Overflow — это мощный костыль, мешающий вам двигаться самостоятельно, потому что слишком легко искать ответы на нём. А когда люди перестают мыслить самостоятельно, то начинают писать неразумные вещи.
Однако освоение поиска по Google/SO — это обязательное условие. Я и сам часто ищу очень простые вещи, например, как написать цикл for на <здесь вставить название языка>. Но это не потому, что я не знаю, как пишется цикл for, а потому что переключаюсь между множеством языков за очень короткий период, и ищу наилучший способ итеративного обхода коллекции (стоит заметить, что это не всегда цикл for), или правильный синтаксис (который в каждом языке незначительно меняется, что сбивает с толку). Поэтому хотя новичок может заявить: «даже опытный разработчик не может помнить всего этого», я и новичок ищем одно и то же по очень разным причинам.
Если вы, как новичок, смотрите, что делают опытные разработчики, то это выглядит простым. Кажется, то, что делают они, может сделать каждый. Это выглядит совершенно посредственно. Существует миф о суперпрограммистах, делающих всё по-своему. Голливуд представляет их как людей, вводящих код со скоростью света, потому что единственный способ продемонстрировать высокий навык персонажа в своём деле — показать, что он справляется с работой быстрее, чем кто-либо другой (Голливуд показал бы человека, лучше всего отсчитывающего десять секунд, как того, кто справляется за пять). Смысл в том, что это выглядит просто, но на самом деле это не так. Потому что опыту новичка не хватает кругозора, сосредоточенности на действительно важном. Новичку научиться считать до десяти мешает только незнание синтаксиса цикла, для опытного разработчика синтаксис — это то, что замедляет его реализацию выполнения операций с коллекцией отфильтрованных данных.
Утверждение «программирование — это просто» не даёт людям развиваться
Этот пост возник благодаря представленному ниже твиту (и этой статье на румынском, но я остановлюсь на англоязычном твите.
— Когда я говорю кому-то, что я программист, то меня сразу начинают считать суперумной. Ребята, можем ли мы как-то вместе попробовать объяснить людям, что кодить не так сложно. В первую очередь, это в буквальном смысле гугление и устранение сделанных нами ошибок. Писать код может каждый.
— Я понимаю задачу этого поста и знаю, что он был написан не из злого умысла, однако учиться кодить сложно и это утверждение «писать код может каждый»/«кодинг — это не так уж сложно» заставляло меня чувствовать себя тупой, когда я была новичком.
Люди чувствуют себя глупыми, когда им приходится разбираться с собственным творением и пытаться его исправить, заставить работать на сценариях реального мира, которые они не всегда предусматривают, когда впервые пишут код. Позитивность не поможет тебе, когда помощь нужна на самом деле. Единственное, что ты можешь использовать — свою смелость, но что делать с необоснованной смелостью? Как быстро положительный настрой и необоснованные запросы падут перед мрачными реалиями работы программистом?
Автор первого твита сказала что-то в духе «люди считают меня умной, потому что я программист» и «главное в гуглении и исправлении своих ошибок». Но на самом деле программирование не об этом, и такой преувеличенный, ограниченный взгляд говорит мне, что её опыт в разработке ПО достаточно мал. И знаете, что пугает? Она работает над сайтом под названием «thecodinginterview.com», то есть является популярным источником советов для начинающих. И я даже не хочу начинать тему того, насколько аморально это мошенничество с «coding interview».
Позитивное мышление безотказно, потому что позитивность никогда не подвергают проверкам; и она полностью пропадает, когда ситуация действительно становится серьёзной. Все ошибки — ваша вина, потому что «кодить может каждый» и «кодинг не так сложен». Когда ты вынужден столкнуться со своими ошибками, ты остаёшься в одиночестве, потому что никакая чушь о позитивном мышлении не может их устранить.
Установка «программирование — это сложно» не должна быть пугающей
Кое-кто утверждает, что если врать новичкам о том, насколько на самом деле сложно программирование, то это их отпугнёт. Не уверен, что людей когда-нибудь останавливал тот факт, что выбранное ими занятие сложно. В конце концов, бОльшая часть нашей поп-культуры посвящена героям, выполняющим сложные задачи. Мне кажется, что именно эта культура изнежила мозги людей, считающих, что если результат не будет мгновенным, то он не стоит усилий. Но когда я начинал программировать, никто не говорил мне, что программировать легко. Я ожидал, что оно будет сложным.
Я знаю, что у многих есть одержимость «достигаторством», они хотят овладеть программированием, стать сениором в 22 года. Я удержался от преследования столь глупой затеи. Я знал, что программирование сложно и что достижение моей цели может быть невозможным. В каком-то смысле, так и есть: я изучал программирование, чтобы уметь писать собственные игры, и спустя более полувека я так и не создал ни одной. Но это дало мне чёткое понимание масштаба моего дела.
Я говорю это не для того, чтобы демотивировать начинающих. Статья всего лишь должна подготовить их к тому, что ждёт их впереди. Так что если вы хотите сказать что-то новичку, то скажите следующее: «В программировании есть простые и сложные вещи. Если ты будешь достаточно терпелив, то со временем сложные вещи станут интересными, а простые станут сложнее».
Но не говорите ему, что программирование — это просто. Это не так.
На правах рекламы
Заказать у нас сервер очень просто! Воплощайте любые идеи и проекты с помощью наших VDS с мгновенной активацией на Linux или Windows. Сервер готов к работе через минуту после оплаты!
Программирование сложное, но не должно быть слишком сложным | Иван Стоев
Как смотреть на программирование более прагматично
Фото Паката Гох на Unsplash
Программирование сложно и часто трудно понять людям, не связанным с ИТ-индустрией. Я думаю, что одна из причин в том, что это неосязаемо, и люди не могут представить себе, как работает компьютерное программное обеспечение. В этой статье я хочу поделиться своим мнением о программировании и почему я считаю, что, хотя это сложно, оно не должно быть таким пугающим и может быть легко понято любым.
Проблема визуализации
Допустим, у нас есть дом и в нем есть разные комнаты (ага).
В доме мы можем проделать все вышеописанные действия, но на данный момент там какая-то неразбериха и мы не знаем, что где происходит, или, по крайней мере, мы не знали бы, если бы действия были сложными программными алгоритмами.
Теперь мы сгруппировали действия по комнатам, в которых мы можем выполнять действие.
Разделяй и властвуй
Как разработчики программного обеспечения, мы стремимся создавать слабо связанные компоненты, независимые друг от друга, и вы должны думать о программировании как о создании отдельных небольших частей программного обеспечения, которые выполняют только определенные небольшие функции.
Часто люди думают о чем-то вроде Netflix, Youtube, Google и т. д. и предполагают, что код этих платформ чрезвычайно сложен и труден для понимания. И хотя код действительно большой, он разбит на несколько небольших частей, которые имеют большой смысл даже в одной из них.
Например, мы можем думать о разделе комментариев на Youtube как о небольшой программе. У вас есть возможность опубликовать комментарий, например, комментарий, ответ и т. д., и хотя он связан с гигантским приложением Youtube, он является независимым компонентом.
Что насчет баз данных
Базы данных — это наборы данных, которые хранятся и доступны программно. Базы данных, вероятно, являются наименее запутанным аспектом программирования для людей, не связанных с ИТ, поскольку они связывают его с хранением данных.
И действительно об этом на более высоком уровне. Функции, которые выполняет программа, для работы требуют определенных данных. Для разделов комментариев Youtube такими данными может быть сам комментарий, кто его написал, на каком видео он был опубликован и так далее.
И снова, думая об этих больших платформах, вы также можете подумать, что каждый компонент этой платформы, вероятно, имеет свои собственные базы данных. Поскольку мы сказали, что эти компоненты могут работать независимо, логично, что для каждой службы должна быть своя база данных.
Интерфейс и серверная часть
Когда вы видите «Внешний интерфейс», подумайте обо всем, что пользователь видит на веб-сайте, в мобильном приложении, в игре и т. д. Интерфейсная часть приложения — это часть, видимая внешнему миру. Когда вы нажимаете на кнопку, меняете страницу, смотрите фильм на Netflix и так далее.
С другой стороны, бэкэнд — это вся логика за кулисами, благодаря которой эти клики действительно работают. В серверной части программного обеспечения происходит большая часть бизнес-логики, а также там, где происходит соединение с базой данных. Подумайте о таком простом примере: вы стираете белье, поэтому вы кладете одежду в стиральную машину, устанавливаете режим и нажимаете кнопку «вкл». Это фронтенд часть. Затем стиральная машина определит, какой режим вы выбрали, и начнет подавать моющее средство, затем воду и так далее. Это решения, принимаемые машиной, которые нам не видны, поэтому они являются эквивалентом «бэкенда» для нашей стиральной машины.
Заключение
Программирование и программное обеспечение в целом представляют собой набор небольших независимых частей, которые взаимодействуют с пользователем через внешний интерфейс, который визуализирует то, что мы хотим сделать, а затем выполняет заданное действие за кулисами, а также может использовать информацию из хранилища. .
Большие приложения решают сложные задачи, заставляя все части программного обеспечения взаимодействовать друг с другом для получения желаемого результата, и мы должны помнить об этом, потому что программирование усложняется, когда мы пытаемся делать слишком много вещей одновременно. Вот почему лучший способ писать и думать о кодировании состоит в том, что это несколько небольших частей, каждая из которых выполняет простую задачу, пока они вместе не смогут решить сложную задачу.
Длинный и простой код — или короткий и сложный? | Адам Маршалл
В предисловии к этой статье я скажу, что все разработчики разные. На самом деле, именно поэтому существуют эти дебаты. Некоторым короткий, но сложный код кажется беспорядком. А для других большое количество простого кода кажется беспорядком. Я думаю, что это сводится как к знаниям в области разработки, так и к уровню сложности. Но, конечно, интеллект тоже имеет значение; для очень умных людей то, что кажется крайне сложным и преувеличенным среднему разработчику, кажется им очень простым и красивым.
С учетом всего сказанного, мои 0,02 доллара по этому поводу заключаются в том, что короткий, но сложный код лучше, если он задокументирован. Обратите внимание, что сложность не означает дерьмовые имена переменных, непостоянные интервалы и плохо продуманный поток управления. Это говорит о качестве кода, а не о его сложности.
Не путайте плохо написанный код со сложным кодом.
Я бы сказал, что сложный код в этом сценарии — это просто код, который умело использует различные функции языка для выполнения сложных задач с помощью небольшого количества символов. Вещи, которые некоторые могут назвать «синтаксическими сахарами», но на самом деле являются просто изящными функциями языка. Примером сложного фрагмента кода может быть функция, использующая 5 // 2 вместо math.floor(5 / 2) в тандеме с пониманием словаря и функцией из itertools . Такой фрагмент кода не просто читать, и зрителю может потребоваться немного подумать.
С другой стороны, длинный, но простой код будет кодом, в котором используется множество очень распространенных программных конструкций (например, длинные/вложенные цепочки if и множество переменных). Это не требует особых объяснений, так как читается как книжка для детского сада; простой, понятный, ограниченный словарный запас.