Граждане делятся ценными сведениями:
Давайте ка посмотрим на то как ведут себя программы при модульном подходе: есть некий модуль который содержит в себе управляющий код(точка входа в программу ....) она реализует две модели при модульном подходе это либо так называемые "поток преобразования" либо "Диспетчерская" в разных учебниках по технологии программированию их по разному называют, суть их же заключается в том что при "потоке преобразования" управляющий модуль вызывает модуль который выполняет основную работу, но перед этим может выполнить некоторые преобразования входных данных, но при условии что управляющий модуль знает какие имеются вспомогательные модули, это первый ключевой момент для обеих моделей при модульном подходе. УПРАВЛЯЮЩИЙ МОДУЛЬ МОЖЕТ ВЫЗВАТЬ ТЕ МОДУЛИ О КОТОРЫХ ЕМУ ИЗВЕСТНО!
Второй ключевой момент состоит в том что если происходят какие то изменения в системе, то управляющий модуль должен последовательно обновить, изменить или еще что то , в общем как то повлиять на всю систему и выполнить он это может только путем вызова методов конкретных подсистем, а для этого ему необходимо знать все особенности и нюансы всех подсистем. Если таких подсистем много, то выполнить синхронизацию очень сложно, к тому же если возникает у одной подсистемы необходимость повлиять на другую подсистему, то выполнить это можно только через управляющий модуль, что очень часто с ростом программной системы приводит к так называемой циклической связи между модулями, которую при модульном подходе отследить очень сложно! К тому же с ростом системы и увеличения количества подсистем, цикломатическая сложность управляющего модуля просто зашкаливает, можно конечно выполнить декомпозицию управляющего модуля, но выполнять декомпозицию можно только до какого то предела!
(источник)
Вот так вот, друзья мои. С точки зрения современников, до наступления сегодняшнего дня был адский ад. «Модульное программирование», — не смотрите, что самим своим названием намекает на концепцию «модуля», — это когда каждая программа написана в стиле «волшебный метод». До внедрения ООП все писали только так. Все подсистемы взаимодействовали между собой строго через «УПРАВЛЯЮЩИЙ МОДУЛЬ, КОТОРЫЙ О НИХ ЗНАЛ». И сам лично во всех подсистемах всё менял. Поскольку, системы подписки не существовало!!! Даже функция qsort, поди, сортировала только то, что было известно разработчикам стандартной библиотеки. И только так, как они хотели.
Мне завсегда нравятся оба замечательных подхода: объявить, что предки были умные, а мы все — дураки, и наоборот, объявить всех предков дураками, а себя лично — умным. Раз у предков не было ООП, разумеется никто из них не догадывался, что можно абстрагировать компоненты и локализовать взаимодействие между модулями.
Как тут строится логика рассуждений? «Я недавно прочитал книжку про ООП, а до того писал на Бейсике. Само собой, моя программа на Бейсике состояла из одного огроменного куска кода, без функций и подпрограмм. Но в книжке про ООП написано, что так писать плохо! А ООП позволяет писать хорошо! У предков не было ООП, следовательно, они наверняка писали, как я раньше на Бейсике. То есть, плохо писали».
Слава богу, положение исправилось.
При объектном подходе есть Управляющий класс, у которого есть события, которые оповещают о каких то изменениях, и есть подсистемы, которые при необходимости могут зарегистрировать свой обработчик данного события, в добавок каждая подсистема может указать свои события на которые может подписаться другая подсистема, что в результате приводит к тому, что у Управляющего класса нет необходимости держать в голове все особенности каждой подсистемы. В результате работа Управляющего класса сводиться к тому что бы инициализировать подсистемы, предоставить им контекст для взаимодействия и следить за тем что бы каждая подсистема работала как того требуется! А подсистемы сами решают реагировать им на какое то событие или нет, и как реагировать, что в свою очередь очень сильно упрощает дальнейшее расширение системы и делает ее более предсказуемой.
(там же)
Вместе с объектным подходом, понимаете, к нам пришла Свобода и Демократия. Теперь подсистемы сами решают, реагировать ли им, как реагировать и зачем реагировать. Вот где успех-то: подсистема если хочет — делает, а если не хочет, так не делает. Тут вам уже не тоталитаризм, где Главный Управляющий Модуль навязывает угнетённым подсистемам свои правила. Фиг там. Любая подсистема может самовыразиться и, например, сделать всё наоборот. Ну, чтобы быть не такой как все. Неясно, правда, как при этом «Управляющий класс следит, чтобы каждая подсистема работала, как того требуется», но в этом как раз и зарыта самая-самая трансцидентальность. Подсистема реагирует как хочет, а Управляющий класс — следит. Так-то!
Если кто не понял, именно в этом самая суть ООП. Вы, дурачьё, думали, будто ООП дал нам удобный способ записи понравившихся многим программистам сценариев организации кода, а на самом-то деле он, эвон как, внедрил Свободу и Демократию.
Уже, знаете ли, хочется внедрить либеральное программирование. Ну, например, ввести конкуренцию между трэдами за процессорное время. Продажу возвращаемых значений на бирже. Тендеры среди объектов за право предоставить требуемую объектом-заказчиком функциональность. Систему импичмента методу main. Написать, наконец, Декларацию Прав и Свобод инкапсулированных сущностей. И Невидимую Руку в качестве диспетчера последовательности исполнения.
Несогласные, надеюсь, согласятся, и Каспаров ещё скажет своё веское слово по данному поводу. Источник: lex-kravetski.livejournal.com.
Рейтинг публикации:
|
Статус: |
Группа: Посетители
публикаций 0
комментарий 441
Рейтинг поста:
У автора видимо весьма примитивное понимание того, что есть программирование ... а Если проводить аналогии с политическими системами то компьютер изначально тоталитарная система - имеется один или несколько процессоров живущих по принципу разделяй и властвуй ...
А вообще, в любой компьютерной системе, независимо от архитектуры, операционной системы, языка на котором писалась исходная программа и ее архитектуры, стиля и примененных шаблонов ... в конечном итоге все равно все сведется к тому что есть поток команд процессора и поток обрабатываемых данных ... все остальное иллюзия!
Просто по мере распространения вычислительных систем, количество программистов постоянно росло, а их качество соответственно так же постоянно снижалось ...
Сначала видимо кому то стало лень считать адреса и смещения команд и данных и появились программы, которые автоматически стали вычислять адреса и смещения меток и проставлять их в код ...
Потом кто то начал ныть, что ему трудно все время листать бумажные таблицы кодов машинных команд и придумали для каждой команды краткое ее название и ассемблер - программу, которая автоматически переводит названия команд в коды команд.
Затем появились те, кто начал ныть, что не может запоминать значения нужных констант (а записывать лень) и что очень муторно набирать по нескольку раз одинаковые или очень похожие последовательности команд ... кто то взял и придумал макросы, после чего ассемблеры стали макроассемблерами.
Естественно это требовало от программиста все меньше и меньше знаний и усилий, но так же естественно приводило к неуклонному снижению скорости работы программ и увеличению их размера ... так как макросы со временем пытались делать все более и более универсальными, то их применение в частных случаях становилось все менее и менее эффективным.
Дальше больше - нашлись деятели, которые заявили, что эффективность кода вообще не имеет значения, главное правильные алгоритмы! Программист не должен знать про регистры, порты ввода-вывода и ячейки памяти - он должен думать алгоритмическими конструкциями, циклами, условными ветвлениями и т.д. Так появились первые алгоритмические языки ... и дальше больше ... кто то сказал "алгоритмы фигня, главное правильная структура" и появились структурные языки ... потом кто то заявил "структура ерунда, главное правильное разбиение программы на модули" и так родились модульные языки ... ну в итоге кто то додумался до того, что правильная программа должна представлять собой набор объектов обменивающихся сообщениями - и так мир увидел объектно-ориентированные языки ...
Если когда то программистами становились только очень умные, талантливые и целеустремленные люди, то сейчас любой инвалид мозга, у кого есть компьютер может скачать какое нибудь бесплатное средство программирования, книжку типа "программирование на чем то для чайников" и через пару часов пыхтения над клавиатурой почувствовать себя крутым кодером ...
Кстати, бэйсик, на котором программировал автор, вообще то не язык для нормального программирования ... его изначально создавали, что бы сделать написание программ доступным для людей далеких от программирования ... на нем учат постигать азы программирования школьников, на него перешли математики, когда оказалось, что он удобнее и легче фортрана ...