freepascal.ru

>_< Коллеги-программисты. Не нужно подменять понятия. Абстрактный класс для разбития описания взаимосвязанных классов мне нужен не для абстракции. Я НИГДЕ больше не буду его использовать, кроме как в одном месте - заткнуть дыру негибкий возможностей пространства имён. Какой смысл мне от такой абстракции? Держать ещё 100+ строк кода, которые нужно все-время поддерживать в актуальном состоянии? Оборачивать каждый вызов метода реального класса пробежкой по таблице абстрактного класса?
И не нужно, возвращаясь к примеру со школой, помещать в школьный класс людей. Там учатся школьники. Повторюсь, с оценками. У базового класса "Люди" оценок быть не должно.
Как-то так.

Добавлено спустя 6 минут 17 секунд:
Люди. Ещё раз посмотрите на пример

Поднимите руку те, кто никогда так не делал? Задам 1 вопрос:
Почему вы считаете, что то что эту конструкцию средствами паскаля невозможно разбить на 2 файла без обходных путей с абстрактными классами или директивами компилятору - норма?

Brainenjii писал(а):Абстрактный класс для разбития описания взаимосвязанных классов мне нужен не для абстракции. Я НИГДЕ больше не буду его использовать, кроме как в одном месте - заткнуть дыру негибкий возможностей пространства имён.

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

Brainenjii писал(а):очему вы считаете, что то что эту конструкцию средствами паскаля невозможно разбить на 2 файла без обходных путей с абстрактными классами или директивами компилятору - норма?

Потому что это врождённая особенность паскаля. Вся его идеология строится на нисходящем програмировании, вплоть до синтаксиса.
Вы не можете использовать то, что ещё не объявили.

Указатели - это исключение из правил.

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

Brainenjii писал(а):Оборачивать каждый вызов метода реального класса пробежкой по таблице абстрактного класса?

Ничего такого нет.

alexs писал(а):Потому что это врождённая особенность паскаля. Вся его идеология строится на нисходящем програмировании, вплоть до синтаксиса.

Проблема, скорее, в реализации модульности в OP. Каждый модуль имеет секции инициализации и финалиэации. Компилятор гарантирует, что секция инициализации будет выполнена до начала использования модуля. При наличии циклических ссылок это невозможно.

Пробежал по этой теме (дискуссия интересная), но выводы из нее получаются следующие:

1. Каждый язык программирования, в т.ч. Паскаль имеют свои удобства и свои неудобства, свои "+", и свои "-".
Особенность языка нужно считать данностью. Расширять язык нужно очень аккуратно, сто раз подумав. Очень часто фичу, требуемую одним, другие используют в противоположном значении. Например, быструю компиляцию в Паскале многие используют как инструмент рефакторинга. Изменил имя (место расположения и т.п.) и смотришь на полученные ошибки (что есть ссылки на использование элемента). Введя пространство имен в его трактовке С# в угоду одним, мы можем получить кучу проблем для других.

2. На то, что указал создатель темы - это реальное ограничение языка Паскаль. Сегодня для устранения нужно либо использовать другой язык, либо использовать модули и наследование, когда в одном модуле описаны все классы с данными и перекрестными ссылками, но нет функционала (есть только абстрактные, либо очень простые методы). А далее в других модулях абстрактная структура данных (что и есть предметная область задачи) насыщается функциями.

3. Оппоненты автора темы с одной стороны говорят правильные вещи, но они не правы по сути, т.к. они говорят о другом. Многие разработчики которые часто используют БД зацикливаются на своих БД. БД - это частный случай. В общем случае данные могут вообще нигде не храниться. А алгоритм создания и удаления может быть намного сложнее, чем контроль битых ссылок.

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

5. Но ведь бывают и другие задачи. Например, есть предметная область (физика, техника, социология и т.п.), данные пусть есть, как-то редактируются и хранятся, пусть хранятся в СУБД в нормализованном виде. Но редактирование и хранение уже реализовано и работает как часы. А стоит задача выполнить обработку. Часто обработка на много сложнее, чем задача редактирования и хранения. Данные бывают очень сложными, а процедуры их обработки будут занимать часы, дни, недели и даже годы. В этом случае возникают требования с одной стороны сделать данные наглядными для описания алгоритма обработки (например, математические формулы), а с другой стороны сохранить быстродействие. Работа с нормализованными данными не приемлема в принципе, т.к. очень медленная, даже с самыми навороченными алгоритмами поиска и сортировки. В такой реализации ввод данных с нуля будет занимать один день, а обработка 1000 лет (пользователь умрет раньше, чем получит результат). Нужны банальные прямые ссылки (указатели на объекты). Здесь и возникает проблема, описанная автором топика, см. п.1 и п.2. И это делается не всегда удобно, но неудобство косметическое, т.к. вынос всей предметной области в один модуль (без функционала) как раз удобнее, чем ее разнесение по 20 модулям. Кстати, с позиции нормализации данных тоже нет никаких проблем. Читаем данные из СУБД, создаем классы под нормализованные данные, и затем в отдельной функции создаем перекрестные ссылки, после изменения состава данных (добавил, удалил, изменил), нужно заново пересоздать все перекрестные ссылки.

Тоже все время сталкиваюсь с этой проблемой, приходится решать как в 6-м посте (через абстрактного предка). В чем-то это даже логично, хотя и неудобно.

И ничего логичного в этом нет ^_^ Но я успокоился, что не одного меня это напрягает.

alexey38 писал(а):5. Но ведь бывают и другие задачи. Например, есть предметная область (физика, техника, социология и т.п.), данные пусть есть, как-то редактируются и хранятся, пусть хранятся в СУБД в нормализованном виде. Но редактирование и хранение уже реализовано и работает как часы. А стоит задача выполнить обработку. Часто обработка на много сложнее, чем задача редактирования и хранения. Данные бывают очень сложными, а процедуры их обработки будут занимать часы, дни, недели и даже годы. В этом случае возникают требования с одной стороны сделать данные наглядными для описания алгоритма обработки (например, математические формулы), а с другой стороны сохранить быстродействие. Работа с нормализованными данными не приемлема в принципе, т.к. очень медленная, даже с самыми навороченными алгоритмами поиска и сортировки. В такой реализации ввод данных с нуля будет занимать один день, а обработка 1000 лет (пользователь умрет раньше, чем получит результат). Нужны банальные прямые ссылки (указатели на объекты). Здесь и возникает проблема, описанная автором топика, см. п.1 и п.2. И это делается не всегда удобно, но неудобство косметическое, т.к. вынос всей предметной области в один модуль (без функционала) как раз удобнее, чем ее разнесение по 20 модулям. Кстати, с позиции нормализации данных тоже нет никаких проблем. Читаем данные из СУБД, создаем классы под нормализованные данные, и затем в отдельной функции создаем перекрестные ссылки, после изменения состава данных (добавил, удалил, изменил), нужно заново пересоздать все перекрестные ссылки.

Неужели выгрести из базы данных данные таблиц в структуры паскаля и обрабатывать в объекты в памяти быстрее , чем обработать данные таблиц на SQL сервере с помощью процедуры ?

А memory таблицы на sql сервере зачем ?
Зачем жонглировать объектами, если есть таблицы.

Ism писал(а):Неужели выгрести из базы данных данные таблиц в структуры паскаля и обрабатывать в объекты в памяти быстрее , чем обработать данные таблиц на SQL сервере с помощью процедуры ?
А memory таблицы на sql сервере зачем ?
Зачем жонглировать объектами, если есть таблицы.

Насколько я знаю, memory таблицы на sql сервере нужны для решения своего класса задач. Но не для всех задач они нужны.

Вот две задачи из моей практики:
1. В одном случае данные - это описание графа (узлы и ветви) с параметрами. Нужно выполнить задачи по эквивалентированию: поиск последовательных и парралельных ветвей, некие преобразования. Напишите на SQL для начала хотя бы банальное хождение по графу, проверку его связанности, поиск альтернативных маршрутов. Как это быстро и просто написать на паскале с использованием классов и рекурсии я знаю (около 10 строк кода). А как на SQL сервере в виде memory таблиц не знаю. Поделитесь опытом?

2. В данных заданы параметры модели. Решение задачи - это итеративный процесс численного решения дифференциальных уранвнений. Не приведете пример решения систем линейных уравнений, и численного интегрирования на SQL сервере с помошью memory таблиц? Небольшой момент - некоторые параметры это комплексные числа (формулы оперирования известны), но я не встречал библиотек для работы с комплексной алгеброй и матрицами для SQL сервера, хотя таблица и матрица это почти одно и тоже. Напишите хотя бы умножение двух матриц на SQL сервере с помошью memory таблиц. Задача как мне кажется решается несложно (хотя и громоздко). Но как быстро это будет работать?

P.S. Самое смешное, что объем данных, сохраненных в виде текстового файла будет несколько кБ. А решение задачи и без SQL сервера заниает приличное время. На кой нужен SQL сервер, для хранения таблицы из 100-500 записей?

Попробуйте вот так:


P. S. Придумал не я.

Взаимные сссылки в секциях INTERFACE классов, определенные в разных модулях можно делать через интерфейсы (полиморфизм в данном случае). Грубо говоря :
--------------------------
unit common;

inteface

type
intf1 = interface
..
intf2 = interface
----------------------
unit class1;

interface

uses common;

type
class1 = class(intf1)
class1func1(const class2ref: intf2);
..

----------------------
unit class2;

interface

uses common;

type
class2 = class(intf2)
class2func1(const class1ref: intf1);
--------------------------

При присвоениях : intf1 = class1, intf2 = class2