Статья №1: //infostart.ru/public/828498
1 Абстракции
1.1 Что такое абстракция и чем она полезна
В последующем мы будем часто обращаться к понятию абстракции. Чтобы не путаться в множестве внешних признаков, предлагаю сразу определиться с понятиями. Абстракция — это способ восприятия объектов и явлений путем построения их упрощенных и обобщенных моделей.
Таким образом, можно обойти физические ограничения на объем обрабатываемой информации в единицу времени. Именно эта экономия в своё время и привела к эволюционному скачку человечества. Во времена, когда мозг наших предков еще не слишком отличался от животных, они смогли в буквальном смысле прыгнуть через голову и научиться обрабатывать в уме сложные системы простыми способами. При этом абстракция стала частью нашего мышления, и если попробовать разобраться в своих представления и мировосприятии, то окажется, что всё построено на абстракциях – так действительно проще. И отсюда мы можем сделать вывод, что технических ограничений для абстракции как метода познания не существует. Конечно, пределы абстракции существуют, но их границы совпадают с границами человеческого восприятия, поэтому об ограниченности абстракции можно говорить только абстрактно :-)
Методика абстрагирования интуитивно понятна, и сводится к нескольким универсальным приёмам, совокупность которых и обеспечивает многообразие возможностей абстрагирования:
Упрощение.
Ключевой метод, являющийся родительским для всех остальных. Создание упрощенной модели системы, где внимание сконцентрировано на необходимых создателю свойствах системы. Данный приём позволяет изучить поведение системы в изолированном контексте, не затрачивая усилия на построение полной и реалистичной модели.
Обобщение.
Выделение группы сходных свойств для группы систем с последующим выделением их в обобщенную модель. Позволяет анализировать большие объемы условно однотипных данных, не останавливаясь на разборе каждого элемента.
Декомпозиция.
Разложения сложных систем на компоненты, количество и индивидуальная сложность которых позволяют упросить процесс осмысления.
Сочетание указанных методов позволяет «оставить за скобками» неизвестные или сложные для понимания детали систем, и работать с их упрощенными моделями. Через обобщение мы сможем обрабатывать большие массивы данных. Любая сложная задача, интуитивно решается повышением абстрактности моделей. Сложную многоукладную систему можно разделить на слои, каждый из которых вполне поддаётся осмыслению, что позволит охватить целиком даже большие и сложные системы. Вошедший в народный фольклор «сферический в вакууме конь» является ярким примером прикладного применения абстракций. Конечно, низкая точность модели очевидна даже далёкому от физики человеку, но точности «сферического коня», как правило, хватает для подавляющего большинства бытовых и производственных вычислений.
Таким образом ключевое значение абстракции в мыслительном процессе — это экономия умственных усилий при обработке систем. Как мы будем использовать сэкономленные калории и время, зависит уже от нас. Например, наши далекие предки, смогли увеличить полезный объем умственной работы, и использовали это для улучшения условий своей жизни.
1.2 Вредны ли абстракции?
Мы только что рассмотрели полезные свойства абстракций и убедились в их безграничном потенциале, но есть ли у абстракции побочные эффекты и может ли абстракция принести вред? Абстракции, в силу своей тотальной распространенности не могут не приносить вред, просто по законам статистики. Поэтому множество частных случаев вреда от абстракций мы рассматривать не будем. Но есть у абстракции и системные проблемы, без понимания которых, есть риск утратить контроль над абстракциями.
То, что даёт преимущества абстрактному мышлению, несет в себе и противоположный эффект. Да, абстракция позволяет легко держать в уме сложные системы, но можем ли мы быть уверены, что модель достаточно полная, и не содержит изъянов, могущих привести к большим неприятностям? Можно ли быть уверенным, что две абстрактные модели, хорошо работающие поодиночке будут так же эффективны при совместном использовании? Очевидно, что преимущества абстракции, также являются её недостатками, и не могут быть легко устранены.
Аксиома 1. Абстракции ложны.
Причем ложны они как в теоретическом, так и сугубо практическом смыслах. Любая абстракция, будучи применима к достаточно большому числу систем, рано или поздно даст сбой.
Следствие из аксиомы 1.
Абстракцию можно оценивать по числу исключений или по риску возникновения исключения и тем самым признавать её годной или негодной. Кстати, это еще один слой абстракции, к которому в свою очередь применимы аксиомы и следствия.
Аксиома 2. Абстракции недолговечны.
Модели строятся для удовлетворения нужд текущего момента в представлениях и понятиях текущего момента, даже если эти нужды обращены в будущее. Исключения существуют, но подтверждают это утверждение – как правило — это настолько примитивные (неделимые атомарные) модели, что устареть они могут лишь в конце времён.
Следствие из аксиомы 2.
Изменение среды может привести к изменению адекватности модели оригиналу, вплоть до полного несоответствия.
Негативные последствия указанных проблем, каждый из нас может наблюдать не только на работе, но и во всём окружающем мире. В связи с этим, необходимо принять абстракцию как меньшее из зол, потому что альтернативой может быть только неупорядоченный хаос. Используя понимание сущности абстракции, нам остаётся смириться с их недостатками и пытаться избежать их негативных последствий. При построении абстрактных моделей нужно всегда помнить, что абстракция — это не сама система, а наше представление о ней. Нельзя всецело доверять фантазиям, можно лишь использовать их как инструмент, не забывая о реальном мире.
2 Парадигмах программирования
В этой лекции я хотел бы рассмотреть важные для курса парадигмы программирования – структурное программирование (СП) и объектно-ориентированное программирование (ООП). Чтобы не спровоцировать священную войну, по традиции предлагаю определиться с терминами и понятиями.
Самое главное определение, которым я планирую обезоружить религиозных фанатиков это определение термина "парадигма программирования". Парадигма в общем смысле понимается как набор неких шаблонов и внутренних правил, применяемых к инструментам познания. Иными словами, парадигма просто предлагает нам способ организации наших умственных усилий в рамках определенных правил. Применительно к программированию, парадигма определяет методологию разработки, связность и способы представления её различных частей, тогда как причиной частых споров становится подмена методологии инструментами. Приведу пример из строительства. Прессованную фанеру рекомендуется закреплять при помощи шурупов. Шуруп можно закрутить отверткой или шуруповёртом. Разумеется, в большинстве случаев, шуруповёрт на порядок удобнее и эффективнее, но его отсутствие не означает, что закрепление фанеры будет произведено не по технологии. Потому и фраза "в 1с нет ООП" лишена смысл, так как здесь перепутаны стили программирования с конкретной средой разработки. Можно сказать, что где-то больше инструментов для программирования в стиле ООП, а где-то меньше, но концепция существует отдельно от них.
2.1 Структурное программирование
Базовые принципы структурного программирования
В соответствии с парадигмой структурного программирования программный код организуется с помощью трёх специальных конструкций:
Следование – выполнение операторов программы в последовательности написания один за другим.
Ветвление – выполнение различных операторов, в зависимости от заданного условия.
Цикл – многократное выполнение операторов, до тех пор, пока выполняется некое условие.
Остальные принципы явно следуют из описания структур, поэтому не будем их рассматривать сейчас. Обратите внимание насколько просты и масштабируемы эти принципы. Их простота, может дать ложное представление об их естественности, но это далеко не так. Это такая же абстракция, как и все остальные методы и приёмы программирования. Следовательно, их применение, всегда требует некоторых умственных усилий.
Здесь мы могли бы закруглиться и перейти к следующей теме, если бы я не встречал проблем с «пониманием основных принципов структурного программирования», поэтому по традиции отпрыгнем в прошлое и рассмотрим основы с поправкой на культовое сознание.
Актуальность структурного программирования
Много лет назад, я молодой специалист попал на свою первую настоящую работу. Один из первых прочитанных мною документов запомнился мне на всю жизнь. Документ этот назывался «Должностная инструкция инженера-программиста», и сам по себе ничем, кроме обстоятельности не примечателен, но на истории моего отношения к этому документу можно было отследить вехи профессионального и личного роста.
В частности, там была замечательная фраза «программист должен понимать основные принципы структурного программирования». Реакция моя была в стиле «ха-ха, динозавры! Уже давно рулит ООП, а они цепляются за какие-то архаизмы из курса по истории программирования». Справедливости ради стоит сказать, что инструкция действительно была разработана в 80-х годах. Но со временем, я эту смешную и даже наивную фразу я стал воспринимать по-другому.
В первых, я довольно быстро понял, что был неправ. Пришло осознание, что я мыслил штампами и был беззаветным адептом «культа Карго» и не понимал принципы структурного программирования, хотя активно ими пользовался. По существу, структурное программирование, есть базис для всего современного программирования. Пусть его принципы были сформулированы давно, но принципы эти просты и универсальны так же, как архитектура фон Неймана. Классические принципы, сформулированные во времена засилья оператора GoTo, в некоторых своих рекомендациях несколько устарели. Но концепция структур кода и большинство рекомендаций актуальны и по сей день. Ведь принципы структурного программирования выполнимы и выполняются в данный момент, и сама парадигма не устарела, а эволюционировала переходом в надсистему, в том числе в ООП-подобные парадигмы.
Во-вторых, со временем я убедился, что даже в наши дни далеко не все применяют эти самые принципы, не говоря уже про понимание. Даже в недавние годы мне приходилось видеть классический «спагетти-код» - многостраничные методы сплошного неструктурированного кода с активным использованием безусловных переходов, но при этом, упакованные в классы и объекты. Конечно, это характерная проблема быстрого роста, но тем острее необходимость в привитии производственной культуры массам новых разработчиков, зачастую не имеющих систематического профильного образования. На мой взгляд, формулировка «должен понимать основные принципы» слишком гуманна и ни к чему не обязывает программиста. Программист обязан глубоко понимать и применять принципы СП. Без понимания основ, использование более сложных инструментов будет в лучшем случае не таким эффективным, а в худшем и наиболее распространенном – вредным.
2.2 Объектно-ориентированное программирование
Популярность споров про ООП отчасти напиталась недобросовестными менеджерами по маркетингу, сделавшими ООП модным словом, употребляя которое, необязательно было знать его значение.
Во-первых, ООП это всего лишь обобщение накопленного опыта программирования и формальное описание приёмов и рекомендаций. Таким образом ООП само по себе не являлось каким-то инновационным прорывом, потому что все его составные компоненты и подходы уже применялись в течение длительного времени до появления моды на ООП.
Во-вторых, методология ООП не является чем-то незыблемым, и говоря сейчас ООП, я подразумеваю целый класс методик и подходов, являющихся родными или двоюродными братьями оригинального ООП.
Ключевой признак, который может определить методику ООП это радикальное повышение абстрактности программы с целью упрощения её логической модели. При этом суммарная сложность повысится многократно, но так как рассмотрение программы идет по уровням абстракции, то субъективно происходит значительное упрощение. Классическое определение про инкапсуляцию, наследование и полиморфизм можно разбирать в течение нескольких часов, но так или иначе это сводится к принципу «больше абстракций для бога абстракций». Что характерно, то старые программисты это считали чем-то само собой разумеющимся, и не нуждающимся в отдельных развернутых пояснениях. Но их молодая смена уже восприняло картину мира рекламных слоганов как объективную реальность и с увлечением ввязалась в серию религиозных войн.
Чтобы не спровоцировать еще одну, сделаю финальное определение о сущности ООП: ООП есть средство повышения абстракции логической модели программы, путем создания неких специализированных сущностей (объекты, классы, агенты – множество их), совокупность поведения и свойств которых и определяет структуру программы.
Таким образом, ООП не является ни мифом, ни сколько-нибудь физической сущностью – это всего лишь способ мышления, стиль написания кода и проектирования систем. Разумеется, любая теория, в результате практического применения обрастает инструментами, доказательствами и опровержениями отдельных её положений, но при этом сама суть теории от этого не изменится. В качестве «эпиграфа, сознательно вынесенного в эпилог» приведу фразу, однажды сказанную мною по поводу очередного спора на тему что 1С нет ООП: "глядя на код некоторых из спорщиков, можно сказать, что в 1С нет даже структурного программирования".
2.3 О применимости ООП в 1с
В предыдущем разделе мы рассмотрели глубинную сущность ООП – существенный рост абстрактности программ. Но для закрепления этого базового понимания, необходимо рассмотреть классическое определение ООП и попробовать примерить его на реальность 1с инфраструктуры.
Классическое определение ООП сводится к описанию объектной модели из классов и объектов обладающей следующими признаками: наследование, инкапсуляция, полиморфизм. Существует бесчисленное число уточнений и определений каждого свойства, что вполне нормально, так как простой, по существу, шаблон начали широко применять и впоследствии толковать, и дополнять.
Предлагаю рассмотреть каждый термин в отдельности, его смысл и место в концепции ООП.
Классы
В большинстве концепций одно из двух центральных понятий. Класс может содержать описание методов и свойств, может иметь родительские и подчиненные классы. Говоря простым языком, класс представляет собой некоторый шаблон-заготовку, образец для коллекции объектов, но объектом в терминах ООП не является. Возьмем для примера телевизор у вас в комнате. Если рассматривать его как экземпляр бытовой техники, то его место может выглядеть примерно так: Объект «телевизор марки N», является экземпляром класса «Телевизоры марки N», входящим в класс «Телевизоры с дисплеем X» и так далее. С другой стороны, если представить этот же телевизор предметом интерьера, то он может быть экземпляром класса «Бытовая электроника» с совершенно другим набором свойств. Одна и та же физическая сущность может быть описана любым количеством классов – в зависимости от контекста, точки рассмотрения и необходимой детализации.
В реалиях 1с дать определение класса еще проще – базовые классы уже предустановлены и поставляются с платформой: справочники, документы, регистры, системные коллекции и многое другое.
Объекты
Центральное понятие ООП. Именно на объекты и призывает ориентироваться рассматриваемая парадигма. Объект является аналогом физического объекта или явления. Он индивидуален и может обладать уникальными значениями свойств, но сам набор свойств определен в классификации этого объекта. В реальном мире объектом можно представить человека как представителя вида Homo, тогда как классом назвать «человекообразных обезъян», входящим в свою очередь в класс «Приматы» и.т.д. Все люди принадлежат одному биологическому виду с одинаковым набором свойств, включая унаследованные от родительских классов, но каждый человек является индивидуумом обладая уникальным набором значений свойств.
В 1С, существует некоторая путаница с понятием объект. В некоторых случаях он применяется в строгом ООП-смысле, но иногда и в специфичном для 1с. Также существует ветвление структуры объектов и создание внешне похожих, но различающихся внутри объектов. В качестве примера могу привести элемент справочника. Объектом c точки зрения ООП является как, собственно, СправочникОбъект, так и его ссылка (ID) на запись в БД, обернутая средствами платформы в свойства и методы, позволяющие работать с записью БД интуитивно понятными средствами.
Этот пример также демонстрирует одну из системных проблем абстракций, когда модель неадекватна реальной системе. Интуитивно понятно, что, обращаясь к внешнему свойству объекта мы ничего предосудительного не делаем, но на практике, получение свойства для СправочникСсылка — это запрос к серверу базы данных, а не обращение к определенному участку оперативной памяти.
Наследование
Важное свойство объектной модели. Смысл этого свойства состоит в том, что дочерние классы имеют возможность унаследовать свойства и методы от родителей. Таким образом избавляя программиста от возможности описывать одни и те же сущности каждый раз при описании похожих объектов. В 1с наследование присутствует в . Те классы что определены и существуют, вполне успешно передают свои свойства и методы дочерним структурам. Например, общий для класса «Справочники» метод «СоздатьЭлемент» вполне успешно наследуется на все новые подчиненные классы. Как нетрудно заметить это очень удобный механизм для построения абстрактных моделей.
Инкапсуляция
Под инкапсуляцией (сокрытием) в контексте ООП понимается сокрытие деталей реализации методов и свойств объектов от внешней среды, с целью упростить и стандартизировать использование объектов. В качестве примера из реального мира могу привести любой интерфейс с кнопками и рычагами. Нажимая на кнопку питания какого-либо устройства, вы не утруждаете себя выполнением последовательности действий, приводящих к запуску устройства – вы просто нажимаете на кнопку «Включить». Таким образом можно легко обращаться с самыми разными устройствами, если они снабжены стандартизированным интерфейсом, а их внутренняя логика инкапсулирована внутри объекта. Как следствие объект может с вами взаимодействовать только посредством программного интерфейса предусмотренного создателем класса, что обеспечивает предсказуемость поведения и теоретическую возможность предоставить гарантию определённого уровня качества. В 1с инкапсуляция также широко представлена как в предустановленных классах, так и во вновь создаваемых. Используя ключевое слово Экспорт для свойств и методов, разработчик может создавать программные интерфейсы объектов, инкапсулируя внутреннюю логику.
Инкапсуляция свойств объектов являющихся реквизитами метаданных, не предусмотрена. Предполагается, что, добавляя такой свойство, вы всегда будете использовать его для просмотра и изменения извне. Это может создать опасные ситуации, поэтому не стоит забывать о такой особенности платформы.
Полиморфизм
Это довольно многозначное понятие, но, чтобы упростить восприятие, дам упрощенное определение. Полиморфизм - есть способ организации обработки данных, когда для множества разнотипных данных может применяться один и тот же интерфейс. Способы достижения этой цели могут быть различны:
Например, может существовать единая функция, принимающая параметры множества разных типов, но внутри неё для каждого типа выполняется подходящий код.
Также сама структура объектов может организована так, что может быть обработана единым механизмом. В качестве примера подобной абстракции можно привести работу файловой системы на уровне пользовательского интерфейса. Когда вы копируете группу файлов из каталога в каталог, вам не нужно анализировать типы и содержимое файлов, вы просто переносите файлы, будь то документы, изображения или видео.
Выводы о применимости ООП в среде 1С
Как многие из вас смогли убедиться, перечисленные признаки вполне узнаваемы и в 1С, а сами парадигмы составлены простыми и понятными принципами, что позволяет их применять не столько как средство разработки, сколько как способ мышления при разработке. Это вовсе не означает, что 1С является полностью комфортной средой для работы в стиле ООП. Имея знание о существующих инструментах, бывает мучительно больно решать задачи без них. Не зря в начале раздела я привел пример с отверткой и шуруповёртом. В некоторых случаях буквально устаёт рука вкручивать сотни шурупов простой «отверткой». Например, очень не хватает возможности определения произвольных классов непосредственно в модуле разработки. Можно использовать некоторые ухищрения, но они как правило или не слишком удобны, что нивелирует смысл их применения, либо плохо влияют на производительность. Также применение нестандартных методик будет дорого стоить при расширении или замене команды разработчиков. Но так или иначе, в большинстве же случаев, в 1С не приходится писать настолько много, чтобы иметь существенные проблемы от отсутствия некоторых ООП-инструментов, а применение хорошего стиля в разработке, позволит облегчить процесс чтения.
3 Заключение
В этой лекции мы рассмотрели определение абстракции, определили её основные свойства, достоинства и недостатки. Мы убедились, что абстракция является главным инструментом в мыслительной деятельности, что требует соблюдения некоторой осторожности при использовании. В прикладной сфере, повышение уровня абстрактности показано ключевым способом повышения производительности умственного труда. На примере двух классических парадигм программирования, показано практическое применение абстракций.
Во второй части лекции подробно рассматривались свойства и методология концепций структурного и объектно-ориентированного программирования. Показана ключевая роль концепции СП как базового для программирования в целом. Рассмотрена применимость ООП 1С с общим выводом об отсутствии каких-либо противопоказаний, если ООП воспринимать как концепцию и стиль мышления, а не набор инструментов.
О последующих лекциях
Две первые лекции, являются последними чисто-теоретическими лекциями. Я старался излагать мысли максимально компактно, не отвлекаясь на детали, но понимаю, что некоторые вещи могут читаться и пониматься сложно. Вводная строго теоретическая часть была необходима для погружения в сам курс. Никакие практические опыты не могут быть действительно полезны без понимания базиса. Нет большой пользы с ответа на вопрос "как", если нет ответа на вопрос "почему".
Мы еще будем рассматривать отдельные вопросы более детально, а при рассмотрении практических вопросов я буду объяснять наиболее проблемные случаи "от базиса". Но такого массива сплошной теории уже не будет. Всем, кто пережил и дочитал - дальше будет проще, дальше будет практика :-).
Отдельное спасибо всем, кто писал комментарии, в том числе критические. Это помогает улучшить материал и обратить внимание на не обозначенные акценты в многозначных терминах и обобщениях.
Статья 3 - //infostart.ru/public/863471
