Собственно вопрос как логично организовать работы с проектом..? Поясню малость: в PHP в данном случае всё было просто: всё по папкам, каждый класс (библиотека) в отдельном файле. В Делфи малость всё по другому.

Допустим есть основная форма, соответсвенно и весь код в одном месте. Но мне нужно, к примеру, иметь механизм управлением настройками, библиотеку для работы с ДатамиВременем и т.д. и т.п. И соответсвенно всё это иметь в одном файле не совсем разумно да и не удобно.

Как мне это лучше использовать, т.е. как организовать саму работу.. Создавать какие-то отдельные DLL, какие-то отдельные PAS-файлы или как-то по иному? К чему сводится практика?

PS
просто изначально хочу организовать удобно и практично. Планирую создать большой проект и не хочу создать мешанину изначально 

Никто не мешает "разбить" код по отдельным Unit. Их можно размещать где угодно: в одной куче или расфасовать по папкам.

В Delphi так же можно каждый класс описать в отдельном файле. 

В этом одном месте можно разместить только код, который непосредственно связан с этой формой (только методы TForm). Все остальное (механизм управлением настройками, библиотеку для работы с ДатамиВременем и т.д. и т.п.) можно разнести по модулям (Unit).

Добавлено через 1 минуту и 40 секунд
Кстати, в Delphi уже есть библиотека для работы с датой/временем - DateUtils. Возможно там уже есть то, что нужно.

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

Допустим я определяю глобальную переменную, которая хранит языковые константы. Что-то типа такого



Как мне это перенести в другой файл и как это будет взаимодействовать, т.е.  определять тим и переменную мне нужно в основной форме или же можно в другом файле?

Добавлено через 2 минуты и 9 секунд
Да, там есть нужные мне функции конечно   Но требуются более свецифичные, например, прибавлять только рабочии дни или вычислять разницу с учётом празников или преобразовывать дату из любого формата в любой формат

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

Красиво смотрится.... 


Это сообщение отредактировал(а) gesper - 1.9.2014, 12:28

немного не так   но не суть...

Так как мне быть? Мне нужно определить и заполнить глобальную переменную LANG данными. Где это мне сделать? соответсвенно со всеми процедурами (или может функциями)

Можешь создать отдельный Unit (назвать его, к примеру, LangUnit), там описать TLang, LANG и функцию GetLanguage (может еще какие функции). Затем в модуле, в котором описан TMainForm, в uses добавить LangUnit и уже из этого моделя работать и с TLang, и с LANG, и вызывать GetLanguage.

Poseidon, вот спасибо! Мне не хватило именно вот такого элементарного объяснения чтобы понять общий принцип   

Так, теперь дальше.. На сколько вообще приемлемо в Делфи дробнение на отдельные модули? Т.е. лучше каждый такой обработчик закидывать в отдельный Юнит или же всё такие сделать 1-2 Юнита, которые не относятся в формам? 
Я так понимаю в каждом таком Unit подключаются при компиляции куча всяких процедур/классов/объектов. Не получается так, что в проект будет несколько раз включена та или иная "библиотека"?

кстати, и есть ли смысл создавать отдельные DLL?

Тут нет каких-то правил. Максимум - рекомендации. Все на усмотрение программиста. Можно все написать в одном модуле формы, а можно раскидать каждую функцию по отдельным модулям. Разницы для Delphi нет. Нужно смотреть со стороны легкости чтения кода. Лично я отделяю по модулям родственные классы, в отдельном модуле описываю глобальные константы, в отдельном - общие функции, и т.д. Если пишешь ты один, то как тебе удобнее, так и пиши. Если не один, то договоаривайтесь и пишите. Тут все делается для удобства разработчика, а не компилятора.

Нет. Магия компилятора сделает свое дело. Более того, даже код, который не используется, но модуль с этим кодом подключен, будет при компиляции "выкинут" из exe.

В данном случае, думаю, нет. Гемороя от dll будет гораздо больше, чем включение кода в exe. Хотя тут тоже могут быть нюансы. Если код будет использован разными проектами, если предполагается частое обновление кода и т.п., то его лучше впихнуть в dll. Плюс не стоит забывать, что dll - это уже отдельный проект и та магия компилятора, которая описана выше, тут не сработает. Получится дублирование некоторого стандартного кода в exe и dll, и, соответственно, размер exe без функций + dll с функциями > exe с функциями.

Poseidon, всё понятно.. Основные мои опасения были насчёт компилятора.. Но коль так говоришь, то поверю на слово.

И на последок ещё один маленький вопрос... Я правильно понимаю что последние версии Делфи по умолчанию уже работают с юникодом?

Да. Юникод появился начиная с версии 2009. Соответственно все ХЕ-версии уже с юникодом.

Большое спасибо за разъяснения. Многое стало более понятным.

Тему можно пока закрыть   

PS
малость помучился с подгрузкой INI-файлов в юникоде.. Хоть делфи по умолчанию и работает с юникодом, но всё таки пришлось задавать кодировку "ручками" 

К слову, если проект большой и не пользуешься какими то программами для создания диаграмм работы программы твоей, то пора начать. Я особо не заморачивался изумением UML, для себя в общих чертаж в "yEd Graph Editor" делал схему как связаны между собой модули/классы, чтобы потом при разработке новых форм не теряться в том, кого и куда цеплять. Чтобы себе проблем не создать. 

gesper, ну с учётом того что я последние 14 лет программирую на PHP, то архитектура проектов Делфи мне кажется малость не логичным   
Поэтому столько и вопросов

А проект уже начал делать: органайзер. Понимаю что велосипед и есть интересные проект. Ближе всего к моим требованиям подходит WinOrganizer, но почему-то он перестал развиваться, да и не всё меня там устраивает... Что касается проекты на Делфи - подобные какие нашёл что-то совсем удогие   

PS
Сейчас немного ещё ещё вспомню что к чему в Делфи и открою новую тему.. Уверен чтобудет много вопросом.. web-органайзер сделать без проблем, но хочется иметь что-то автономное, без сервера на компе  Очень давно планировл начать, года три   вот решился...

Добавлено @ 16:23
Проект планирую большой, естественно с открытым кодом. По этому и хочу предусмотреть всё что принято в Делфи, начиная от "как принято называть переменные/функции/класса" до "как организовать структуру проекта" и "стиль кода".. Вдруг участники проекта появятся. Вот чтоб глянул в код и было всё сразу понятно..

Это сообщение отредактировал(а) Gold Dragon - 2.9.2014, 16:29

Это не велосипед, это так программа которая нужна каждому своя. Когда поиграться решил с программированием, то брат предложил сделать ему по его хотелкам. Он показал мне 4 программы в каждой было что то классное, но в целом либо перегружен функционалом, который ему не нужен. Либо идиотский интерфейс, либо..либо...  
Было несколько предложений по переводу программы на другой язык и продаже, куча хотелок, но у меня нет времени ей заниматься и желания делать это за так. Она уже убыточная. В этом году я отказался от продления домена сайта который был у меня, и от развития программы полностью. Глянь, если интересно.
http://freesoft.ru/pichugin_organizer
http://pichugin.ucoz.ru/publ/3-1-0-11
У нее есть глюки, и движок который надо переделать полносью(собрано на коленке). Сейчас я знаю как, но когда начинал такого не умел. И сейчас я бы отказался от Delphi и стал делать ее на Lazarus. Потому что круг пользоватлей шире можно получить.

По поводу правил - в книгах по Delphi нет некоторых интересных правил которые есть в Java и PHP. Помоему, главное чтобы все было однообразно и в одном стиле, а если часть эл-тов, например названия файлов, сделаны в стиле java то ничего страшного.

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

Это сообщение отредактировал(а) gesper - 2.9.2014, 17:50

Вот и я про это... В PHP есть несколько основных требований (не обязательных, но рекомендованных) которым большинство старается следовать... А в Делфи мне показалось "кто на что горазд" 

gesper,  кажется находит твою программку, но скачать не смог.. Если не жалко, скинь проект куда-нибудь для скачивания


PS
а Lazarus это конкурент Делфи? .. ещё и бесплатный...

Добавлено через 2 минуты и 5 секунд

а что в личку то... я у ж официально проект открою где-нибудь на Гуглекоде   

Программа сама тут, или ты исходники хочешь?
http://depositfiles.com/files/97fuh0qlx


Не знаю насчет конкурента, по мне нет, функционал другой дает и развивается медленней. Зато поддержка нескольких платформ сразу у тебя, есть функция преобразования проектов Delphi, но не полностью. У меня некоторые формы не сконвертировались. Язык и общий синтаксис такой же как и в Делфи, только иногда приходится функции другие использовать, чем те что в делфи. Где то удобнее, где то нет. Слежу больше за правильностью кода в нем, придирается больше.


ну туда) на гугл)

Это сообщение отредактировал(а) gesper - 2.9.2014, 18:54

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


Это сообщение отредактировал(а) Gold Dragon - 2.9.2014, 19:07

Не помню не одного исходника чтобы что то получилось скомпилировать, везде что то не хватало)
Личку смотри.

Тогда тебе будет не лишним прочесть стандарты Embarcadero

Не знал что это есть на сайте, впринципе все есть в учебниках, что там написано... кроме


Кто писал это был мазахистом что ли? Форматировать код толдыча пробел....  

ну это и в PHP актуально.. Вот только два - так код сливается ... почему не 4....

Добавлено через 8 минут

Очень позновательно....

PS
и кто придумал присвоение начинать с двоеточия, а не просто через "равно" делать....   

И ещё тогда.. с помощью чего делать автоматическое форматирование кода? В других IDE это встроенный функционал, выбираешь стиль и всё автоматом форматируется...

К слову, на Lazarus табом делается форматирование. Это есть в настройках, сколько пробелов у таба и на сайте его показывается как быстро форматировать табом в обе стороны.

Автовыравнивание было в Delphi, некогда не пользовался им. 

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

Проверил форматирование кода.. Работает    но примитивненько, с PHPStorm не сравниться однозначно. Настроек по минимум

Это сообщение отредактировал(а) Gold Dragon - 3.9.2014, 14:14

Для удобства поставь cnPack - он и автоформатирует, и автодополняет и вообще имеет кучу вкусного. гуглить как Delphi cnPack. Ну а об организации классов - в качестве примера, могу привести свой распаковщик BSA. Он не совсем удачно организован с точки зрения человеческой логики, но уж очень мне хотелось с наследованием поиграться.

Глядеть тут.

Ну в принципе не знаю делфи для меня всё достаточно понятно и на первый взгляд: всё достаточно наглядно что и где. А если минут 15 посидеть то вообще буду во всём шарить..

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

Хотя может в Делфи абстрактный класс это нечто иное как в других языках... Я понимаю наследование классов - это разумное и правильное решение, при условии грамотного подхода к коду

PS
малость не понял синтаксис кода (не встречал в "учебниках")
домыслить смогу конечно, но хочется чуть поясниния

Добавлено через 14 минут и 32 секунды
АХ..... какая Х.... хорошая прога!!! +1!


Это сообщение отредактировал(а) Gold Dragon - 4.9.2014, 07:46

Дженерики

В дополнение к цнпаку могу посоветовать GExperts, тоже набор мастеров, улучшающих работу в иде.

По вопросам оформления и стиля - лучше придерживаться борланда/амбара ну с незначительными отклонениями. Ну а архитектуру и модульность обычно с опытом приходит, кто с помощью умл совершенствует свои навыки, кто с паттернами, по банде и по статьям, много путей.
Могу посоветовать порыскать по Delphifeeds.com и Delphifeeds.ru на предмет соотв. статей. 
Есть некоторое количество блоггеров, которые пишут по делу.

Я так предполагаю, что это был Никлаус Вирт. В общем это еще от Паскаля пришло.

В общем я понял одно.. такой сплочённости как в PHP в Делфи нет   

Ты учти. Delphi - коммерческая среда построенная на языке Object Pascal(поддерживаемый ей только), а PHP язык без среды с кучей свободных редакторов.

ах точно!!! Но всё равно, разработчики как-то договариваются 

В общем просмотрев кучу стилей написания, мне ближе тот который больше похож на PHP. И я таких уже встречал..

Gold Dragon, вот несколько ссылок, может будет полезно:
Ссылка
Ссылка
Ссылка
Ну и там еще по блогам можно пошариться.

Это сообщение отредактировал(а) superVad - 4.9.2014, 16:51

https://ru.wikipedia.org/wiki/Delphi_(язык_программирования)

ТоляМБА, и?   

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

Даже в этой теме достаточно ссылко на другие ресурсы где народ просто говорит о том что "пишет как хочет"  

Добавлено через 2 минуты и 33 секунды
superVad, +1 
достаточно позновательные статьи и структуре проекта, очень много интересный мыслей. Хоть материалы и старые, но ... 

TArray - дженерик обёртка, появившаяся в Delphi XE если не путаю. По сути - тот же самый массив. Просто использовать удобнее, чем обычный Array.

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


Это сообщение отредактировал(а) CynicRus - 4.9.2014, 21:27

Первоисточник в любом случае Object Pascal. То что Борланд(которого нет уже) решила назвать Васю Петей, ей очков не прибавило.
И что хорошего в языке который только одна платформа/IDE понимает?

https://ru.wikipedia.org/wiki/Lazarus
https://ru.wikipedia.org/wiki/Free_Pascal

А что хорошего в языке который много иде понимают? Наоборот же - унификаця.

народ, не отвлекаемся от темы!... Спорить можно сколько угодно, но Делфи есть и будет.. Lazarus - оболденная вещь (почитал немного, попробовал)... И очень надеюсь что у неё большое будущее лишь потому, что она бесплатная с открытым кодом. А практика показала что такие системы более динамичнее в плане развития и (самое главное) в поддержке..

PS
если всё перевести на историю.... Есть провессиональная армия, а есть народная армия.. И очень понятно кто победит.. Вот только Народная армия раз в 1000 больше....... За две недели опытов с этим языком (хотя лет 10-15 назад я писал на нём примерно на среднем уровне  ) я понял, что он очень мощный язык, был и остаётся... Но есть один большой недостаток - очень большая неорганизованность, по сравнению с другими языками!

 PSS
свотрю справку по Lazarus... оказывается Total Commander 64-bit уже на нём писан 

Добавлено @ 21:03
очень многое... Например, у PHP много IDE и очень большая конкуренция... каждая версия любого IDE стремиться к "совершенству". Не "в тренде" - помер... А у Делфи, к сожалению, всё самое "вскусное" - сторонних разработчиков.. Самый элементарный пример - подсветка и форматирование кода


Это сообщение отредактировал(а) Gold Dragon - 6.9.2014, 21:03

так пишут только школьники, и то только мини поделки.

Ключевой особенностью (по сравнению с PHP) является организация "области видимости" и запрет на перекрестные ссылки.
Идеальный способ организации один класс = один модуль. Описание типов (общих для нескольких модулей) желательно тоже выносить в отдельный модуль. Тоже касается и констант.

На мой взгляд хорошим решением было бы прочесть книгу по Delphi5-7. В то время авторы уделяли внимание основам синтаксиса. А в свежих книгах данная тема зачастую не затрагивается.

не болтайте ерундой 
речь идет о том чтобы не использовать символ табуляции, потому что он может по разному отображаться с разными настройками IDE, соответственно не у всех он будет выглядеть так как у тебя. но кнопкой Tab можно вставлять нужно количество пробелов вместо символа табуляции (тоже настраиваейтся в IDE). талдычить пробел не нужно.

а чуть подробнее.. Области видимости и PHP достаточно организованы

речь не о том, что они не организованны, а о том, что они разные

так в каждом модуле Delphi две области видимости: interface (область видима для других модулей) и implementation (видима только внутри модуля).
Также имеется разрешение на совпадение имен (констант переменных или типов) в подключенных модулях. 
Видимость любых описаний всегда ограничена блоком к которому относится описание.

странно, что суть этой замечательной возможности не до всех доходит
программеры (на разных языках) спорят о наиболее удобной ширине отступов (2? 4? 8 пробелов?) и никак не придут к одному мнению
тогда как использование для отступов именно символов табуляции плюс настройка ширины отображения таба в IDE как раз позволяет каждому разглядывать и набирать код в удобном именно ему виде, а у другого программиста с другими настройками IDE он отобразится в удобном уже ему виде 
для этого достаточно не мешать табы с пробелами, точнее, мешать по уму и осознанно

касательно дельфовского стиля кодирования - все просто: общепризнанный авторитет один (борланд/эмбаркадеро) и их код (rtl/vcl) и является для (не стремящихся во что бы то ни стало самовыразиться) дельфистов образцом стиля

Это сообщение отредактировал(а) PointerToNil - 9.9.2014, 10:31

на практике всё просто расползается 

ну из практики скажу.. два пробела это ужасно мало       идеально 4

PS
и кстати, "нормальные" IDE легко настраивают табуляцию.. т.е. жмёшь tab, а тебе X пробелов

даже если и всё, то не у всех
а только у тех, кто смешивает табуляцию с пробелами, причем тупо (неправильно)

Вроди как bems об этом и писал  правда я не скажу с ходу где это настраивается т.к. не пользуюсь табом.

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

два вопроса:

1. Как быть с наследуемыми классами? Лучше (грамотнее) положить в один модуль или всё же раскидать?

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

Это сообщение отредактировал(а) Gold Dragon - 12.9.2014, 07:39

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

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

Главное не забывать некоторые моменты для классов в одном модуле - ссылка.

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

Я всего лишь намекнул, что классы в одном модуле имеют доступ к приватным членам друг друга. В свое время я на этом моменте завис.

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