Процедурное программирование vs Объектное

[Tango]

А приписывать НУЖНО таки, очень, потому что то что хочется, уже не реализовать на том что есть, слишком большой бардак и узкая спецификация получившейся схемы данных.
Вы исходники смотрели? Если нет, то там всё стало похоже на бабушкин чулан.

[hinst]

то там всё стало похоже на бабушкин чулан.

сделай рефакторинг

[Tango]

"Сейчас выбрана стратегия сверху вниз (циклично), переписывания от мелкого к крупному, а не наоборот, когда рубится корень и всё что было выше падает.
Буду потихоньку спускаться вниз, как дойду до низа, поднимусь и опять вниз с другой абстракцией, других объектов. Так я считаю, самое неразгромное решение."

Никогда так не делайте! Это бесконечная итерация. Я взял нарисовал объектный каркас сначала. Потом стал переносить готовые блоки кода, исправляя пот сложившуюся структурную модель, и так достаточно быстро, за месяц перенёс весь проект на объектную структуру. Стало значительно лучше.

[wavebvg]

А ещё лучше - разбейте весь код на максимально независимые блоки (лучше не делать слигком мелких или крупных блоков), постройте схему с зависимостями:
* по функционалу
* по использованию (что и как использует) человеком через ГУИ и вами для реализации
Ещё раз подумайте как лучше разбить на блоки
Оформите блоки в коде (разделите логику, где надо, оставив прежний стиль программирования, даже если раньше был стиль "каша"). И лишь после этого вы сможете легко и непринуждённо "весь проект на объектную структуру" отдельными блоками.

[sign]

wavebvg, вы так незатейливо описали (немного, правда) дракон-схемы Паронджанова.

[wavebvg]

Ну дракон это в первую очередь минимализация ошибок (путем визульного представления, которое требует серьезной формализации - писать на нем бизнес не будет).

Тут всё куда проще и уменьшение ошибок возможно, но это не самоцель. Просто если рассмотреть программу как процесс написания со всеми зависимостями, что-то вот такое...

Написание программы:
1. Программа пишется, чтобы имелась (базовая абстракция, базовый интерфейс, базовый use case).
2. Добавляется функционал (приобретенные абстракции на стадии Х).
3. Обновляется интефейс программы (обновление интерфейса на стадии Х).
4. Появляются новые задачи для программы (приобретенный use case на стадии Х).
5. Усложняются имеющиеся задачи (обновление use case на стадии Х).
6. Имеющиеся задачи решаются по другому (приобретенные абстракции на стадии Х)
7. Добавляются новые элементы интерфейса (новый интерфейс на стадии Х)

Программист:
1. Пишет код, согласно своим (базовым принципам) написания кода, допускает (базовые ошибки) и исправляет их
2. В дальнейшем он применяет различные (базовые идеи как недопустить ошибки) и корректирует свои принципы, получая (обновленные принципы на стадии Х)
3. При наличии стадий >2, мы получаем, что у него в одной программе пристутствуют принципы различных версий. Видя это, программист применяет (базовый рефакторинг)
В дальнейшем все меняется и принципы рефаторинга и принципы написания кода, и способы недопущения ошибок

Задачи программы:
...

Область применения:
...

Аппаратные средства:
...

Из всего этого можно сделать любые выводы, но...
Если рассмотреть "переписывание с нуля" - то это не самый лучший подход, потому что:
1. Переписывание большого объёма функционала (текущих абстракций) приведет к большому числу новых ошибок, которые спокойно пройдут через все приобретенный принципы и устроят очередную головомойку по исправлению ошибок.
2. Если не формализовать существующий use case, то при обновлении многие вещи будут сделаны по другому, т.е. мы не получим новый use case, когда нам и старый тоже нужен.
3. Если не провести формализацию интерфейса... Мы получим одну кнопку "сделать хорошо", а потом добавим ещё одну "вернуть как было"...

И это только основные взаимосвязи двух первых рассмотреных ситуаций, которые и так видны сразу же.

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

[Kemet]

А давай сами напишем? Там изменения, по сравнению с объектным паскалем, не такие уж и большие.

Убрать директивы типа Virtual, Protected ets... а вместо них ввести потоки и директиву own. Добавить класс типа процесс.

Угу, и получится Active Oberon

[Лекс Айрин]

Kemet, значит, язык моей мечты Оберон. Осталось найти компилятор под линукс.

[Kemet]

Kemet, значит, язык моей мечты Оберон. Осталось найти компилятор под линукс.

Oberom и Active Oberon это разные языки, как и Pascal и Object Pascal, тебе какой именно из Оберонов?
Если любой, то, как минимум, есть Optimizing Oberon-2 Compiler, Oxford Oberon-2 compiler, XDS.
Active Oberon реализован только под OS A2 и .NET, как вариант - использовать UnixAOS - реализацию ОС А2 под Никсы.

[debi12345]

Объекты нужны когда нужны невыгружаемые блоки кода с удобным интерфейсом доступа. Если таковых блоков кода нет или не может быть (PHP, CGI,..) то и объекты не нужны. Если есть (типичные GUI-аппликухи, Java-сервлеты,..) - то с ними удобнее.

[hinst]

нет! объекты нужны всегда! надо всё делать на классах и объектах!
PHP - дно

[Лекс Айрин]

Kemet, мне кроссплатформенный.

Хотя... Паскаль, как таковой, меня вполне устраивает. Именно поэтому есть желание его чуточку видоизменить, приблизив к классической объектной модели. Форк С++ модели программирования менее интересен, так как больше шансов запутаться в директивах методов

[Kemet]

Kemet, мне кроссплатформенный.

По приведенным ссылкам и представлены кроссплаьформенные реализации

[Лекс Айрин]

Kemet, а что-нибудь не заброшенное есть?

[Kemet]

Kemet, а что-нибудь не заброшенное есть?

Ага, есть - Модула-3 )))
Но вообще, Охфорд и ХДС вполне себе актуальные? есть еще инструментарий, ты скажи что именно хочешь сделать, что именно, для чего и в каком виде тебе нужно, тогда можно что-то выбрать из того, что используем мы