?

Log in

No account? Create an account

Предыдущий пост Поделиться Следующий пост
Про либеральные подходы к программированию
lex_kravetski
Граждане делятся ценными сведениями:

Давайте ка посмотрим на то как ведут себя программы при модульном подходе: есть некий модуль который содержит в себе управляющий код(точка входа в программу ....) она реализует две модели при модульном подходе это либо так называемые "поток преобразования" либо "Диспетчерская" в разных учебниках по технологии программированию их по разному называют, суть их же заключается в том что при "потоке преобразования" управляющий модуль вызывает модуль который выполняет основную работу, но перед этим может выполнить некоторые преобразования входных данных, но при условии что управляющий модуль знает какие имеются вспомогательные модули, это первый ключевой момент для обеих моделей при модульном подходе. УПРАВЛЯЮЩИЙ МОДУЛЬ МОЖЕТ ВЫЗВАТЬ ТЕ МОДУЛИ О КОТОРЫХ ЕМУ ИЗВЕСТНО!

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

(источник)


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

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

Как тут строится логика рассуждений? «Я недавно прочитал книжку про ООП, а до того писал на Бейсике. Само собой, моя программа на Бейсике состояла из одного огроменного куска кода, без функций и подпрограмм. Но в книжке про ООП написано, что так писать плохо! А ООП позволяет писать хорошо! У предков не было ООП, следовательно, они наверняка писали, как я раньше на Бейсике. То есть, плохо писали».

Слава богу, положение исправилось.

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

(там же)


Вместе с объектным подходом, понимаете, к нам пришла Свобода и Демократия. Теперь подсистемы сами решают, реагировать ли им, как реагировать и зачем реагировать. Вот где успех-то: подсистема если хочет — делает, а если не хочет, так не делает. Тут вам уже не тоталитаризм, где Главный Управляющий Модуль навязывает угнетённым подсистемам свои правила. Фиг там. Любая подсистема может самовыразиться и, например, сделать всё наоборот. Ну, чтобы быть не такой как все. Неясно, правда, как при этом «Управляющий класс следит, чтобы каждая подсистема работала, как того требуется», но в этом как раз и зарыта самая-самая трансцидентальность. Подсистема реагирует как хочет, а Управляющий класс — следит. Так-то!

Если кто не понял, именно в этом самая суть ООП. Вы, дурачьё, думали, будто ООП дал нам удобный способ записи понравившихся многим программистам сценариев организации кода, а на самом-то деле он, эвон как, внедрил Свободу и Демократию.

Уже, знаете ли, хочется внедрить либеральное программирование. Ну, например, ввести конкуренцию между трэдами за процессорное время. Продажу возвращаемых значений на бирже. Тендеры среди объектов за право предоставить требуемую объектом-заказчиком функциональность. Систему импичмента методу main. Написать, наконец, Декларацию Прав и Свобод инкапсулированных сущностей. И Невидимую Руку в качестве диспетчера последовательности исполнения.

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




Вы не договорили. Невидимая рука управляющего класса обеспечивает корректную работу подсистем!

> Ну, например, ввести конкуренцию между трэдами за процессорное время.
>Продажу возвращаемых значений на бирже.
Вполне себе шедулер.
>Тендеры среди объектов за право предоставить требуемую объектом-заказчиком функциональность.
Умная прокся в распределенной системе.
>Систему импичмента методу main.
Вотчдог обыкновенный. Он и компьтер перезагрузит если надо.
>Написать, наконец, Декларацию Прав и Свобод инкапсулированных сущностей. Несогласные, надеюсь, согласятся и Каспаров ещё скажет своё веское слово по данному поводу.
Хер его знает. Каспаров для авиаторов кода не пишет.


Прокси, шедулеры и вотчдоги осуществляют тоталитарный контроль сверху. Так нельзя. Это недемократично.

(Удалённый комментарий)
(Удалённый комментарий)
По-моему, обыкновенный дурак. Ну или подросток.

угу, прочитал самоучитель с++ и возомнил себя гуру...

Фраза "исчерпывающее тестирование кода в большинстве своем не возможно выполнить" тоже дает исчерпывающие сведения об авторе.

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

(Удалённый комментарий)
(Удалённый комментарий)
"Вначале было слово". Многие думают что сначала придумывается название, а потом оно наполняется смыслом. Но такой подход библия припысывает Богу. Распростронять эту логику на мир людей конечно нельзя. У людей наоборот -- сначала появляется предмет, потом его называют. Возможно у Вашего оппонента отношение к программированию как к чему-то сокральному/божественному?

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

Re: Ответ на вашу запись...

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

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

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

Вы про ОС-РВ (RSX-11) слышали? Система работала строго от прерываний.

Алексей, вы на SECR в этом году не идёте? Там подобные выступления фурор вызывают. :)

Re: Ответ на вашу запись...

Я там вообще никогда не был.

qsort из стандартной библиотеки C дерьмо несусветное. В функцию сортировки невозможно прямым способом thread-safe передать дополнительные параметры. Вообще оба фрагмента писал какой то тупой дегенерат ничего не понимающий в программировании. Вообще если у вас есть какой то интерфейс который куда то отдаётся и работа ведётся без знания конкретного типа - у вас ООП, пусть там хоть ассемблер будет.

>> тупой дегенерат ничего не понимающий в программировании
"Кто обзывается, тот сам так и называется". -- Мне одному кажется что это про этот комментарий?

Нельзя ж так! Я чуть чаем не захлебнулся!

Как ни странно, но ООП оказало сильное влияние на неокрепшие умы. Аналогии, подобные приведённой, мне попадаются постоянно. Причём спорить с адептами практически бесполезно. Даже Н.Вирт не помогает
<<Вирт часто критикует «американский подход» к разработке средств программирования, в котором маркетинговые соображения превалируют над требованиями математической стройности и гарантированной надёжности, и каждое новое модное поветрие сопровождается некритичным внесением в языки программирования новых синтаксических элементов. Это приводит к неправильной оценке роли некоторых идей и, в конечном итоге, к неправильной расстановке приоритетов в разработке ПО. В частности, говоря об ООП, Вирт неоднократно отмечал, что оно является достаточно тривиальным расширением того же структурного подхода, сдобренным новой терминологией, и вряд ли может претендовать на звание «революционной методологии программирования». Известно ехидное замечание Вирта по поводу привычки американцев к антропоцентризму в терминологии: «Они называют расширение типа „наследованием“, но, вообще-то, наследство обычно переходит к потомку только тогда, когда предок умирает».>> На скорую руку из ВИКИ.

Я думаю диагноз обожествление можно поставить смело.
1. Фанатичная приверженность. (как Вы изволили отметить)
2. Присутствие божественного начала. (ООП появилось из небытия)

Вопрос в том кто у него Бог? Неужели УПРАВЛЯЮЩИЙ МОДУЛЬ? :)

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

Ох. Это, знаете, уже новый подтип АО. Обычно они сами что-то придумывают, а потом коряво пытаются недалёким окружающим объяснить свою Великую Истину. Но использовать вместо Истины недавно прочитанный учебник — это что-то особенное.

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

ввести конкуренцию между трэдами за процессорное время.
Оно уже давно есть и работает.

Тендеры среди объектов за право предоставить требуемую объектом-заказчиком функциональность.
Уже появляется по мере развития "облачных" вычислений.

И Невидимую Руку в качестве диспетчера последовательности исполнения.
В экономике - Невидимая Рука Рынка. А тут чья Невидимая Рука?

{выбор сервера при подключении} не компоненты делают. Это делает тоталитарный Апач или ещё кто-то типа него.
У Вас странное понятие о кластеризации. Конечно, есть кластеры по принципу MPP, когда один из юнитов распределяет задания. Но в кластерах высокой надёжности - SMP, там как раз демократия.

знаю ещё людей, которые уверены, что если что-то сделано не по шаблону из книжки, то оно, во-первых, не имеет архитектуры вообще, а во-вторых, заведомо неправильное.
А если это сделанное будет описано в очередной книжке - оно сразу обретёт архитектуру и станет правильным? (Я понимаю, что вопрос не к Вам.)

Re: Ответ на вашу запись...

>
ввести конкуренцию между трэдами за процессорное время.
Оно уже давно есть и работает.

Откуда вы эту траву берёте? Нет никакой конкуренции за процессорное время между трэдами. Время им ОС выделяет.

>
Тендеры среди объектов за право предоставить требуемую объектом-заказчиком функциональность.


> Уже появляется по мере развития "облачных" вычислений.

Ты понимаешь, про что речь-то идёт? Облачные вычисления — это создание «виртуального сервера» из нескольких. Там никто ни в каких тендерах не участвует и предоставляемая функциональность заранее известна.

> У Вас странное понятие о кластеризации. Конечно, есть кластеры по принципу MPP, когда один из юнитов распределяет задания. Но в кластерах высокой надёжности - SMP, там как раз демократия.

Друг, не надо нести херню. Из того, что в системе N процессоров, вовсе не следует, что каждый компонент индивидуальным порядком по собственному желанию подключается к любому и делает с ним, что хочет. С серверами — аналогично. Диспетчером и там тоже выступают приложения на сервере, а не подключающиеся к нему клиенты.

Это всё равно как считать, что если в министерстве много комнат и сотрудников, то это — разные министерства.

(Удалённый комментарий)
(Удалённый комментарий)
(Удалённый комментарий)
а я то, идиот, думал, что только наследование

Интересно, а тоталитарная инкапсуляция как-же? На пару с непонятным полиморфизмом. ;)

(Удалённый комментарий)
(Удалённый комментарий)
(Удалённый комментарий)
(Удалённый комментарий)