Учебный курс. Повышение качества разработки. Вводная лекция, часть 2

Программирование - Практика программирования

47
Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Лекция №2. Эта лекция посвящена абстракциям, их свойствами и практическому применению в рамках классических парадигм программирования.

Лекция №1: //xn--80appelehcm.xn--p1ai/public/828498

1 Абстракции

1.1 Что такое абстракция и чем она полезна

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

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

Методика абстрагирования интуитивно понятна, и сводится к нескольким универсальным приёмам совокупность которых и обеспечивает многообразие возможностей абстрагирования:

1. Упрощение. Ключевой метод, являющийся родительским для всех остальных. Создание упрощенной модели системы, где внимание сконцентрировано на необходимых создателю свойствах системы. Данный приём позволяет изучить поведение системы в изолированном контексте, не затрачивая усилия на построение полной и реалистичной модели.

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

3. Декомпозиция. Разложения сложных систем на компоненты, количество и индивидуальная сложность которых позволяют упросить процесс осмысления.

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

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

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,4,5 - //xn--80appelehcm.xn--p1ai/public/863471

47

См. также

Комментарии
Сортировка: Древо
1. VmvLer 24.05.18 13:22 Сейчас в теме
Не заметил в этой статье идей по заголовку-приманке

Повышение качества разработки


Ткните мне пальцем где тут идет речь о повышении качества?

По-моему это примитивная компиляция вводной лекции по программированию за 1-й курс стандартного ВУЗа, причем "прочитанная" сухо и скучно.

Ремарка
Мы еще будем рассматривать отдельные вопросы более детально, а при рассмотрении практических вопросов я буду объяснять наиболее проблемные случаи "от базиса". Но такого массива сплошной теории уже не будет. Всем, кто пережил и дочитал - дальше будет проще, дальше будет практика

зачем?

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

Мое мнение может не совпадать с мнением авторов, аудитории и бла-бла-бла.
2. Артано 624 24.05.18 13:36 Сейчас в теме
(1)
Ткните мне пальцем где тут идет речь о повышении качества?


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

По-моему это примитивная компиляция вводной лекции по программированию за 1-й курс стандартного ВУЗа, причем "прочитанная" сухо и скучно.

Если упрощать, то так и есть. С другой стороны, компиляция большого массива знаний в короткое резюме с выделением базиса, требует больше усилий, но даёт больший эффект. На первой лекции как раз рассматривались подобные проблемы восприятия действительности, под общим названием "культовое сознание".

Не проще ли было сразу перейти к практике, а не лить воду.

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

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


Я не был бы так категоричен и самоуверен, впрочем моё мнение тоже субъективно...
botokash; CyberCerber; Diplomat000; kalyaka; +4 Ответить
3. TODD22 17 24.05.18 13:38 Сейчас в теме
(1)
По-моему это примитивная компиляция вводной лекции по программированию за 1-й курс стандартного ВУЗа

Если только профильного. Но не все 1сники заканчивали профильные учебные заведения.
CyberCerber; Adam12345678; neikist; Артано; +4 Ответить
4. Артано 624 24.05.18 13:41 Сейчас в теме
(3) Горячо поддержу. И не только в 1с, вообще в IT всё больше и больше людей приходит не только без профильного образования, но и вообще без ИТ-контекста в виде хобби и увлечений.
dassin; Adam12345678; +2 Ответить
5. Арчибальд 2702 24.05.18 18:53 Сейчас в теме
(1) Когда человек начинает обдумывать то, что он делает, а впоследствии (так бывает не всегда) еще и понимать - качество продукта возрастает весьма значительно.

Обсуждение СП и ООП понравилось безусловно. Порядок (как и разруха) имеет место быть в голове, а не в подъезде (М. А. Булгаков)
6. CheBurator 3558 25.05.18 03:05 Сейчас в теме
Качество разработки начинается с того, что начиная лекцию №2 - дают ссылку на Лекцию№1... тут такого не заметил, возможно - туплю...
7. Артано 624 25.05.18 03:19 Сейчас в теме
(6) Моё упущение. В первой дал ссылку на вторую, а во второй нет. Спасибо за наблюдение
8. CheBurator 3558 25.05.18 03:26 Сейчас в теме
Почитал. Нормально. Мне полезно.
(запятых по тексту не хватает)
9. nodalt 2 25.05.18 09:02 Сейчас в теме
Автор проделал большую работу чтобы опубликовать в свободный доступ
компиляцию вводной лекции по программированию за 1-й курс стандартного ВУЗа
- уже за это спасибо! Этот базис я начал понимать только после многих лет практики. В ВУЗе это все изучал, зубрил, сдавал, но не понимал. В целом, очень полезно для новичков. Да для всех полезно. Хотя бы для того, чтобы сравнить свое понимание с видением Автора и прочих обитателей ...
Adam12345678; +1 Ответить
10. genayo 25.05.18 14:02 Сейчас в теме
К содержанию особых претензий нет, но вот с пунктуацией беда...
11. starik-2005 1400 25.05.18 14:12 Сейчас в теме
А вот я, лично, надеялся на большее от второй лекции, ибо всегда интересно, когда люди, некоторым образом знакомые с программирование, пытаются изложить его основы. Но есть конкретные придирки:
1 Упущена такая замечательная парадигма, как функциональное программирование, ибо с точки зрения математики, любая программа - это функция от входящих данных. Таким образом любую программу можно изложить в функциональном стиле, где простые и примитивные основы структурного программирования уступают место строгому языку математических функций.
2. Совершенно упущена фундаментальная вещь в ООП, которая это самое ООП и определяет. И фундаментальной вещью в нем является как раз совмещение данных и логики их обработки, преобразования и представления в контейнере класса. Без ООП такие концептуальные паттерны программирования, например MVC/MVP/MVVM, реализации поддаются с трудом; также для него написан целый, я бы сказал, стандарт - S.O.L.I.D: одна причина для изменения класса; расширение класса, а не изменение; наследование должно расширять, а не заменять класс (т.е. ПО должно работать с новыми классами без изменения логики программы); множественность интерфейсоов лучше, чем один; Зависимость на Абстракции, а не на чем-то другом. Последние две вещи по первому времени вообще неочевидны.

Ну и вообще про ООП скорее мне лично показалось, что написано с точки зрения культиста, который перешел от Свидетелей Иеговы к Баптистам, и теперь говорит о смертных грехах первых )))

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

ЗЫ: мой коллега разбирался в течение какого-то времени с HyperLeger Fabric и прочей его инфраструктурой и просто в восторге от ООП того же JQuery после 1С, на что я ему сказал, что он увидел только край зеленой поляны после засушливой пустыни, а там еще водопады есть... Ну реально, убогость 1С зашкаливает сверх всякой меры по сравнению даже с древним JS, не говоря уже о таких штуках, как JQuery, которые в этот JS просто вносят реализацию интерфейса взаимодействия с ДОМом, и это еще без BootStrap и прочих AngularJS и ReactJS...
Артано; acanta; CyberCerber; neikist; +4 Ответить
15. Артано 624 27.05.18 16:58 Сейчас в теме
(11) Про функциональное программирование - исключено сознательно. Причина та же по которой вообще появился этот курс - необходимость дать в нескольких простых определениях интуитивно понятные (а ООП именно таков) приёмы мышления.

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

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


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

P.S. Спасибо за важные дополнения, эти комментарии выполняют роль сносок "вы хотите узнать больше?"
12. CyberCerber 213 25.05.18 17:19 Сейчас в теме
По ООП в 1С

В 1с с наследованием тоже полный порядок.

Да ничего там не полный порядок. Его в 1С, можно сказать, и нет. Несколько раз надо было создавать в конфигурации набор похожих прикладных классов. Выкручивались так: создавали класс-шаблон, где были определены все общие методы и поля. Реализации методов выносились в общий модуль. Тогда наследуемый класс создавался копированием шаблона и доработкой. Это хоть как-то упрощало разработку. Но если нужно было прописать новый метод или изменить интерфейс существующего, приходилось изменять каждый из N классов.

В 1с инкапсуляция также широко представлена как в предустановленных классах, так и во вновь создаваемых.

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

Например, может существовать единая функция, принимающая параметры множества разных типов, но внутри неё для каждого типа выполняется подходящий код.

Может, я сам не до конца понимаю полиморфизм, но то, что вы описали, это как раз какой-то спагетти-код. Для полиморфизма нужно совпадение интерфейсов объектов разных классов, чтобы можно было, например, для каждого объекта из коллекции вызвать один и тот же метод, а сам объект уже его обработает по своим внутренним принципам. И для каждого класса это будет своя процедура. Это, как раз, можно решить в 1С в своих надстройках. В принципе, и стандартные классы 1С в основном поддерживают этот принцип.

В общем, затронули для меня больную тему ООП в 1С. Мне его очень не хватает.
13. starik-2005 1400 25.05.18 23:54 Сейчас в теме
(12)
В общем, затронули для меня больную тему ООП в 1С. Мне его очень не хватает.
ООП вполне можно на 1С реализовать, но это уже будет не совсем ООП.

Суть наследования в 1С - это одноразовое наследование базового класса. Т.е. создание на основе прототипа некого элемента, который уже не может быть унаследован. Т.е. от базового справочника наследуем справочник "Номенклатура", а от него уже ничего наследовать не можем (да и не нужно это в общем-то для задач, решаемых на 1С).

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

Полиморфизм для 1С, как языка без типов (хотел сказать "без костей"), "искаропки", т,е. вызывая метод экземпляра класса мы вызываем именно его метод, а не метод базового класса. С точки зрения ООП это может требовать отдельной реализации для языков с типизацией. Например, в объектном паскале это реализовывалось через виртуальный метод, который переопределялся для всех потомков в обязательном порядке.

А по поводу нехватки в 1С ООП, то решается просто:
1. Создается модуль с методами класса-прототипа.
2. Создаются модули с методами классов-потомков (Переопределяемый, СуперПереопределяемый, Перезаопределенный, ...)
3. Для совмещения логики работы с данными можно создать структуру через функцию конструктора в базовом или унаследованном модуле, которая возвращает свойство со ссылкой на общий модуль с методами.

Да, изврат, конечно, но вполне реализуемый. Товарищи сертифицированные и прочее, прочее, в БСП что-то такого чуть ли не на каждом шагу понаворотили, и те адинэснеги, кто парадигму ООП понимает только через class newClass {...}, конечно понять ничего тут не смогут (не говоря уже о тех, кто вообще об ООП что-то слышал, но не читал и осуждает) )))
17. Артано 624 27.05.18 17:10 Сейчас в теме
(13)
Суть инкапсуляции в по мнению автора в том, что в модуле и менеджере того или иного объекта есть экспортные функции, а есть функции без этого ключевого слова. Но, опять же, никто не помешает внешнему коду обратиться напрямую к полям объекта, в то время как инкапусляция этому препятствует - это ее главная функция, можно сказать.


Нет, я такого не писал:
Под инкапсуляцией (сокрытием) в контексте ООП понимается сокрытие деталей реализации методов и свойств объектов от внешней среды, с целью упростить и стандартизировать использование объектов

А так как получение свойства объекта выполняется методом получить, то это можно воспринимать просто как особенность реализации объектной модели.
16. Артано 624 27.05.18 17:03 Сейчас в теме
(12)
Может, я сам не до конца понимаю полиморфизм, но то, что вы описали, это как раз какой-то спагетти-код. Для полиморфизма нужно совпадение интерфейсов объектов разных классов, чтобы можно было, например, для каждого объекта из коллекции вызвать один и тот же метод, а сам объект уже его обработает по своим внутренним принципам. И для каждого класса это будет своя процедура. Это, как раз, можно решить в 1С в своих надстройках. В принципе, и стандартные классы 1С в основном поддерживают этот принцип.


Это один из примеров полиморфизма. Далее идет как раз описываемый пример. Полиморфизм даже в рамках ООП многозначный термин, о чем предупредил и привел два базовых варианта проявления этого свойства
18. HAMMER_59 70 28.05.18 08:04 Сейчас в теме
Первая лекция для меня была абсолютно неинтересна. Во второй лекции - для себя не узнал ничего нового, но лекция уже намного интереснее, будем надеяться, что и дальше автор будет повышать качество лекций.

Я считаю, что понятие абстракции в статье описано очень абстрактно, а следовательно теряется контекст и детали. Есть какие-то свойства, и почему-то мы их должны отбрасывать. Вот есть предмет, допустим, мяч. У предмета множество свойств: цвет, вес, форма, свойства материала, и он либо есть, либо его нет со всеми его свойствами. Как же мы можем отбросить часть свойств?
Мы можем построить модель: автомобиля, здания, ракеты. При этом модель не будет точно повторять реальный объект, мы выберем важные для нас свойства, и построим упрощенную модель. Зачем строить модель, думаю понятно, по поведению модели мы можем предсказать как будет вести себя реальный объект.
Конфигурации 1С являются экономическими моделями, т.е. реальную хозяйственную деятельность мы моделируем в упрощенном виде, т.к. реальная деятельность слишком сложна. Описать всю хозяйственную деятельность мы могли бы одним текстом, получился бы толмут на 5000 страниц, что обычно и происходит на практике. Работать, естественно с такой информации крайне сложно, поэтому текст начинают структурировать: на тома, на разделы и т.д.
В статье сложность работы с большими объемами информации преподносится как данность, сложно и все. А это ведь очень важный момент. Попробуйте запомнить десятизначное число, сложно? Как отдельный цифры, в пределах короткого времени запомнит только гений. Обычный же человек запомнит числами по 3 знака. А теперь возьмем 20-значное число, это уже 7 трехзначных чисел, и это уже на грани возможностей. Всего-то 7 трехзначных чисел, и это уже грань краткосрочной человеческой памяти.

Насчет удобности ООП - крайне однобокий взгляд. Для разработчика - безусловно удобно. А теперь представьте, открываете вы типовую конфигурацию, а там сотни объектов, естественно никак не документированных.
20. Артано 624 28.05.18 13:36 Сейчас в теме
(18)
Первая лекция для меня была абсолютно неинтересна. Во второй лекции - для себя не узнал ничего нового, но лекция уже намного интереснее, будем надеяться, что и дальше автор будет повышать качество лекций.


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

Я считаю, что понятие абстракции в статье описано очень абстрактно, а следовательно теряется контекст и детали. Есть какие-то свойства, и почему-то мы их должны отбрасывать. Вот есть предмет, допустим, мяч. У предмета множество свойств: цвет, вес, форма, свойства материала, и он либо есть, либо его нет со всеми его свойствами. Как же мы можем отбросить часть свойств?


По тексту ниже сами даёте ответ на вопрос, более кратко он дан в статье при определении абстракции. Это мысли вслух?

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


Интерфейсы есть, книжки есть, методисты есть. Неудобные интерфейсы и кривизна логики, это проблема в головах и руках, а не в концепциях.
24. HAMMER_59 70 29.05.18 06:57 Сейчас в теме
(20)
Интерфейсы есть, книжки есть, методисты есть. Неудобные интерфейсы и кривизна логики, это проблема в головах и руках, а не в концепциях.


ИМХО документация от 1С хромает на обе ноги. Я не встречал документации по программному коду типовых конфигураций. Документации для пользователей на троечку с минусом: "В справочник контрагенты заведите контрагента, в реквизит ИНН заполните ИНН".
По стандартным объектам, например СКД нет нормальной документации.
Найти полезную информацию на ИТС - это подвиг. Абсолютно не понимаю почему 1С, не развивают справку.

Как только появится ООП в 1С, весь этот бардак заиграет совершенно новыми красками.
25. Артано 624 29.05.18 07:23 Сейчас в теме
(24) ООП верное замечание. Я неправильно понял про документированность. Насчет бардака, тоже верно - ООП инструменты привнесут лишь новые проблемы. Пример приводил в разделе про структурное программирование
27. starik-2005 1400 29.05.18 11:02 Сейчас в теме
(25)
ООП инструменты привнесут лишь новые проблемы
Забыли добавить: "для тех, кто в ООП разбирается плохо или не разбирается вообще".

(24)
Как только появится ООП в 1С, весь этот бардак заиграет совершенно новыми красками.
А чем ООП в 1С усложнит восприятие кода? Сейчас в типовых изобретается свой "ООП" из-за попытки упростить код, увеличив уровень абстракции (опять же для разработчика типовых, а для рядового 1С-ника, пришедшего в отрасль из бухгалтерии или розничной торговли, это, конечно, усложнение, и ООП настоящий мог бы это упростить и для него).


ЗЫ: по поводу документации, то все есть, но, конечно, примеров не хватает. Мы в конторе планируем сделать ресурс по типу php.net с синтаксисом и примерами, куда хотим привлечь разработчиков, желающих разместить примеры кода. Тогда будет и описание объекта конфигурации, и его описание методов и свойств, и примеры со временем появятся, и, надеюсь, сообщество подключиться к оценке примеров и эта оценка определит, на сколько пример хорош. Но такие вещи, сами понимаете, за три минуты не делаются...
dassin; neikist; Артано; genayo; +4 Ответить
26. antz 29.05.18 09:38 Сейчас в теме
(18) Насчёт памяти - ну для этого и существует мнемотехника. Упаковка образов, чертоги разума и проч. Вчера, прочитав ваш комментарий, ради интереса запомнил 50-значное число. Через 3 часа его воспроизвёл, и сегодня утром тоже. Думаю, воспроизведу его и через три года.
28. starik-2005 1400 29.05.18 11:07 Сейчас в теме
(26)
Думаю, воспроизведу его и через три года.
А зачем? Если, конечно, упражнения заради, то можно, но есть упражнения куда полезнее и не только для себя. Вот, например, можете привести пример кода для какого-нибудь метода объекта 1С, чем некоторым образом поможете сообществу 1С-программистов.
29. antz 29.05.18 19:22 Сейчас в теме
(28) Практическое применение именно то, о котором вы писали - обработка и усвоение больших объёмов информации, мнемотехники это же не о запоминании чисел, а о запоминании и сортировке вообще всего.
30. starik-2005 1400 29.05.18 23:04 Сейчас в теме
(29)
а о запоминании и сортировке вообще всего.
Есть некоторым образом авторитетное мнение на тему того, что машине с абсолютной памятью интеллект не нужен - она просто будет доставать готовый ответ. А программирование - это интеллектуальные задачи, и развитие памяти мало в этом помогает (имхо, конечно). А вот логика - это да, это помогает. http://nazva.net/logic_test7/ - хороший тест на эту тему...
31. antz 30.05.18 14:10 Сейчас в теме
(30) Обычный тест на формальную логику и соблюдение правил силлогизмов. Формальная логика тоже не шибко сильно при программировании помогает)
32. starik-2005 1400 30.05.18 15:21 Сейчас в теме
(31)
Формальная логика тоже не шибко сильно при программировании помогает)
Все программирование основано на присваивании и ветвлении. Ветвление без логики - это нонсенс. Программировать - это искать причинно-следственные связи через ретроспективный анализ результата во входящие параметры.
19. awk 687 28.05.18 13:23 Сейчас в теме
По моему не раскрыт основной вопрос: "Почему в запорожце нет кондиционера как в мерседесе". Хотя ответ вроде очевиден: "Запорожец это не мерседес".
21. Артано 624 28.05.18 13:38 Сейчас в теме
(19) Запорожец была семерка. А семерка с телепатом и 1с++ - это ара-тюнинг и форсированный движок!
22. awk 687 28.05.18 14:06 Сейчас в теме
23. Артано 624 28.05.18 14:10 Сейчас в теме
(22) А як жи! Но без них никуда
33. dotPRICE.ru 48 30.05.18 17:51 Сейчас в теме
Измените заголовок Вашей статьи, например: "Типа Учебный курс..."

... или исправьте Ваши фразы: "в течении (времени)" на "в течениЕ", "Нет большой пользы с ответа " на "Нет большой пользы ОТ ответа"...

Извините, накипело.
34. starik-2005 1400 31.05.18 10:07 Сейчас в теме
(33) филфак?
Учительница русского языка, прыгая с парашютом, была обескуражена, взволнована, ... Но вслух кричала другое )))
ЗЫ: а может быть в этом деепричастном обороте запятые и не нужны, да? ;)
35. dotPRICE.ru 48 31.05.18 10:52 Сейчас в теме
Не филфак. По-моему, это пятый класс начальной школы... :)

Статья полезная и заголовок публикации "Учебный курс..." обязывает писать грамотно.
(34)
36. Артано 624 31.05.18 10:56 Сейчас в теме
(35) С замечанием про наречие согласен, при следующей правке исправлю. С предлогом нет - здесь намеренно использовал диалектный вариант нормы для повышения легкости чтения.
dotPRICE.ru; +1 Ответить
37. mitia.mackarevich 23 24.07.18 01:49 Сейчас в теме
Хороший материал. Когда читал тут же вспомнил статью Нуралиева "1С как продукт инженерной мысли" (вроде так называется). Местами есть сквозные идеи.
Оставьте свое сообщение