[bubaeshka]

Хотя и имею профильное образование, программирую под Win довольно редко (в основном ПЛК, а ещё чаще отвёртки и бокорезы), да и собственно, кроме Delphi, особо то и не знаю ничего. Возникла необходимость написать новое приложение, а так как с годами, мне кажется, что я тупею, решил посоветоваться. Последнее на чём я писал, это Delphi 7, несколько лет назад, причём когда писал, помню что сильно матерился, что не могу сделать так как я хочу, потому что это реализовано только в новых версиях делфи. Сейчас вот скачиваю 11 Community Edition.

Собственно задача: дан некий текстовый файл с данными для станка. В этом файле, в строковом виде, существует список изделий, а в каждом изделии, соответственно, список операций, осуществляющимися над ним. Необходимо перестроить файл, в соответствии с оптимизацией (раскроем) изделий. Также была необходимость пересчитывать некоторые операции, содержащиеся в изделии (первая версия программы написанная примерно за месяц неспешного труда, с постоянным отвлечением на другие задачи, обрастала мясом года полтора ещё сверху). То есть я уже делал одну такую программу, но сейчас возникла задача сделать такую же под другой станок и соответственно формат файлов.

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

Как я сделал старую программу: изначально, при открытии файла, создаётся объект при помощи конструктора класса TФайл, затем в этом же конструкторе файл парсится. И в поле типа TObjectList класса TФайл создаются объекты класса TИзделие. В свою очередь в классе TИзделия, есть поле типа TObjectList, которое содержит в себе объекты класса TОбработка. Получается такая иерархическая структура связанная через TObjectList. В каждом классе, естественно, помимо поля TObjectList, существуют вспомогательные и не очень, поля относящиеся к каждому конкретному классу, какие то размеры, списки TStringList с самими кодами программы и какими то служебными полями, также есть методы оперирующие данными, находящимися в этих классах. Например процедура оптимизации, содержится в классе TФайл, так как она выполняет перестановки в "массиве" изделий, который содержится внутри класса TФайл, в его поле TObjectList. Есть ещё несколько служебных - вспомогательных классов (например списки раскраиваемых заготовок), которые не относятся напрямую к классу изделий, файла, и обработок - они отделены и не входят в общую структуру. В итоге получается такой мегаобъект типа ТФайл, внутри него в списке объекты изделия, внутри которых объекты обработки.

И собственно вопросы:

1. Насколько я выбрал удачную архитектуру приложения? Можно ли сделать лучше?

2. Какой класс выбрать, с учётом более современных возможностей Делфи 10/11, в качестве контейнера объектов, или остаться на TObjectList?

[Guaho]

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

[lmikle]

В общем, стандартная схема построения модели данных. Так что тут все ок.
Для списка объектов вполне можно пользоваться TObjectList, только если уж планируешь использовать Д11, то используй тот, который generic - TObjectList<T>, тогда у тебя все методы будут типизированные.

[bubaeshka]

Огромное спасибо вам ребята. Я уж думал никто и не ответит. Да, я уже постарался бегло посмотреть что есть в новой делфи. Наткнулся на System.Generics.Collection, и понял, что ничего умнее TObjectList никто не придумал. Помню, что я как то бился с очисткой памяти и не победил её, и постоянно возникали какие то глюки.

С базами данных я работал. Даже когда учился, был специальный предмет когда то, и там именно на Делфи с ними и работали. Я со временем увлекался программированием, ну в качестве хобби что-ли, да и до сих пор немного php пользуюсь, java подучиваю (в первую очередь в плане веба и Androida). Но меня поражало, насколько легко в Делфи на десктопе работать с базами... А учитывая, наше образование базировавшееся на Паскале (слышал мнение, что это правильно), не понимаю, почему борланд не купили русские? Правда неизвестно где сейчас место Паскаля в образовании и что там вообще творится, вся таки 15 лет прошло... Ну это я уже отвлёкся от темы.

Здесь БД, немного не тот случай, входной формат текст, выходной - текст. В тексте в строках, разделённых пробелами, команды и параметры команд, размеры. При работе с одним файлом (да даже с несколькими, хотя я это не предусматривал) проще держать всё в памяти, в виде объекта. Если уж развивать программу, то по сути, надо двигаться в сторону графики и редактирования пользователем операций вручную. Но это уж такое себе. Солидно слишком. Но я подумаю. Полнейший крутяк был бы 3Д конечно.

У меня была некоторая проблема при разработке именно оптимизации, немного не хватило у меня времени и ума осилить матчасть этих алгоритмов (линейного раскроя), в итоге я решил, что всё равно тупой, и сделал жадным алгоритмом. В 2% отхода всегда результат укладывался, все остались довольны. Собственно есть вопросик:

При создании и перестройке кое-каких списков... а именно, карт раскроя, в виде ID изделия > Длинна, удобно ли использовать TDictionary? Вот хочу его попробовать. Помню что с массивами было не совсем удобно работать, по причине того, что ИД изделия, это всё-таки не индекс массива. Кстати, в чём смысл введения класса TArray?

Тут намедни видел статью на Хабре, что типа TDictionary в делфи убого реализован, что типа им лучше не пользоваться. Было это описано в статье про хеш-таблицы. Но чем больше я читаю на Хабре комментаториев, тем скептичнее отношусь и к Хабру, и к его сообществу, и особенно, к самим комментаторам, хотя полезного там много.

[bubaeshka]

Сообщение от lmikle

В общем, стандартная схема построения модели данных. Так что тут все ок.
Для списка объектов вполне можно пользоваться TObjectList, только если уж планируешь использовать Д11, то используй тот, который generic - TObjectList<T>, тогда у тебя все методы будут типизированные.

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

[lmikle]

Ну, БД тут, вроде как, ни к чему. Если только детали не одинаковые. тогда можно библиотеку деталей сделать. Но это скорее полезно для моздания новых раскроек.

Если номенклатура детелаей ограниченна, то действительно имеет смысл держать в памяти 2 объекта:
1 - собственно список уникальных делатей со всей информацией по ним и тут действительно можно использовать TDictionary (особенно, если ID зашит и его менять нельзя, а то в принципе и индекс в этом массиве работат тоже хорошо), т.к. при разборе файла одинаковае детали действительно "сольются"
2 - собственно раскройку в виде (ID, координаты)
Ну и потом по второму списку идет экпорт в новый файл, просто извлекая из словаря деталей нужную по ID и вставляя соотв. блок.

Короче, теоретически сложно сказать как будет лучше. Тут надо смотреть на файл и данные в нем.

[bubaeshka]

Спасибо. Я рад, что был на правильном пути, и я думаю его и дальше придерживаться. Спросил, потому что пишу классические программы редко, то есть для ПЛК чаще всего, и в классических языках для ПЛК с ООП пока совсем туго, тем более если такие применяются - например какое ООП в FBD или LD, графических языках? Однако же видел, что ООП вовсю пошло на Ардуино, там С.

Да, действительно ID менять нельзя и от него многое зависит. Даже если детали абсолютно одинаковые, один в один. Хотя нередко и просто с одинаковой длинной, тогда при идентичных значениях в массиве, детали будут разными и путать их уже нельзя совсем. Так что попробую TDictionary. Тема касается, кстати, деревянного домостроения.

У меня были ещё всякие вспомогательные классы именно для оптимизаций - маленькие. Например, списки раскраиваемых заготовок.