Редактирование: Парадигмы программирования, 11 лекция (от 03 декабря)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
| Текущая версия | Ваш текст | ||
| Строка 27: | Строка 27: | ||
Теперь мы заговорили на событийно-ориентированное программирование. Известно, что событийно-ориентированные программы приятне всего писать на ОО-языке. Ещё со времён smalltalk'а. Тогда же появилась Симула, которая предназначалась для имитационного меоделирования и хорошо для него подходит. Неоднократно лектору приходилось встречаться с таким утверждением: ООП не более чем разновидность императивного программирования. Утверждение неверное категорически. Откуда оно берётся? Скорее всего из того, что ОО-языки в большинстве своём императиные. С другой стороны, есть Common Lisp Object System [http://en.wikipedia.org/wiki/Common_Lisp_Object_System], но никто же не утверждается, что ООП — это слегка измененное функциональное программирование. Поэтому ОО не является ни функциональным, ни императивным программированием. Как доказать это: для ОО-программирования присваивание является возможностью посторонней. В чистом ОО присваивание быть не может. Что такое присваивание? Это полная замена состояния переменной. Теперь вспоминаем, что такое ООП? В ООП среда выполнения программы представляет как набор чёрных ящиков, называемых объектами, т. е. системами, с внутренностями которых нельзя ознакомиться, только со внешними проявлениями. Известно, что объект может принимать сообщения и отвечать на них. При этом он можнет изменять собственное состояние и обмениваться с другими объектами сообщениями. При этом мы не знаем, сменил ли объект состояние полностью или нет. Потому что это нарушает принцип инкапсуляции. Поэтому присваивание в чистом ОО быть не может. Если же допускается, то это означает, что ЯП поддерживает не только ООП. | Теперь мы заговорили на событийно-ориентированное программирование. Известно, что событийно-ориентированные программы приятне всего писать на ОО-языке. Ещё со времён smalltalk'а. Тогда же появилась Симула, которая предназначалась для имитационного меоделирования и хорошо для него подходит. Неоднократно лектору приходилось встречаться с таким утверждением: ООП не более чем разновидность императивного программирования. Утверждение неверное категорически. Откуда оно берётся? Скорее всего из того, что ОО-языки в большинстве своём императиные. С другой стороны, есть Common Lisp Object System [http://en.wikipedia.org/wiki/Common_Lisp_Object_System], но никто же не утверждается, что ООП — это слегка измененное функциональное программирование. Поэтому ОО не является ни функциональным, ни императивным программированием. Как доказать это: для ОО-программирования присваивание является возможностью посторонней. В чистом ОО присваивание быть не может. Что такое присваивание? Это полная замена состояния переменной. Теперь вспоминаем, что такое ООП? В ООП среда выполнения программы представляет как набор чёрных ящиков, называемых объектами, т. е. системами, с внутренностями которых нельзя ознакомиться, только со внешними проявлениями. Известно, что объект может принимать сообщения и отвечать на них. При этом он можнет изменять собственное состояние и обмениваться с другими объектами сообщениями. При этом мы не знаем, сменил ли объект состояние полностью или нет. Потому что это нарушает принцип инкапсуляции. Поэтому присваивание в чистом ОО быть не может. Если же допускается, то это означает, что ЯП поддерживает не только ООП. | ||
| - | С ОО, поговорим о нём ещё. Более практическая терминология заменяет понятие отправки | + | С ОО, поговорим о нём ещё. Более практическая терминология заменяет понятие отправки сообщ. на понятие "вызов метода". Ответ на сообщ. --- рез-т вызова метода. Теперь чуть дальше. В ОО есть классы. Это нечто, фабрика объектов, экземпляров класса. То есть классы это что-то, позв. созд. объекты, один. по внутр. устройству. Отсюда класс есть множество объектов. Конечно, не любое множ. объектов явл. классом. В таких терминах можно опр. понятие насл. Когда мы насл., то мы добавляем свойства. Это озн., что мы множество сузили. КОгда мы сужаем множ., то мы можем сказать что-то дополн. о них. При этом A ⊃ B. |
| - | + | Ntgthm ktrnjh cj,cndtyyj [jntk crfpfnm ghj to` jlye byn/ ghfflbuve? njxytt? rkfcc zpsrjd/ Есть класс языков, по крайней мере, больш. из них явл. импер., языки эти наз. командно-скриптовыми. С т. з. лектора, к-с языки опр. тремя моментами: | |
| - | * Строка — наше всё. Строка текста как | + | * Строка — наше всё. Строка текста как универс. предст. для любых типов данных, а также самой программы. |
| - | * Развитые и легко применимые средства запуска | + | * Развитые и легко применимые средства запуска внеш. программ и упр. ими. |
| - | * (в принципе, | + | * (в принципе, явл, соедствием первого) Функция eval. |
| - | Почему eval возник здесь? Потому что для кода и для данных одно | + | Почему eval возник здесь? Потому что для кода и для данных одно предст., и м может во время предст. слепить кусок кода и подать его на вход интерпретатору. Где такое ещё есть: в lisp. |
| - | Кто-то может сказать, что | + | Кто-то может сказать, что стр. не явл. общим предст.. Есть такой язык tcl, раньше это было так, сейчас не совсем, но есть полная иллюзия того, что работа всё равно со строками. Когда это становится видно: когда его встраиваем или расширяем. Тогда мы видим, что там возн. полиморфные объекты, но внутри это не видно. |
| - | Что здесь интересно: в КС языках очень интересна скорость разработки. Благодаря тому, что есть простое | + | Что здесь интересно: в КС языках очень интересна скорость разработки. Благодаря тому, что есть простое ср. упр. внешними программами, то можно их очень быстро слепить. Более того, если мы возьмём КС-язык, который из. был придуман как язык упр. заданиями, тот же самый bourne shell, то там мы можем обнаружить такую вещь, как алгебру программ. Так вот, если рассм. как некий обхект со стандартным вводом, выводом и командной строкой, то можно заметить два способа суперпозиции: конвейер и обр. апострофы. |
| - | Кроме того, это | + | Кроме того, это позв. связывать программы, в том числе, написанные с исп. разных парадигм. |
| - | Последнее, что лектор хочет сказать: а давайте | + | Последнее, что лектор хочет сказать: а давайте посм. внимательно на понятие ascii-текст. Вообще, это понятие может использ. для хроанения чего угодно, это своевременно обнаружили, и в результате большинство протоколов текстовые, конфигурационные файлы текстовые. Что это позв? Встраиваться программисту в цепочку работы программ, например, в целях отладки. Кроме того, ascii есть везде, а с юникодом и кодировки есть варианты. Если же это ascii, то мы это всегда увидим. Кроме того, можно взять бинарный файл и вычленить из него строки. Для этого есть, например, команда strings. |
В любом случае, лучше про ascii не забывать, и очередным подтверждением является то, что в юникоде каждый символ имеет имя, причём заглавными латинскими буквами. | В любом случае, лучше про ascii не забывать, и очередным подтверждением является то, что в юникоде каждый символ имеет имя, причём заглавными латинскими буквами. | ||
{{Парадигмы программирования}} | {{Парадигмы программирования}} | ||
