Сверху или снизу? Сверху!!!
Запись от CoderHuligan размещена 22.02.2021 в 10:46
Показов 8668
Комментарии 45
|
Как проектируют программные системы? Обычно существует два основных подхода к написанию (проектированию) программ. Один из них так называемое проектирование сверху, другой - снизу. Философию создания снизу, как известно, проповедовали фортисты или фортеры - поклонники языка Forth. Чарльз Мур, создатель форта, отвечая на вопрос: как он пишет программы, сверху или снизу, отвечал, что если ему нужно в программе нарисовать круг на экране, то он сразу приступит к его рисованию, путем создания слова(процедуры), которая нарисует круг. Он как известно был поклонником разработки снизу. Да и язык форт только способствует такому стилю. Другие известные специалисты ратовали за разработку сверху. Это - Дейкстра, Вирт и мн. др. Алан Перлис, в одном из своих афоризмов заметил: "Все нужно проектировать сверху вниз, за исключением фундамента, с которого нужно начинать." То есть начинать с примитивов, снизу, а проектировать сверху. И он был абсолютно прав! Раньше я тоже думал, что писать надо всегда снизу, а там по ходу видно будет куда выведет эта дорожка, однако сейчас думаю совершенно иначе.. Корифеи были правы, смею признать. Проектирование программы начинается с самых главных процедур, а примитивы создаются по мере потребности в них. Только тогда программу, что называется, можно сразу "пощупать", увидеть сильные и слабые стороны проекта, так сказать, "в общем". Сторонники нижней позы , возражают, что, мол, как вы будете тестировать программу, если написав её половину, вы обнаружите, что требуется изменить общую структуру? Но они заблуждаются. Как раз, общая структура проектируется с самого начала, хорошо отрабатывается, и её изменять уже не нужно. Написав же программу наполовину снизу мы еще не знаем общей главной структуры. При проектировании снизу, взаимосвязь компонентов не всегда очевидна в общей структуре, и изменив один компонент, надо искать связи выше. При компонентной разработке не строго регламентируются иерархические отношения между компонентами, так как общей структуры еще нет, и непонятно что, к чему будет принадлежать и что от чего будет зависеть в конечном итоге..Общая, главная структура создается примерно так: 1. пишется главный код или процедура, подчиненные компоненты которого делаются в виде так называемых "заглушек". Заглушки это - пустые процедуры, которые возвращают какое-то значение, которое главный компонент будет интерпретировать должным образом. 2. Отработав общую схему, приступаем к созданию дочернего кода. Подчиненный код имеет свои функции-заглушки. И так далее, пока не дойдем до создания конкретных функций уже на "земле", спустившись с небес на землю. 3. Теперь раскручивая рекурсию в обратном направлении идем вверх создавая вместо заглушек рабочие компоненты. Так как общая структура уже спроектирована, написание кода является механическим созданием и отладкой отдельных компонентов. Несколько позже затрону тему иерархичности вообще, общения компонентов между собой опосредованно путем посылки сообщений, и как ООП извратило эту объектную идею. Теперь немного философии. Те, кто верят в Творца вселенной, в разумное начало (а я к таковым отношу и себя), хорошо знают, что мир создавался и поддерживается путем проектирования сверху вниз, от общего к частному. Мы знаем, что любое знание, чтобы быть хорошо усвоенным должно преподноситься от общего к частному, от общей структуры или обзора, к деталям. Только сверху видна общая картина. Тот же Перлис сказал: " Достаточно года работы над искусственным интеллектом, чтобы заставить поверить в Бога." Апологеты нижнего подхода , думаю, упускают из вида одну наиважнейшую вещь: управляемость, разделение ответственности, иерархичность. Компонентный подход снизу, - против иерархичности: там каждый компонент не знает кому принадлежит, а зоны ответственности размыты. По сути это хаос. Вот поэтому языки типа форта и канули в лету как самостоятельные единицы: больших серьезных систем на них не создашь. Объектный же подход возвел эту парадигму в ранг закона о чем позже. Правда это не относится к проектированию сверху или снизу - это другая тема. |
Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 45
Комментарии
-
Ну теперь то, поле очередного вашего прозрения, мы наконец то увидим от вас хотя бы морской бой?Запись от Катафалк размещена 22.02.2021 в 11:40
-
Запись от CoderHuligan размещена 22.02.2021 в 11:48
-
Так я вроде никому ничего не обещал, чтобы мне такие вопросы задавать
Сообщение от CoderHuligan

Запись от Катафалк размещена 22.02.2021 в 12:17
-
CoderHuligan,
вновь рад видеть вас и ваш непотопляемый блог! Как я погляжу, к вам сбегается народ почесать языком. Вы их сильно не пинайте. Любят они вас!Запись от wer1 размещена 22.02.2021 в 12:32
-
Монизм себя исчерпает - это однозначно. Деградация - нечто иное как высшая ступень монизма, его конечный пункт.
Только с появлением дуализма стали возможны сколь угодно сложные системы. Опыт развала СССР - результат монизма, который консервативно сдерживал другие направления развития до тех пор, пока не решил -"лучше развалиться, чем сосуществовать" (сам не съим и другим не дам).
Законы бытия они везде одинаковы, вселенная едина, но грань всегда делит две части.
Исключения - дридесятые измерения, с царём гороха.
Сколько верёвочке не вица, а результат вне исключения - заблуждения, самодурство, деградация, разложение.Запись от Hrethgir размещена 22.02.2021 в 12:50
-
Единоначалие - основа порядка. Демократия - основа анархии, всегда кончается анархией. Самая твердая, адекватная и правильная власть - власть Царя, Диктатора, Вождя. Анархизм в моде потому что анархия в голове. В программировании тоже самое: анархисты придумали ооп и сами заблудились. Поэтому исчерпывает себя не монизм, а политеизм.
Сообщение от Hretgir
Запись от CoderHuligan размещена 22.02.2021 в 13:27
-
основа порядка - закон и конституция, остальное бла-бла монистов. а чтобы был закон и конституция - должно быть право, анархия (беззаконие) это как раз и есть тот инструмент, который служит для лишения прав.
Сообщение от CoderHuligan
нет закона - нет порядка.
есть закон - будет и порядок.
единоначалие
, разве что в конфликтах, больше вы его нигде и не увидите.
в конфликтах - как нельзя лучше можно лицезреть единоначалие
, да и то, если конфликт не "договорной".
так всегда было и так всегда будет - законы бытия не переписать никому.
анархия - беззаконие. Вот она анархия:
Безначалие, отсутствие организованной власти, приводящее к беспорядку, хаосу (отсутствие плановой организации общественного производства, неизбежно приводящее его к кризисам и безработице).
Вот мне звонят с МТС, мы хотим предложить вам тарифный план, так как видим что ваши расходы увеличились и вы много платите. Умная - не берите много тогда, чтобы я много не платил, зачем меня ещё и времени лишать кроме прав.
Много платим - не берите много, а то начинают сказки про белого бычка рассказывать. А мы хотели-бы так, а вот хотели этак. Вы уже взяли от меня много, куда вам ещё хотеть?Запись от Hrethgir размещена 22.02.2021 в 14:35
-
"Закон что дышло - куда повернул, туда и вышло."
Сообщение от Hretgir
У нас много законов напринимали, а порядка как нет так и нет. Можно еще 10000 законов принять.. Не в законах дело, а в ответственности всех и каждого на своих местах. Каждый должен знать кому подчинен, и уважать и соблюдать некий кодекс поведения. Строгая иерархия отношений от мала до велика. Подчинение не по закону, а по внутреннему убеждению. Нижний компонент знает только свою меру ответственности. Высший компонент - отдает приказы и проверяет выполнен ли приказ. Тебе дали приказ подмести двор - выполни приказ только своего и только своего высшего указчика. Тут есть только двое относительно симбиоза - подчиненный-начальник. У начальника может быть несколько подчиненных, но подчиненные обязаны общаться между собой только через начальника. В смысле выполнения приказов. То есть другой подчиненный не может приказать мне вымести улицу, а только мой собственный начальник.
Такие взаимоотношения намного упрощают понимание сложных систем и их функционирование.Запись от CoderHuligan размещена 22.02.2021 в 14:46
-
с законами бытия так не получилось ни у кого. на Нобелевку подайте с своим заявлением.
Сообщение от CoderHuligan
А если у кого-то не хватает сил для рассуждений на элементарном бытовом уровне, то кроме как конфликт - он ничего начать не сможет.
Покрутите теперь. Никак? Зато какое начало было-"закон что дышло...".
Закон - механизм отношений, а не дышло.
Берите хоть физику, хоть математику, хоть право, хоть влюблённых, хоть физический конфликт военных сил.
Закон - механизм отношений, а там где его нет - там и есть анархия и бесправие.
Не надо лечить тут дышлом своим.Запись от Hrethgir размещена 22.02.2021 в 14:49
-
То есть - контракт. Отношения на основе соглашений. Контрактное программирование: https://ru.wikipedia.org/wiki/... 0%B8%D0%B5
Сообщение от Hretgir
Это то, к чему я хочу плавно повести. Тут мы четко знаем кто за что ответственен.Запись от CoderHuligan размещена 22.02.2021 в 16:07
-
Ну так это совсем другой разговор.
Тут всё ясно и понятно. Тогда ещё 5 звёздочек + от меня.Запись от Hrethgir размещена 22.02.2021 в 16:55
-
Запись от Croessmah размещена 22.02.2021 в 22:46
-
Запись от Usaga размещена 23.02.2021 в 05:49
-
Запись от CoderHuligan размещена 23.02.2021 в 09:21
-
Запись от CoderHuligan размещена 23.02.2021 в 09:28
-
Запись от Usaga размещена 23.02.2021 в 09:37
-
Так для нормального программиста, а тем более такого, который собирается кому-то что-то рассказывать про разработку, написать играбельный морской бой - примитивная задачка максимум на несколько часов ненапряджной работы. И отлаживать там месяц совершенно нечего.
Сообщение от CoderHuligan
Запись от Катафалк размещена 23.02.2021 в 09:40
-
Для "нормального" - да. Для "ненормального" - нет. Удовлетворит такой ответ? Ты лучше не бросайся такими словами, а то заставим за пару часов морской бой на си запилить, а потом сравним что получилось у тебя и у меня за месяц работы. И уверяю тебя: ты наложишь в свои дрянные штанишки. Уже на первом часе запилки проекта. Не такая это уж простая вещь на первый взгляд. Если вдуматься, то тут нужен ИИ-блок. Простым рэндомом тут не обойдешься, так школьники поступают, а не реальные пацаны. Но это тема другая конкретно касающаяся до игры морской бой. Ты просто не представляешь о чем говоришь. Приведу простой пример. У меня 16 типов 4-х палубных кораблей, включая повороты. 5-основных+повороты-4 палубы для квадратного типа 4-х палубного корабля. Чтобы выбрать следующую координату компом, необходимо не просто рэндомно её выбрать из списка небиты координат, но еще создать список цепочек всех типов которые вмещаются в этот список. Для чего это нужно? Представим, что у нас осталось два небитых корабля: 1 однопалубник и 1 четырехпалубник. ИИ должен решить выбором наибольшей цепочки, ибо если он выберет ход поразив однопалубник, у него останется еще 4 хода вместо одного и он может проиграть. поэтому ИИ должен выбрать четырех палубник. это сильно упрощенный пример. А есть еще алгоритм выбора хода в о время атаки и т.д. А есть еще диалог с пользователем. а есть еще телеметрия конкретного состояния игры и его вывод. А еще нужно создать окно в виндовс, а еще работа со спрайтами и пр. И все это на чистых апи.. За час говоришь? Ну ну парнишка.. Не бросайся словами. В сети очень мало примеров морских боев, а те что есть не выдерживают никакой критики. Хочешь создать еще одно г.? Флаг в руки.
Сообщение от Катафалк
Запись от CoderHuligan размещена 23.02.2021 в 09:59
-
Запись от CoderHuligan размещена 23.02.2021 в 10:00
-
Да, забыл: еще нужно валидировать ввод пользователя. Еще проверять типы кораблей. И еще - это не питон где тебе просто не дадут прострелить себе ляжку, а голый си, где выход за границу массива ничем не отслеживается автоматически и где все нужно ручками ручками пилить. и на отладку и тестирование уходит туева куча времени.Запись от CoderHuligan размещена 23.02.2021 в 10:13

, возражают, что, мол, как вы будете тестировать программу, если написав её половину, вы обнаружите, что требуется изменить общую структуру? Но они заблуждаются. Как раз, общая структура проектируется с самого начала, хорошо отрабатывается, и её изменять уже не нужно. Написав же программу наполовину снизу мы еще не знаем общей главной структуры. При проектировании снизу, взаимосвязь компонентов не всегда очевидна в общей структуре, и изменив один компонент, надо искать связи выше. При компонентной разработке не строго регламентируются иерархические отношения между компонентами, так как общей структуры еще нет, и непонятно что, к чему будет принадлежать и что от чего будет зависеть в конечном итоге..

, да и то, если конфликт не "договорной".

