Зачем я решил написать эту статью, даже сам не знаю. Она не претендует на научность и адресована

молодежи.Поэтому и стиль здесь отчасти шутливый. Надеюсь, что она кому-то и поможет.

Программирование вообще очень молодая штука. Ведь первая ЭВМ появилась в 1945г.

Давайте сразу, компьютер «понимает» только нули и единички. Задача программиста по сути

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

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

это может выглядеть примерно так:

              201900387  8236372  128812  8653

Абракадабра, да и только. А первые программисты именно этим и занимались.

Конечно, много так не напрограммируешь и сразу стали думать об упрощении и «автоматизации»

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

Вот наш пример будет выглядеть примерно так:

        SUM   A1  B1  C1

А что, уже лучше. На долгое время Ассемблеры стали основными «языками» так называемого

«системного» программирования и именно на таких языках писались операционные системы, компиляторы,

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

удел очень узкого круга людей, и чего греха таить, работали они на оборонку. А там нет рыночных

отношений, бизнеса и т.п. Спокойно работай и получай хорошую зарплату.

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

А там с таким «программированием» делать особо нечего, слишком дорогое удовольствие. И тут начались

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

проще, с тем, чтобы это было доступно не узкой группке «ЭЛИТЫ», а «широким массам трудящихся».

В конце концов, это привело к тому, что программирование стало массовой профессией. Но помните,

это случилось  очень даже недавно.

Если во многих видах профессиональной деятельности(да и не только) всегда были свои герои,

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

деятельности. Ну, к примеру, все знают, кто такой Эйнштейн.

А в программировании все не так. Несмотря на то, что программирование стало массовой профессией,

истинных героев и первопроходцев толком никто и не знает. Причем, даже не широкие массы а и профессионалы. Вот

кто первый придумал Ассемблер, так я, к примеру, и не знаю.

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

часто и не в одной программе, а во многих. Вот, примеру, Вам нужен Sin(X). Что, каждый раз

Вы будете расписывать фрагмент программы, который это синус и вычисляет. Накладно очень. А почему бы
не написать этот фрагмент и запомнить. Тогда Вы можете уже прямо писать

                Y=Sin(x)

а программа-транслятор уже переведет эту штуку уже в машинные коды. Вообще, транслятор, компилятор

это вообще важнейшие атрибуты программирования. Именно они переводят написанную на языке

программу в машинные коды. А кто первый придумал транслятор, процедуру – науке неизвестно,

а зря – вот кому можно было смело давать честную (не блатную) Нобелевскую премию.

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

программисткой элиты.

Первые программисты зачастую и не знали, что будет делать их программа, и для чего она вообще

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

Что, «лечить» программистов своей физикой, да напрасно, у них своих дел хватает.

Появилась проблема написания некоего «технического» задания. Что, на уровне общих фраз, это

не покатит, сразу стало ясно. Задания писались на эзоповском языке псевдокода примерно так:

   завести числовые переменные  X Y Z a b c

   сложить X Y

   результат присвоить переменной а

   и т.д.

Именно из таких псевдокодов и появились языки программирования высокого уровня.

Ясно, что если некто пишет псевдокод, как он сам понимает, то и программист может его

понять, как он сам понимает. Не дело это.

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

были скорее не программисты, а именно люди, выдававшие им задания на программирование. Наверное,

первым таким формализованным псевдокодом, который практически сразу стал языком программирования,

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

библиотек процедур практически на все задачи, связанные с математическими расчетами. Но у него

есть серьезные недостатки «косметического» порядка. Требования к написанию текстов были очень

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

колонок-столбцов и т.п. По «лингвистике» FORTRAN был ближе к Ассемблерам. Чтобы написать

некий псевдокод, нужно было проделать работу, сравнимую с работой чистого программиста.

И, к примеру, математикам-прикладникам, которые придумывали  численные методы решения уравнений

приходилось выполнять работу, близкую к работе программиста. Это отнимало много времени, да и

зачем тогда уже вообще нужен программист. Математик уже сам доведет свой «псевдокод» до

работающей программы, но при этом потеряет много времени на «не творческую» работу.

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

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

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

программирования он и не позиционировался. Установилось некое равновесие. Шустрые молодые

математики использовали FORTRAN и практически сами стали программистами. Более маститые

использовали ALGOL60. Но, это был удел относительно небольшой группы людей. Да к тому же,

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

финансировать не будет. И все разговоры о науке, о научно-техническом прогрессе – это все

от лукавого. Оборонка, вот «крестная мать»  всего этого хозяйства.

Но и бизнесу тоже ведь что-то нужно. Бухгалтерия, финансовые расчеты. Что, на счетах что ли

считать. Хотя до мощной математики пока еще далеко, хватает пока и 4-х арифметических операций.

Сами знаете, уметь читать сложные формулы, разбираться в них умеют далеко не многие. А бухгалтеров,

финансистов, менеджеров и т.п. этому особо и не учат. Если уж бизнес замахнулся на

использование компьютеров,то ему нужно что-то попроще. Так появился в США язык программирования COBOL. 

Главная цель

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

Т.е. язык программирования должен быть по возможности приближен к естественному языку. Что же, идея

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

Оператор языка COBOL выглядит примерно так( за точность не ручаюсь):

            A = B MULTIPLY C

что означает перемножить В и С, результат присвоить А.

А Вы знаете, по моим сведениям COBOL в США жив до сих пор.

По такому же принципу построен сверхмодный сейчас язык SQL.

Для таких языков иногда применяют термин «языки описательного типа».

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

«алголоподобных» языков. Назову наиболее известные. Это PASCAL, МОДУЛА, PL1,C, CLARION.

Для таких языков иногда применяют термин «языки процедурного типа».

Но все это уже история. Сейчас собственно язык программирования это игрок второго плана.

Пора уже с историей кончать, но куда же без нее. Хочу привести два факта.

Как ни странно, ALGOL60 стал настоящим языком программирования языком программирования в России.

В связке с нашим суперкомпьютером БЭСМ6 для него были написаны хорошие транслятор и компилятор.

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

Эта связка в те времена была, наверное, лучшей в мире (это примерно 1968-1980гг.)

А судьба супер-языка фирмы IBM PL1 , вообще, весьма странная. В США он толком и не прижился.

Там пробавлялись языком COBOL. Но, почему-то, в России, он стал языком №1 для знаменитой

серии ЕС ЭВМ (плоховатой копии американской IBM 360/370). А уж сравнивать COBOL и PL1 это

вообще глупо – парадокс, да и только.

Ну а теперь об объектно-ориентированном программировании. Так что же это такое. А черт его знает.

Вот в вакансиях по трудоустройству для программистов обязательно пишут – владение ООП.

Как нанотехнологии, сколько шума, а что это такое ???

Скажу сразу, хороших книжек по этой тематике мне не попадалось(хотя может и есть). А так,

особенно если среди авторов есть «чистые математики», такого накрутят такового, что хрен и

разберешься. Кстати, это везде так. Либо автор чистый теоретик и за свою жизнь ни одной

профессиональной программы и не написал, либо специально так пишет, чтобы не помогать

потенциальным «конкурентам». Так что уж попробую кратко, может меня и поймут.

Как вообще выглядит современная программа. Запустив ее, Вы видите некое окно, на котором

размещены некие «объекты»: надписи, поля для ввода, кнопки для управления и т.д.

Как все это хозяйство запрограммировать( а это всего лишь для начала). Интересный пример,

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

которая всего лишь на черный экран выводит знаменитую фразу «Hallo World».Так вот, полный текст

этой программы на языке С (С# или С++) занимает порядка 500 строк.

Как раньше программист начинал разработку новой программы – с карандаша и бумаги(позднее,

с текстового редактора). Сидел он сидел, чего-то написал  и, наконец, добрался до компьютера.

Прогнал программу и получил листинг с кучей ошибок. Взял и пошел разбираться. И так по дуге

большого круга до конца. Куча сил и времени потеряно.

Представим, что вот сейчас ему нужно начать с фрагмента, который выводит на экран стартовое

окно программы. Это Вам не «Hallo World», а гораздо сложней. Если не повезет, тот этот фрагмент

он может писать и отлаживать до пенсии. Так дело не пойдет, надо что-то придумывать.

Хотя доводилось мне встречать упертых хлопцев, которые принципиально писали такие вещи на «чистом»

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

всего лишь хобби, а не средство заработка средств на жизнь, то и флаг Вам в руки.

Сразу скажу, что для ООП чистый язык процедурного типа не пойдет. Нужна его ООП -редакция.

Для технологии ООП одного языка программирования мало. Нужен еще один продукт, для которых

придумали название BUILDER или RAD(Rapid application developer). Это здоровенная программа,

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

нового языка программирования. Что это за программы. Назову, но может быть и не все.

MS Visual Studio, Powerbuilder, C++ Builder, Delphi, может что-то еще.

Сравнивать их  и говорить, что лучше – дело неблагодарное. Все зависит от того, с чего

Вы начали и к чему привыкли. Наверное, самая популярная сейчас RAD-система это Delphi.

Много литературы, русификация, да и купить «пиратскую» программу можно в каждом подземном переходе.

Итак, начнем. Вы запускаете эту систему и перед вами здоровенное окно с кучей кнопочек и т.д.

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

надо. Просто Вы обращаетесь к хранилищу объектов, прототип окна там уже живет. Перетаскиваете его

мышкой и можете на него уже смотреть. Можете и подправить размер, цвета и т.п. Далее, перетаскиваете

поля для ввода данных, кнопки и т.п. В контейнере таких объектов хватает. А что дальше. Ну, к примеру,

разместили Вы кнопку управления. Что же будет, если будущий юзер по ней кликнет. Вот это уже Ваши

проблемы. Вы должны к кнопке прицепить уже программный код, который будет выполнять конкретные

действия, как Вы хотите. Просто для Вас откроется окошечко текстового редактора, в котором Вы и

будете вбивать текст программы, к примеру, на ООП-паскаль. Насобираете Вы приложение из таких

объектов, а далее RAD-система его соберет, откомпилирует, укажет на ошибки, если они были, да и

запустит на исполнение, если ошибок нет.

Когда я показываю это своим старым приятелям, с которыми мы вместе начинали и которые по разным

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

труда: в сотни, скромно отвечаю я. Так программирование из элитной профессии для узкого круга

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

подготовили единицы элитных программистов. Если у Вас есть желание склепать не особо сложное

приложение типа каталога архивов Ваших СД-дисков, то и проблем особых не будет. Вы сделаете его

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

не нужно. Но конечно истинная суть ООП не в этом. Попробуем кратенько разобраться.

Там появилось уже совсем новое понятие КЛАСС. КЛАСС – это в целом естественное обобщение понятия

процедуры, но в несколько другой интерпретации.

Вернемся к пресловутым синусам. Если Вы усвоили, что такое класс(это только к примеру и не

обязательно), то Вы можете замутить класс, к примеру с именем TRIGONOM. Эта штука должна взять

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

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

синус, то выглядеть это будет примерно так:

      TRIG1.XXX.YYY.Calculatesin(X,Y) 

и будет фактически исполнено X=SIN(Y).

Зачем эта муть, Вы спросите, а я и сам не знаю.

В RAD-системах так на самом деле все и делается, т.е. объект это только внешнее отображение

класса.

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

не увидите. Раньше все было проще. Ну придумали Вы процедуру, написали текст и в рамках своей

программы оформили как процедуру. Сейчас это не проходит, во-первых потому, что вашей процедурой

не могут «легко» воспользоваться другие. Ведь крупные проекты делают множество людей из разных

городов, да и стран. Если Вы делаете процедуры для большого проекта, то Вам нужно как-то переслать

свои разработки в центр, где проект собирается. Нужно иметь методику, как это делать.   

ИНКАПСУЛЯЦИЯ  - модный в ООП термин, но именно в рамках этого понятия и решаются эти проблемы.

Не будем копаться в истории, сейчас это DLL-файлы. Это бинарные файлы, в которых процедуры 

и живут. Вообще, разница между DLL- файлами исполняемыми EXE-файлами особо и не велика. Вот

разрабатываете Вы библиотеку процедур. Вам же нужно проверить, как они работают. Для этого

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

тестирования процедур. Т.е. сначала Вы имеете, вообще говоря, EXE- файл. Все проверили и затем

пересобрали это в формате DLL. Ну а далее эти DLL разлетаются по городам и весям. Преимущества

очевидны, а недостатки. Ну, прежде всего очень желательно изгнать довески, которые Вы использовали

для тестирования(они по делу не нужны и просто раздувают код). Все ли это делают – не всегда.

Далее, программа будет работать медленнее из-за большого количества обращений к внешним 

файлам-библиотекам.

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

шустрее. Можно ли это обойти, а Вы знаете, да. Хорошие RAD-системы позволяют на этапе компиляции

«вытащить» необходимые процедуры из DLL-библиотеки и напрямую включить в Вашу программу. Это

называется сборка программы в локальной моде. Т.е. Ваша программа будет прекрасно работать без

всяких там DLL. Все ли RAD-системы умеют это делать. Я не знаю, но такие есть (немного об этом

ниже). Далее, можно ли «повредить» DLL- библиотеку. Если Вы хакер, то конечно, а случайно практически

невозможно. А где же хранить классы. Сегодня это просто здоровенные текстовые файлы, которые

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

Будьте осторожны с этим. Хотя формально, если Вы цепляете класс к своему приложению, создается «копия»

этого класса.

Далее, Вы уже что-то освоили и активно работаете. И замечаете, что возможностей некоего класса Вам,

не хватает, а то еще вообще и новый класс хотите поиметь. Они регулярно появляются в  «окрестностях»

всех известных RAD-систем, могут быть платными и бесплатными. Если класс приходит от солидной фирмы,

то это обычный SETUP, запускаете и можете работать. Но бывает, что класс попадает Вам в виде текстовых

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

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

заметит. Вы должны их зарегистрировать. Как, ну везде по-разному, читайте инструкции, но это

всего лишь несколько кликов мышкой. Я думаю, легко разберетесь.

Вообще то, для «среднего» класса программистов этого и достаточно.

Ну Вы уже «крутой» и решили в некий класс добавить свой метод. Ну что же, можно.

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

написания исходных текстов добавляете свой метод. Но при этом в рамках «нового дочернего» класса

будут доступны стандартным образом все методы родительского класса. В «теории» ООП это называется

наследуемость методов.

Ну, а если Вы вовсе крутой, то можете написать и полностью свой класс. А что, если получится удачно,

можете его продать. Пустяк, а приятно.   

Все ли это, да нет, иначе вокруг ООП не было бы столько шума. Есть еще некое понятие.

Это ПОЛИМОРФИЗМ. Не так-то просто понять, что это такое, но и история полиморфизма

тянется издалека.

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

    S string
    R real
    D decimal
    . . . . .
    D= S*R

Транслятор Вас сразу отругает, типа «неправильная операция над типами даны». И это правильно.

Но почему, если

     S=’123,986,124.78’

то это в принципе число и такая операция логична.

И языки программирования иногда стали такие конструкции пропускать. Но если в строке появятся

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

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

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

то и слава богу. Если нет, Ваша программа завершится уже не с системным ABEND, а с Вашим

сообщением типа « . . .туда пришли некорректные  данные . . .». И у юзера уже к программе
претензий и нет.

Такое часто бывает, если программа обрабатывает внешние текстовые файлы и Вам нужно данные

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

ПАРСИНГ, а что, забавно. И уж совсем хорошо, если при вылете программы Вы укажете, в строке с

каким порядковым номером это произошло.

Но все было бы слишком просто, если бы полиморфизм этим и ограничивался.

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

Я был далеко не зеленый, но эта статья многое мне прояснила и прочистила мозги.

По-больше бы таких статей.

Итак, нам нужно сделать класс для вычисления площади многоугольника. Казалось бы, чего проще.

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

по формуле Герона, а потом складываем. Но этот метод весьма сложноват, особенно, к примеру, для

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

запустив класс с параметрами(длины сторон), он сам определит, какой метод лучше. Если это квадрат,

то вычислит мгновенно, если что-то эксклюзивное, то повозится подольше.

Вот в этом то и есть инновационная суть ООП. Но все это весьма и весьма сложно. Если класс запутается

с параметрами, то такого «навычисляет», что мама не горюй.

Можно сказать, программирование полиморфных классов – это высший пилотаж в нашем скучном деле.

Ну, наверное, это и все. Осталось выбрать RAD-систему и начинать.

Вот какую, это Вам решать. Сейчас наиболее популярна Дельфи. Но есть у ней серьезный недостаток.

В свое время автор языка ПАСКАЛЬ -  знаменитый Вирт, позиционировал его не для промышленных разработок,

а для обучения студентов программированию(для промышленных применений у него есть версия МОДУЛА,

о которой толком мало кто и знает). Следствие – совсем простенький компилятор. А в результате

программы  на Дельфи жутко тормозные и огромны по размеру, не очень надежны. Но прижились, что делать.

А на чем же работаю я. Уже много лет на системе CLARION. Могу ли я Вам ее рекомендовать. Вообще то,

поостерегусь.

Достоинства CLARION в необычайно большой функциональной насыщенности (уж классов и методов там

выше крыши), но не это главное. Главное достоинство – наличие сверхмощного компилятора(к его разработке

приложил руки некий Йенсен – основатель сверх знаменитой фирмы БОРЛАНД – ну все про нее слышали).

Как следствие, программы на CLARION очень компактны, очень надежны, а главное, сверхбыстрые.

А о недостатках, ну это в основном из иной сферы. Попробую перечислить:

  труднодоступность – это Вы Дельфи( и иже с ними) купите в любом подземном переходе. Здесь это не так.

        можно конечно официально купить (единственный официальный дилер – фирма Арсис).

        Но когда Вы посмотрите на цены, Вам плохо станет. А что, хороший продукт и стоить должен дорого.

  практически полное отсутствие всяких русификаций и уж полное на официальном уровне. Кое-что делают

        энтузиасты на общественных началах, но это очень и очень мало.

  полное отсутствие литературы. Только формальная документация на английском языке.

  трудное освоение – к примеру, Дельфи, не в пример проще.

Так что может Вы до CLARION и не доберетесь.

А вообще, стоит ли заниматься программированием. Может уж лучше менеджментом, юриспруденцией,

маркетингом, финансовой аналитикой. Модно это сейчас, но надолго ли. А IT-технологии сейчас вписались

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

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

В лучшие времена программисты зарабатывали много.

Ну и напоследок повеселю Вас немного. Немного грустный анекдот из программисткой жизни.

Некая программистская контора, работает на системе ПАРАДОКС (есть такая). Производственное помещение.
Бродит по нему сотрудник и вслух бормочет: парадокс . . . парадокс
Сотрудники его спрашивают, мол, чем тебя  ПАРАДОКС то достал. Вроде работаем и ничего.
Ответ, да не в ПАРАДОКС дело. А тогда в чем. Понимаете,
  спрашиваю я дочь, можешь отдаться за 100 долларов – отвечает -  легко . . .  – парадокс
  спрашиваю жену, можешь отдаться за 1000 рублей -  отвечает – конечно, деньги нужны . . . – парадокс
  спрашиваю тещу, можешь отдаться за 100 рублей – отвечает- с удовольствием . . . – парадокс
Коллеги спрашивают, так в чем парадокс то. Как в чем – полный дом блядей а денег нет ни хрена - парадокс