×Закрыть

Уровни абстракций — ключ к пониманию архитектурных изысков ПО

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

Абстракция — один из набивших оскомину столпов ООП. В любом курсе по программированию с вероятностью 99% можно найти урок-другой, посвященный теме абстракции. И практически всегда упускается более широкое, всеобъемлющее понятие «уровней абстракции» — на мой взгляд, критически важное, ключевое для понимания всех остальных принципов проектирования.

Модель объекта и ступень приближения

Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали, не играющие существенной роли в данном приближении. И уровень абстракции — это и есть наша ступень приближения. Каждый человек способен строить абстракции — это отличительная способность homo sapiens. Но не каждый способен делать это достаточно качественно.

Чтобы не вдаваться в многоэтажную теорию, приведу наглядный пример. Итак, раскладываем по полочкам. Представьте себе, что вы решили испечь яблочный пирог. Вы берете толстую кулинарную книгу с полки (для любителей, все остальные — в сеть), открываете нужный вам рецепт и читаете нечто следующее:

«Чтобы испечь яблочный пирог, нам понадобится два килограмма непременно свежих яблок, румяных, как девичьи щёки на крещенском морозе. Помнится, видал я такие щёчки у моей ненаглядной Лизоньки, когда мы впервые с ней встретились, и она угощала меня яблочными пирогами, состряпанными на последние деньги, которые она выручила от продажи дедовских коллекционных монет 1819 года, выпущенных при императоре таком-то...» И т.д, и т.п.

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

А теперь вспомните, как часто в коде нам приходится встречать логические конструкции типа if-if-if-else-if-else-if, содержащие тонны вложенных рассуждений. Приходится читать все эти адские нагромождения и держать в голове всю цепочку событий, для того, чтобы понять, что тут вообще происходит и какое отношение «вот это всё» имеет к заявленному содержанию (название класса/функции по аналогии с названием рецепта «яблочный пирог»).

А ведь что на самом деле нас интересовало в рецепте? Нам нужно было знать, сколько и каких продуктов нам понадобится и что затем с ними делать. Нас абсолютно не интересует в этом приближении (на данном уровне абстракции), каким образом эти продукты к нам попали (более низкие уровни абстракции) и что мы будем делать с этим пирогом потом (более высокие уровни абстракции). Это очевидно. Но тысячи программистов продолжают игнорировать эти принципы и пишут мозговыносные структуры if-if-else-if...

А бывает так, что в рецепте встречаются умные словечки типа «бланшировать» или «сделать бизе». В хороших кулинарных руководствах описание подобных практик выносят в отдельные главы, а в самих рецептах лишь ссылаются на страницы с подробным описанием техники (привет, Инкапсуляция).

Построение структуры

Конечно, бывают и обратные ситуации, когда за тоннами слоёв абстракций невозможно уловить нить повествования. Но в этом-то и состоит мастерство архитектора ПО — спроектировать достаточно простую для сопровождения, то есть понимания, структуру. «Не нужно быть умным — нужно быть понятным» ©.

В то же время, не терять в эффективности решения бизнес-задач. В некоторой мере, это искусство. Каждый конкретный архитектор (программист) будет рисовать эту картину, то есть создавать модель мира по-своему: «Я художник — я так вижу». Вот вам пища в топку холиваров на счет единых стандартов программирования в рамках команды и необходимости наличия исполнителя роли архитектора.

Абстракция и Реализация

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

Чтобы упростить этот процесс, стоит разобраться в природе дуальности понятий Абстракции и Реализации. В этом моменте обычно и фокусируются на различных курсах по программированию, перед этим упуская понятие уровня абстракции. Из-за чего у студентов формируется заблуждение, что ООП — это что-то запредельно сложное.

Возьмем для примера такую цепочку слоёв абстракций: нам нужен пирог для Дня рождения друга. Спускаемся ниже: пирог может быть фруктовый или мясной. А может, рыбный? В момент рассуждений о том, что нам нужен какой-то пирог в качестве подарка, он (пирог) выступает конечным элементом данного уровня абстракции. В этот момент пирог — это реализация подарка (но он может быть любой: бритва, деньги, конструктор лего — это всё варианты подарка). Когда мы совершаем переход на более низкий уровень абстракции, наш объект (пирог) превращается из конечной реализации в абстракцию: уже нас не устраивает уровень детализации «какой-то пирог», мы начинаем искать его реализацию (привет, Полиморфизм).

Таким образом, считать объект абстрактным или реальным — зависит исключительно от степени детализации моделируемого «мира» и от бизнес-задач, поставленных перед архитектором. И, разумеется, от его чувства прекрасного.


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

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

Если моя манера изъясняться была кому-то полезной в достижении состояния «дзен» и вообще «пишите, Шура», то в будущем, вероятно, напишу «о чём-то таком ещё».



Продолжение

Лучшие комментарии пропустить

В кои веки на сайте посвященному разработке ПО статья о разработке ПО.
Как надоели эти нудные однотипные «интервью» и обзоры «экономики» ИТ Украины, отчеты и прочая пустота, которая не дает ничего полезного. В каждой рассылке социальной мути больше чем практической или теоретической полезной информации.
Так и живет ИТ Украины — больше похоже на реалити-шоу, поэтому мне не удивительно что у нас в Украине толком и нет продуктовых компаний и стартапов толковых — один оутсорс для всей этой «серой массы» только и доступен.

102 комментария

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

складна у вас робота якщо початківці розробляють архітектуру ПЗ...

Там ниже среди комментов есть противоположное вашему мнение.

Спасибо за статью, было интересно.

Теоретически, уровень (силу) абстрактного мышления человека можно навскидку оценить по количеству и частоте употребляемых им местоимений.

Ну, эта... как его.. ваша... эмм... как её... А! Точка зрения! Она, как бы эта... ну, как же его... эммм... сомнительна она, да.

Уважаемая Наталья! Хотел поделиться своим опытом преподавания: когда я 11-классникам говорю, что фактически и в программировании, и в математике, и в физике они работают с МОДЕЛЯМИ, а не с конкретными объектами, это их ставит в тупик! Причём, некоторые мои ученики выигрывают олимпиады, ребята они толковые. Я месяцами пытаюсь абстрагирование как-то им «вживить в подкорку». А дети 11-12 лет под словом «собака» подразумевают ту последнюю, с белым ухом, что видели вчера. Им тяжело осознать собаку как класс или объект. А ведь это через год-два — уже Ваша аудитория! (у меня 6-классники уже склепали сайт своего 6-Б:), причём не на CMS, а разбирались с HTML/CSS. Я хочу сказать, что культура обобщений, абстрагирований, то есть — философская, ну, или логическая, вообще отсутствует в обществе. Я нашёл способ объяснять абстракции (для решения задач по алгебре, кстати) — GoogleMaps. Там при масштабировании интуитивно понятно, что вот твой дом — объект (конкретно жёлтый и 5-ти этажный и № 37, а вот уже — точка, а вот — твой город уже точка, а для Австралии — твоя страна уже пятно, а для Юпитера — твоя планета — точка). Детей не учат ни анализу, ни синтезу, ни абстрагированию — одни тупые и никчемные алгоритмы «счетоводства», типа дискриминантов бесконечных... Поэтому Вам и приходится разъяснять Ваши статьи бесконечно! У молодых людей просто нет мировоззренческой базы для их восприятия. Кстати, спасибо большое!

Очень интересные наблюдения. Спасибо за откровенность. Я помню себя в старших классах — у меня всегда были лучшие оценки по алгебре и началу анализа. Большая часть учеников на нашем потоке (это был лицей, там лекции читали для потока, а не для класса), они не понимали вообще ничего в том, что происходит на доске — у них перед глазами какая-то завеса висела. Теперь я понимаю, что это было именно то, о чём вы говорите. Я думаю, мои способности к математике в школе, а затем и к анализу во взрослом состоянии обусловлены тем, что в детстве мои родители старались объяснять мне суть вещей, их причины, что порождает те или иные события — они разжовывали мне это на элементарных примерах, строя взаимосвязанные цепочки. Мне кажется, восприятие абстракций начинать закладывать надо с глубокого детства, а не в 11-м классе. Вам как учителю теперь приходится пожинать плоды родительского безразличия. Искренне желаю Вам научить Ваших учеников вещам, которые Вы знаете сами.

А ещё, можете попробовать с ними «поиграть». Дайте им пример разложения на уровни абстракции — у вас это путешествие по уровням локации в пространстве (дом — точка на уровне города. Город- точка на уровне страны. Страна — точка/пятно на уровне планеты и т.д.). И в домашке или на самостоятельной работе (а лучше и там, и там), дайте им задание: придумать свою цепочку уровней абстракции. Может быть, это будет хорошее упражнение.

В кои веки на сайте посвященному разработке ПО статья о разработке ПО.
Как надоели эти нудные однотипные «интервью» и обзоры «экономики» ИТ Украины, отчеты и прочая пустота, которая не дает ничего полезного. В каждой рассылке социальной мути больше чем практической или теоретической полезной информации.
Так и живет ИТ Украины — больше похоже на реалити-шоу, поэтому мне не удивительно что у нас в Украине толком и нет продуктовых компаний и стартапов толковых — один оутсорс для всей этой «серой массы» только и доступен.

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

А статьи — ну так пишите и присылайте. Откуда редакторы доу возьмут много технического материала, если его никто не пишет? Другое дело, что аудитория доу-комментаторов в сборном портрете больше напоминает эдакого закомплексованного «прыщавого школьника», чем взрослого адекватного человека. За любой промах в материале — голову оторвут и с благородным белковым д*мом смешают. Мой самый первый материал тоже освистали. Даже не знаю, зачем я продолжила что-то публиковать.

Та ладно, на доу аудитория весьма доброжелательная. Это вы на хабру писать не пробовали, видимо...

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

Замечу также что смутило и что может, на мой взгляд, несколько сбить новичка с толку при переходе от теории к практике: упор на состояние объекта в качестве «сути» объекта, а не на перечень действий с объектом. Особенно это касается раздела «Абстракция и Реализация», где классификация даётся в отрыве от отображения классификации на поведенческую модель. Как мне кажется, в наиболее распространённом к данном времени понимании ООП именно набор действий с объектом задаёт понимание сути объекта.

П.С.: Как говорилось в статье и в обсуждении, темы связанные с дизайном ПО — благодатные для холливаров. Поэтому сразу замечу: пишу для того, чтобы конструктивно обсудить какие-то вопросы, а не чтобы кого-то подколоть или обидеть.

Спасибо за конструктивный комментарий.

Я задумывала эту статью исключительно как пояснение уровней абстракций — про них нет толковых статей, я не встречала. Разумеется, перечень действий с объектом — это невероятно важно. Однако, я думаю, что это относится к части интерфейсов. Завтра как раз публикуют статью по DIP — там это будет. Не хотелось впихивать в один материал столько информации — сложно было бы построить монолитный рассказ.

Ага. Ясно... Ну, отлично. С удовольствием почитаю продолжение про интерфейсы.

Спасибо!

«Каждый человек способен строить абстракции» — автор живет в стране добрых волшебников, где все ездят на единорогах по радуге.

Take it easy. Ну члены племени Пираха не могут. Остальные могут. Больные, человеческие эмбрионы и дети до определённого возраста не в счёт.

Хотя не, вон в вики пишут, что пирахане не такие уж и безнадежные.

Мне кажется, этот комментарий больше для Хабра подходит, там любят поверить во что-то плохое и приукрасить единорогом )

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

На пальцах объяснять — самое правильное.

Мне тоже статья очень понравилась. А то читаешь в GoF одну главу 10 раз и все равно ничего не понятно, а эта статья вдохновляет.

Статья прикольная :) Автор — вы молодец, новичкам все это сгодится.

П.С. Комментаторы, которые умничают, критикуют и поправляют, не сказав ни единого слова поддержки за труд другого человека — не пишите больше ничего, пожалуйста :)

Вспомнилась статья, особенно часть про монады.
mkremins.github.io/...daches-intellectual-need

Из лекции Н. Малюкова: «декомпозиция сверху вниз — основной метод проектирования». Даёшь больше материала!

Как по мне — статья поверхностная, в основном общие фразы. Сомневаюсь, что она может быть полезна новичкам. Скорее детям начальных классов. Лучше бы автор не поленилась и вместо этих рисунков привела бы примеры кусков кода по созданию пирогов.

Конечно, спасибо за столь ценный совет, но у меня другие планы. Вместо того, чтобы рассказывать, что мне делать, вы можете самостоятельно продолжить начатое мной дело и написать по вашим меркам «полоценный, насыщенный глубокими фразами» материал. С примерами кусков кода.

Морской закон: «Кто предложил — тот и делает».

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

превращается из конечной реализации в абстракцию: уже нас не устраивает уровень детализации «какой-то пирог», мы начинаем искать его реализацию
Реализация пирога это собственно рецепт, а в рецепте может быть столько угодно слоев тобиж уровней.

По статье:
Манера изложения легка и непринужденна, но кое-что не все смогут понять (фантазия барахлит и прочее), вследствие.....нужно продолжение ))))))))

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

А ведь что на самом деле нас интересовало в рецепте данной статье?...

Статья забавная, но убойно туманная. Хочется добавить картинку с лётчиком, который говорит «я ничего не понял». Останавливает только доверие к искренним намерениям автора.

На тему уровней абстракции вспоминается старая максима от Kevlin Henney — «Любую проблему можно решить введением дополнительного уровня абстракции, кроме проблемы чрезмерного количества уровней абстракции».

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

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

А если без сарказма: я не совсем поняла, что именно «некий». И лично мне больше нравится «стУпень» — я так вижу. В своём воображении я перемещаюсь между уровнями абстракций по ступеням: делаю шаги вверх или вниз — это очень образно. Мне нравится.

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

«Некий».
Вы писали о модели некоего объекта. В том контексте объект не может быть неким (неопределенным), иначе к нему нельзя применить моделирование и абстракцию.

Вам могут нравится или не нравится какие-то слова — ваше дело.
Если вы пробуете себя на роль лектора, то разумно не допускать ошибок — слушатели засмеют.
В таких ситуациях «ваше» становится не только «публичным», но и может нести «знание».
Требования к высказываниям в таком случае жестче.
Надеюсь, это понятно и ясно почему именно так.

И да, я понимаю, что вы допустили не орфографическую ошибку, а именно стилистическую ;)
Именно поэтому мой совет был таким, каким был.

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

По поводу советов «как быть лектором». Я исповедую принцип, что нужно слушать советы исключительно тех людей, которые достигли определённых успехов в деле, на счёт которого дают консультации.

В свете вышесказанного, дерзну спросить: вы активно практикующий лектор? То же касается «стилистики фрагментов текста» — у вас богатый опыт в написании статей или какого-то другого письменного материала? Если да — тогда можем подискутировать как практикующие специалисты. А если вам интересно потрепаться «чисто с теоретической точки зрения» — имейте хоть какое-то уважение, не тратьте моё время попусту.

У вас не правильный подход по поводу того кого надо слушать.
Хороший тренер и хороший спортсмен это разные люди

Ответ из серии «нечем бить».
Но если вам так нужен «хороший тренер» — не вопрос.
Первая ошибка: вы стали давать советы в делах, в которых некомпетентны.
Второе: вы допустили ошибку «плохого рассказчика», написав в своём первом сообщении о вещах, контекст которых ведом вам одному (//"некий").
Третье: вы придирались и навязывали человеку своё стилистическое видение: если знаете как лучше -"пишите, Шура«.
Четвертое: «неправильный» в последнем сообщении пишется слитно (чисто грамматическая ошибка, не стилистическая).
Пятое: вы употребили плод моего умственного труда и в благодарность совершили низость, начав оскорблять меня.
Нет вам моего прощения.

Из плюсов: вы храбрый человек.

хмм, рекомендую читать имя человека которому вы отвечаете

Я прошу прощения за свою ошибку, в порыве безудержного веселья не заметила такой очевидности :-)

Ваш пункт только четвёртый.

Ну и раз «вы — не он», расскажу маленькую историю. У меня есть свекровь, которая постоянно даёт мне советы «а как лучше строить семейную жизнь». Если бы я ее слушала, я бы развелась уже раз десять. А знаете почему? Она сама не смогла построить своё «гнездо», она живёт без мужчины и «абсолютно счастлива». Но при этом раздает советы «а как укрепить отношения». Вот если бы мне надо было стать хронической разведенкой — я бы непременно пошла к ней, в этом вопросе человек несомненно компетентен.

Поэтому это слово нельзя здесь использовать.

Доказать сможете? Что-то ваше мнение тут не совпадает ни с известной практикой (которая позволяет использовать «некоторый» или реже «некий» для введения указания на новую сущность, которая далее будет рассматриваться), ни со свидетельскими источниками вроде gramota.ru, которая явно приводит примеры такого употребления (так что тут не получится и сослаться на украинизм).

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

О боже... В определении не важно, какой именно обьект будет представлен в виде модели. Это не суть важно. Не имеет значения. Не относится к данному уровню абстракции. Не является существенным. Да пофигу вообще, от чего там абстрагируются. Важно, что оно существует хоть в каком виде. Что это НЕЧТО, из чего мы хотим построить абстрактную модель. Бельме?

Хотя, если вопрос сугубо в «придолбаться», то логика и медицина тут бессильны.

Автор декларирует определение.

Автор вводит новую сущность в рассмотрение.

Вы правда считаете, что в определении может быть неопределенность?

Сплошь и рядом. В математике, например.
«Для любого X такого, что Y(X), выполняется Z(X)» — общая форма множества теорем. «Для любого X, что Y(X)» тут полностью аналогично «модель некоего объекта или явления реального мира» у Наталии.

Даже нашли на языковом портале подобное в примерах?

Да. Не понимаю, почему это Вас так удивляет.

Автор вводит новую сущность в рассмотрение.
Тогда бы была вводная часть, что-то типа: допустим, рассмотрим, представим.
А написано: абстракция — это...
Это определение. В данном случае — определение термина.
Сплошь и рядом. В математике, например.
Любой не равно некий.
Приведенные вами примеры всегда предваряются очерченной областью (контекст) и определения даны раньше. Совсем другой случай.
Аналогией в математике будет аксиома.
Аксиома всегда конкретна, детерминирована.
В данном случае — определение термина.

Со свободной переменной.

Совсем другой случай.

Другой, но не совсем. Без математической строгости, но сами элементы подхода взяты оттуда. Это нормально для попытки объяснить некоторые совершенно фундаментальные принципы «на пальцах».

Главное не увлекаться, чтобы не пришлось разрабатывать 3 года, то, что за 2 недели можно написать

Вы абсолютно правы. Но это тема для отдельной статьи )

Мое ИМХО — не сачкуйте и рассказывайте трейни и джунам про абстракции в том же духе и с подобными же картинками :8)

Годно, по-моему.

самое ценное в статье

«Не нужно быть умным — нужно быть понятным» ©.
остальное с моей точки зрения муки Аристотеля

Вы первый абзац статьи читали?

Наталья ни в коем случае не хотел своим мнением Вас обидеть, но как видно из реакции всё же задел...

Если вы супер-сениор и всё-всё знаете — напишите о чем-то интересном нам, вместо того, чтобы рассказывать, что «это все и так известно». Вот например я не считаю себя сениором, но пишу о вещах, в которых достаточно ориентируюсь. Потому что я помню, как это было адово сложно — разбираться в этих вопросах.

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

я тоже так думала какое-то время назад. Но потом я поняла, что многие люди сталкиваются с одинаковыми проблемами. И если я сталкиваюсь с некой проблемой — то вероятность того, что она «вся такая уникальная» примерно равна нулю. Я помню свой путь и вопросы, которые у меня возникали, на которые мне было тяжело найти ответы — я систематизировала их у себя в голове и кое-что из этого написала здесь. Не всем будет полезен мой опыт, но те, кому он пригодится, я думаю, несомненно существуют.

возьмите пяток джунов в своём окружении. Расскажите каждому из них персонально тему, которую считаете полезной для них. Промониторьте реакцию, интерес и пробелы в их знаниях — и на основании этих исследований пишите статью на выбранную тему. Скорее всего, с такими же проблемами, как у ваших «подопытных», сталкивается большинство новичков. Таким был мой опыт.

Наталья я нигде не писал

это все и так известно
а так же не писал и не рекламировал себя как
супер-сениор и всё-всё знаете
по поводу комментария он означает простые две истины
1 мне понравилась фраза и я с ней согласен
2 что Ваши размышления изложенные в статье по поводу Абстракции
носят больше философский оттенок

простите за мой уровень Абстракции в комментарии

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

у вас рядом с именем написано «Senior web developer»

Далась Вам эта надпись

Ладно давайте по статье
первый абзац к которому Вы меня отсылали гласит

Эта статья будет в большей степени полезна новичкам

вспоминаем себя начинающим разработчиком и пытаемся понять что написано в статье с точки зрения начинающего разработчика

читаем раздел

Модель объекта и ступень приближения
и узнаем два новых понятия
Абстракция
и
уровень абстракции
хорошо попытались запомнить новые понятия читаем рецепт ... и узнаем о куче if и т.д. по тексту

вспоминаем что у нас не так много опыта и естественно это информация нам не говорит ровным счетом ничего

читаем дальше раздел

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

следующий раздел

Абстракция и Реализация
из этого раздела узнаем
В этот момент пирог — это реализация подарка (но он может быть любой: бритва, деньги, конструктор лего — это всё варианты подарка)

абстракции конечно абстракциями но вот как то не уловил через какое количество уровней абстракции должен пройти пирог что бы стать «подарком бритвой»

как говорится в народной мудрости(если быть точным то это упрощенная фраза Сергея Павловича Королёва) «критикуешь — предлагай»

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

т.е. какой то Пирог — это Абстракция, Пирог С Яблоками — это Реализация, Пирог С Вишнями еще одна Реализация Абстракции Пирог

если выражаться терминам программной индустрии то Пирог это Интерфейс а Пирог С Яблоками это конкретный класс реализующий Интерфейс Пирог

после усвоения этого материала можно ввести понятие Уровня Абстракции

для поясняющего примера использую Ваши наработки

если мы пишем приложение которое помогает пользователю в выборе Подарка,
тогда для решения нашей задачи нам нужен новый Уровень Абстракции
благодаря которому можно рассматривать любой из Пирогов (ранее реализованных нами) наряду с другими реализованными абстракциями такими как Бритва, Конструктор, Деньги как новую Абстракцию Подарок

на этом Уровне Абстракции — Пирог С Вишнями, будет являться одной из Реализацией Интерфейса Подарок ...

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

ЗЫ: не воспринимайте критику так болезненно это не попытка Вас обидеть

Вы сами себе противоречите. Вы предлагаете навешать юмону падавану сходу про Интерфейс.

Ну и кроме того, вы выкинули контекст:

только начинающим работать с абстракциями и построением архитектур ПО

Считаю ваши придирки необоснованными.

я насчитала всего двоих «пострадавших», включая вас. Откуда у вас сведения про «пол аудитории»?

Как правильно заметили, проблема больше философская, но тем не менее интересная, чтобы рассмотреть её в разрезе разработки ПО.
...
In my simple world, было бы полезно дополнительно рассмотреть как данные подходы и умозаключения реализуются в области инструментальных средств — языков программирования, тоесть ближе к телу )
...
* ортогональный интерфейс, мы же создаём абстракции не просто так, а чтобы потом наделить их поведением (или выделять их на основе поведения)
* наследование, композиция, агрегация. извечная борьба, советы применения на реальных примерах.
* интерфейс, класс, объект — тут работать и работать, я даже не могу предложить с какой стороны тут подходить к решению )
...

«пишите, Шура»

Я тут как-бы статейки пишу, а не книгу :-) Кроме того, если я выберу какую-то шибко простую тему — меня ж заклюет сообщество, мол «мы и так это знаем». Проще и практичнее брать сложные темы, про которые в сети мало информации или она неполная (непонятная). А рассказывать о том, чего и так полно и в книгах и в сети — не вижу смысла. Скорее всего (якщо буде час та натхнення), напишу про Лисков и инверсию зависимостей.

студенты (и не только) ... вообще нихрена не понимают дальше Наследования.
1. потому что это философские проблемы, а не «технарские». а так как философия отрицается, но ею приходится заниматься при абстрагировании — то и выходят «диспуты неофитов», или интуитивные постижения ремесленников.
например
В ООП классом называют тип объектов, как у Аристотеля. Было бы правильно в ООП вместо термина класс объектов использовать термин тип объекта. Однажды, съехав с правильной терминологии, вернуться в лоно правильных терминов оказывается очень трудно.
habrahabr.ru/post/249165

2. в основных ООЯ интерфейс и реализация синтаксически плохо различимы. отсюда путанница в головах, после «наивного» проектирования гирлянды классов, когда доходит дело до написания реализации.
пример 1
есть часто применяемое — «утиный тест» если нечто ходит как утка, плавает как утка, и крякает как утка, то это утка и есть.
хотя согласно вики в источнике: Когда я вижу птицу, которая ходит как утка, плавает как утка и крякает как утка, я называю эту птицу уткой.
то есть указана реализация «птица», у которой есть интерфейс «ходит, плавает, крякает как птица с интерфейсом утка»
а если это НЕ птица, то даже при соблюдении интерфейса «утка» это будет не утка.
и это тоже совсем не новость. вот знаменитая история про тоже самое:
Платона однажды попросили его дать определение человека, на что тот ответил: «Человек есть животное на двух ногах, лишённое перьев». Однако после того, как Диоген Синопский принёс в Академию ощипанного петуха и предъявил его в качестве платоновского человека, Платону пришлось добавить к своему определению: «И с плоскими ногтями».

программисты же создав(вычленив, абстрагируя) интерфейс — делают выводы и о реализации, и когда начинают ее описывать в программном коде — очень удивляются. иногда докапываются до «вечного» ООП вопроса — object IS A vs. object HAS A — то есть — до первой рефлексии.

3. ООП бывает двух видов — основанное на модели акторов, и расширение процедур состоянием.
в учебниках же эти два вида смешиваются. что является третьей причиной путанницы в умах.
первый вид не интересует реализация, а второй — поведение.
но так как в действительности важны оба аспекта — то программист с путанным умом, и не знающий о корнях проблематики принимает решения на свой «хлопский розум». если повезет — «угадает».
но объяснить рационально свое везение другим — не сможет.
вопрос-маркер
ты хотел наследовать поведение ИЛИ реализацию?

или он же по сути, который я люблю задавать на собеседованиях
паттерн MVC знаешь? а в какой его букве нужно размещать бизнес-логику?

Слишком много вопросов вы подняли — мы неделями будем всё это обсуждать :-)

почему неделями?
эти вопросы обсуждаются уже пару десятилетий :)
при том что курс аналитической философии или ее производных обычно прослушан в колледже.

а у нас так вообще малоперспективно обсуждать — негативизм к философским проблемам парадоксально сочетается с занятием ими при — проектировании иерархии классов :) по терминологически спутанными при переводе книгам, авторов, которые учились в колледжах, а не постсоветских вузах :)

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

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

Никак не наследовать. Используйте Полиморфизм.
dou.ua/...el-of-abstraction/#913298

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

А на счёт контроля архитектурных решений — вы про дизайн-ревью слышали? Да, не обязательно это должен быть именно архитектор личной персоной, но кто-то, кто понимает общую задумку.

И ещё пять копеек: пример с квадратом и прямоугольником — популярный для демонстрации принципа подстановки Барбары Лисков. Но об этом принципе я, возможно, напишу в следующий раз. Если вы не будете доставать меня до печенок попытками подловить меня на «вранье».

А когда вы о чем-то просите, надо писать «пожалуйста» — ну или хотя бы не так откровенно наезжать с претензиями.

Спасибо. Если бы я был вашим студентом не знаю как бы я отнёсся к таким ответам.

Вы не мой студент. Да и вряд ли бы вы смогли в лицо говорить в том же духе, как пишете. Вежливость — в принципе полезная вещь. Я не намерена терпеть хамство ни от студентов, ни от кого-то ещё. Мы все свободные люди — если кому-то не нравится, что я не люблю, когда мне выдвигают претензии — не слушайье мои лекции, не спрашивайте меня ни о чем, не читайте мои статьи. Есть масса литературы и других статей на поднятую тему — это все можно за пару лет осилить собственными силами и прийти к пониманию вещей, о которых я тут распинаюсь.

Пожалуйста, очень нужна толковая статья по принципу подстановки Барбары Лискоу :) который год не могу понять его смысл.

А что именно непонятно?

я сегодня накидала статью по Лисков, но прежде чем её публиковать, надо написать про инверсию зависимостей, без неё будет тяжко с Лисков разбираться. Осталось ещё немного подождать )

dou.ua/...v-substitution-principle Надеюсь, она будет понятной — судить вам )

Спускаемся ниже: пирог может быть фруктовый или мясной. А может, рыбный?
Вот тут ты пропустила (привет, Наследование) :)

Всё, что я сейчас скажу — прозвучит дико. Но таков мой взгляд на эти вещи.

То, на что вы указываете — это Полиморфизм. Наследование, на мой взгляд, стоит рассматривать в теме «Что такое Класс и Обьект в ООП» — и то лишь как идею, позволяющую размножать классы. Это просто «правило игры ООП». В то время, как Полиморфизм и Инкапсуляция — естественные следствия абстрагирования (как и Интерфейс и всё остальное). Думаю, именно поэтому все новички так просто вкуривают Наследование (ну оно и правда элементарное, это лишь правило, не надо много мозга, чтобы его запомнить), а о Полиморфизм и Инкапсуляцию ломают зубы. Просто надо начинать разбирать ООП с Абстракции и её уровней, а потом только браться за Классы и Обьекты. Именно по той же причине, я думаю, студенты (и не только) постоянно применяют Наследование вместо Полиморфизма и Инкапсуляции и вообще нихрена не понимают дальше Наследования. Они не понимают уровней абстракций и не видят, что практически все принципы проектирования — это просто естественные следствия Абстрагирования.

Заранее простите, если кого-то обижают мои слова.

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

превращается из конечной реализации в абстракцию
, — довольно неожиданная подводка к идее полиморфизма. И, как по мне, — очень живо и наглядно.
В курсе Learning How to Learn на Coursera объясняется техника «Memory Palace». Суть её — в привязывании новых концепций к хорошо знакомым предметам/понятиям/ландшафтам. По-моему, перекликается с идеей объяснения уровней абстракции и полиморфизма на типах пирогов. Особенно для тех, кто любит печь.

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

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

Возможно, когда-нибудь на пенсии... А пока что ограничусь кругом профессиональных друзей ) Спасибо за лестный отзыв.

пишите, Шура
Нас абсолютно не интересует в этом приближении (на данном уровне абстракции), каким образом эти продукты к нам попали (более низкие уровни абстракции) и что мы будем делать с этим пирогом потом (более высокие уровни абстракции).
Это не уровни абстракции, это аспект времени, это lifecycle.

lifecycle это съесть, подарить, прокрутить через мясорубку.
а вот то что дальше следует в статье (подарок) — все таки абстракция

Дальше да, а тут нет.

С чего бы «каким образом попали к нам продукты» — это более низкая, «а что делать с пирогом потом» — более высокая абстракция?
Абстрагирование — это выделение общих свойств, обобщение, центром является общность объектов. Обратное действие — конкретизация, выделение частных свойств, то есть центром является уникальность объектов.

Приготовить пирог: купить продуктов, найти рецепт, приготовить. Это можно выразить в более абстрактном виде (убрать пирог как уникальность): пирог, как и любую другую еду, делают из исходных компонент (в случае пирога — продуктов) по инструкции (в случае пирога — рецепт). Можно в менее абстрактном виде: для яблочного пирога с корицей надо взять муки, яблок, корицы, масла, сахара и яиц. Надо замесить тесто, выложить форму, положить начинку, запечь. Можно еще менее абстрактно (более конкретно): купите 400 грамм пекарской муки типа 405, 150 грамм сливочного масла...

По моему мнению, вы путаете lifecycle с Абстракцией. На момент приготовления пирога всё, что не имеет отношения к данному процессу — неважно. Ни то, откуда поступили ингридиенты и каким образом мы их добыли, ни то, какая судьба будет у нешего кулинарного творения — это всё не играет никакой критической роли в момент приготовления — значит нечего об этом и говорить, раз оно нам не пригодится.
А lifecycle — это как раз путь, по которому прошёл наш «пирог»: сначала он был набором продуктов (первый уровень детализации), потом он стал полноценным пирогом (совершенно другой уровень детализации), а затем превратился в продукты жизнедеятельности млекопитающего (третий уровень абстракции).
Кроме того, я говорила, что каждый человек строит абстракции исходя из своих собственных соображений и представлений. Если для бизнес-задачи важно акцентирование именно на жизненном цикле некоего объекта — стоит создавать абстракции, принимающие это требование во внимание. И тогда это уже будет совсем другая история, не та, о которой я говорю.

Да, я неправильно понял вначале. Согласен.

Абстрагирование — это выделение общих свойств, обобщение, центром является общность объектов.
нет. выделение общих свойств это собственно и есть обобщение. абстракция это отвлечение от несущественных деталей.

Абстра́кция (от лат. abstractio — отвлечение) — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование — теоретическое обобщение как результат такого отвлечения.

А, я понял. В том смысле, что покупка ингридиентов — часть пирога, а пирог — часть подарка.

Беру свой комментарий обратно )

Подписаться на комментарии