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