Краткое введение в современный Object Pascal для программистов

По доброй традиции знакомство с языком начинают с самой базовой и простой программы "Hello world". На Паскале она выглядит следующим образом:

Это — полноценная программа, которую можно скомпилировать и запустить.

Остальная часть этой книги рассказывает о самом объектном Паскале, поэтому не ожидайте чего-либо большего, чем консольных приложений. Если хочется взглянуть на что-либо более "крутое", можно просто создать новый GUI проект в Lazarus (Project → New Project → Application). Вуаля! — рабочее кроссплатформенное GUI приложение, с нативным видом, использующее удобные визуальные библиотеки. Lazarus и Free Pascal Compiler имеют множество готовых компонент для сетей, GUI, баз данных, чтения и записи различных форматов файлов (XML, json, изображения…​), управления потоками и всем, что только может понадобиться программисту. Ярким тому примером является Castle Game Engine, о котором упоминалось ранее :)

Чтобы задать возвращаемое значение функции, необходимо присвоить какое-либо значение "волшебной" переменной Result в процессе выполнения функции. Её можно свободно читать и устанавливать новое значение так же просто как и любую локальную переменную.

Можно рассматривать имя функции (MyFunction в примере выше) как переменную, которую можно использовать как самую обычную переменную. Но лично я бы не советовал так делать, поскольку это выглядит не очень "прозрачно", особенно в случае, если это значение используется с правой стороны выражения. Лучше всегда использовать Result, в случае, если необходимо использовать или устанавливать возвращаемое значение функции.

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

Функция Exit служит для завершения выполнения процедуры или функции до того, как она достигнет завершающего end;. Если Exit вызвать без параметров, она вернёт последнее значение, присвоенное Result. Так же можно использовать конструкцию Exit(X), чтобы установить результат функции и завершить её исполнение немедленно — это эквивалентно конструкции return X в С-подобных языках.

Обратите внимание, что результат функции может быть "проигнорирован" (отброшен). Любую функцию можно вызвать как обычную процедуру. Делать так имеет смысл если функция выполняет некоторые побочные операции (например, изменяет глобальные переменные), а не просто вычисляет некоторый результат. Например:

Конструкции if .. then или if .. then .. else запускают определённый код, когда выполняется указанное условие. В отличии от C-подобных языков, в Паскале нет строгого требования ставить условие в скобки.

Оператор else всегда относится только к последнему условию if. Поэтому можно вполне рассчитывать на однозначность выполнения такого кода:

Впрочем, заключение вложенного if внутри блока begin …​ end; является лучшим вариантом, чем предыдущий пример, поскольку он более читабельный, даже если нарушены отступы или большой объём кода и комментариев затрудняет понимание. Таким образом, всегда очевидно к какому if относится данный else - относительно A или относительно B - и, соответственно, куда меньше шансов допустить ошибку при написании кода или при его правках.

Логические операторы представлены в Паскале операторами and, or, not, xor. Их значение в большинстве случаев очевидно для людей, знакомых с компьютерной грамотой. Разве что, за исключением оператора xor, который в русской литературе обычно называется "исключающее или". Эти операторы принимают булевские аргументы (boolean), и возвращаемое значение имеет тот же тип boolean. Они также могут работать как побитовые операторы, в случае, если оба аргумента целого типа (integer, byte или подобные), в этом случае они также возвращают значение идентичного целого типа.

Операторы отношения (сравнения) - представлены следующими комбинациями символов: =, <>, >, <, <=, >=, значение которых вполне очевидно. Следует отметить, что в отличии от синтаксиса С-подобных языков, в Паскале оператор сравнения выглядит как один знак "равно" A = B (в отличии от С, где используется код A == B). Специальным оператором присваивания в Паскале является :=.

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

Следующий пример вызовет ошибку компиляции:

Ошибка связана с тем, что компилятор в первую очередь пытается выполнить побитовый оператор and в середине выражения. В результате получается (0 and B) - побитная операция, возвращающая целочисленную величину. Далее компилятор выполняет оператор "равно" и получает булевскую величину A = (0 and B). И в конце концов появляется ошибка type mismatch, в результате попытки сравнения булевской величины A = (0 and B) с целочисленной величиной 0.

Правильно записывать это условие в следующем виде:

Паскаль использует "короткую оценку (short-circuit evaluation)" - мощную оптимизацию, позволяющую не вычислять выражение целиком, если какая-либо его часть полностью определяет результат. Рассмотрим пример:

Если в зависимости от разных значений определённого выражения должны быть выполнены разные действия, тогда может оказаться удобной конструкция case .. of .. end.

Условие else опционально (и соответствует default в C-подобных языках). В случае, если текущее значение анализируемого выражения не совпадает ни с одним из описанных случаев и нет условия else, то программа просто пропустит всю конструкцию case и будет выполняться далее.

Программисты С-подобных языков могут сравнить case с весьма подобной конструкцией switch в этих языках. Стоит отметить, что case в Паскале защищён от случайного выполнения следующей инструкции, т.е. нет необходимости уделять внимание тому, чтобы размещать инструкцию break в конце каждого блока. После выполнения ветви условия программа автоматически закончит обработку конструкции case и продолжит работу далее.

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

Общепринято, что префикс перечисляемого типа состоит из двух букв сокращения имени типа, следовательно ak = сокращение для "Animal Kind". Это полезное соглашение, так как имена перечисляемых типов находятся в глобальном пространстве переменных unit-а. Таким образом, с помощью префикса ak автоматически уменьшаются шансы на случайный конфликт с другими идентификаторами.

Прозрачность перечисляемого типа означает, что он не совместим напрямую с целочисленными величинами. Тем не менее, если такая совместимость необходима, можно использовать Ord(MyAnimalKind), чтобы вручную привести список к целочисленному типу. Обратная операция будет выглядеть как приведение типа TAnimalKind(MyInteger) и превратит целое число в соответствующий перечисляемый тип. В последнем случае необходимо также быть уверенным, что MyInteger является частью диапазона от 0 до Ord(High(TAnimalKind))).

Перечисляемые типы могут быть также использованы в качестве индексов массивов фиксированной длины:

Они также могут использоваться для создания наборов (они же set-ы, они же внутренние битовые поля):

Примечания:

Для простого вывода строки в Паскале используется процедура Write или WriteLn. Во втором случае в конце автоматически добавляется символ переноса строки.

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

Чтобы явным образом добавить перенос строки можно использовать константу LineEnding (из библиотеки FPC RTL). (Castle Game Engine имеет также более краткий вариант NL). В отличии от HTML и других подобных синтаксисов разметок в Паскале обратная косая (\) не позволяет вставлять специальные символы в строке, например:

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

или так:

Стоит отметить, что функции Write/WriteLn будут работать только в консольных приложениях. Для этого необходимо указывать {$apptype CONSOLE} (но не {$apptype GUI}) в главном файле программы. На некоторых ОС консоль явно или скрыто присутствует всегда (Unix) и эта директива не используется. А в некоторых системах попытка выполнения Write/WriteLn из GUI приложения приведёт к ошибке (например, в Windows).

В Castle Game Engine не советуется использовать WriteLn, поскольку для этого есть специальная функция WriteLnLog или WriteLnWarning для вывода логов и отладочной информации. Их результат всегда будет направлен в полезном направлении: для Unix-подобных систем это будет стандартный вывод в консоль. Для Windows GUI приложений это будет лог-файл. В Android вывод будет направлен в Android logging facility (инструмент логов Андроида), который можно просматривать с помощью команды adb logcat. Использовать WriteLn есть смысл лишь в ограниченном наборе случаев, например, для консольных приложений (исполняемых из командной строки) в которых можно быть точно уверенным, что стандартный вывод определён. Например, так можно делать в конвертере или генераторе трёхмерных моделей, который предназначен для запуска из командной строки.

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

Не только основная программа, но и unit-ы также могут ссылаться на другие unit-ы. Другой unit может войти в секцию interface или только в implementation. Первый вариант позволяет создавать новые определения (процедуры, типы…​), используя или наследуя информацию из другого unit-а. Во втором варианте возможности более ограничены - если использовать unit в секции implementation, то применить его идентификаторы возможно лишь в рамках implementation данного unit-а.

Запрещено применять кольцевую взаимозависимость (cyclic reference) в разделе interface. Т.е. два unit-а не могут использовать друг друга в разделе interface. Причина такого ограничения заключается в том, что для того, чтобы "понять" секцию interface unit-а, компилятор анализирует и "понимает" все unit-ы, перечисленные в uses в секции interface. В Паскале это правило придерживается строго, что позволяет достичь высокой скорости компиляции и полностью автоматическое определение компилятором что именно необходимо перекомпилировать. В Паскале нет необходимости создания сложных Makefile для выполнения простой задачи компиляции, а также нет нужды перекомпилировать всё лишь для того, чтобы удостовериться, что все зависимости правильно обновились.

Вполне возможно создавать кольцевые зависимости между unit-ами когда один из них "используется" только в implementation. Поэтому нормально для A использовать B в interface, и затем unit B использует A в implementation.

Различные unit-ы могут определять одинаковые идентификаторы. Чтобы поддерживать код простым для чтения и правки, обычно следует избегать таких совпадений, но не всегда это возможно. В таких случаях, последний unit в списке uses "перетягивает одеяло на себя", т.е. идентификаторы определённые в нём скрывают одноимённые идентификаторы введённые другими unit-ами ранее.

Однако, возможно недвусмысленно определить unit предоставляющий идентификатор, с помощью конструкции MyUnit.MyIdentifier. Это стандартное решение ситуации, когда используемый идентификатор из MyUnit скрыт идентификатором из другого unit-а. Для достижения этой же цели можно просто перестроить порядок unit-ов в списке uses, однако это повлияет на все идентификаторы, что не всегда желательно.

В случае unit-ов следует также помнить, что они могут иметь два списка uses: один - в секции interface, другой - в implementation. Основное правило в этом случае звучит как: "позднейшие unit-ы скрывают все что было до этого" и применяется последовательно, что в свою очередь означает, что unit-ы использованные в секции implementation могут скрывать идентификаторы из unit-ов использованных в секции interface. Кроме того, не стоит забывать, что в процессе обработки секции interface данного unit-а компилятором, влияют лишь unit-ы использованные в секции interface. Это может сбить с толку в ситуациях, когда два на вид одинаковых объявления обрабатываются компилятором по-разному:

Unit Graphics (из набора библиотек Lazarus LCL) определяет тип TColor. Но компилятор указывает на ошибку в этом unit-е, указывая на то, что заявленная в секции Interface процедура ShowColor не описана. Проблема в том, что unit GoogleMapsEngine также определяет тип TColor, который используется только в секции implementation, следовательно он перекрывает определение TColor в секции implementation. Т.е. компилятор видит это буквально как:

В данном случае решение тривиальное: необходимо просто изменить implementation, чтобы явно использовать TColor из unit-а Graphics. Это также можно исправить, переместив GoogleMapsEngine в секцию interface до unit-а Graphics. Впрочем, это может привести к другим последствиям внутри unit-а UnitUsingColors, так как коснётся всех его определений.

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

В некоторых случаях это делается из-за необходимости сохранить обратную совместимость с предыдущими версиями unit-а. А иногда таким образом удобно "скрыть" какой-либо unit для внутреннего пользования.

Это может быть осуществлено с помощью повторного объявления идентификатора в новом unit-е.

Стоит отметить, что данный трюк не пройдёт с глобальными процедурами, функциями и переменными. В таком случае возникнет необходимость объявить постоянный указатель на процедуру в другом unit-е (см. Колбэки — они же события, они же указатели на функции, они же процедурные переменные), но такой код выглядит не совсем чисто.

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

Чтобы проделать то же с глобальными параметрами иногда используются глобальные (на уровне unit-а) свойства, см. Свойства.

В Паскале для объектно-ориентированного программирования чаще всего используются классы (classes). На базовом уровне класс просто является "контейнером", который может вмещать в себя:

Паскаль поддерживает наследование и виртуальные методы объектно-ориентированного программирования.

По умолчанию методы не являются виртуальными и для объявления их виртуальными необходимо использовать ключевое слово virtual. Перекрытие или замещение виртуального метода осуществляется с помощью ключевого слова override, иначе компилятор выдаст ошибку. Чтобы скрыть метод без перекрытия используется ключевое слово reintroduce, впрочем, без особых на то причин, так делать не стоит.

Чтобы узнать, является ли некоторый класс из семейства классов конкретным его наследником можно использовать оператор is. Для выполнения приведения типа класса к конкретному классу следует использовать оператор as.

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

Свойства (Properties) являются "синтаксическим сахаром" (прим. перев. syntax sugar - жаргон, означающий синтаксические возможности, применение которых не влияет на поведение программы, но делает использование языка более удобным для программиста) который можно использовать с целью:

Стоит обратить внимание, что вместо того, чтобы указать метод для чтения или записи, можно напрямую указать читаемое/записываемое поле (которое обычно является private и весьма часто имеет название идентичное property с дополнительным префиксом f (от field - поле)) чтобы непосредственно получать или устанавливать значение. В примере выше, свойство Color использует setter-метод SetColor. Однако, для получения значения свойство Color напрямую ссылается на private поле FColor. Прямая ссылка на конкретное поле, очевидно, быстрее, чем написание дополнительных методов getter или setter - как с точки зрения разработки, так и с точки зрения скорости исполнения программы.

При объявлении свойства указывается:

Компилятор следит за тем, чтобы типы и параметры соответствующих полей и методов совпадали с типом свойства с которым они работают. Например, чтобы прочитать свойство Integer следует или предоставить поле Integer, или беспараметрический метод (функцию), который возвращает Integer.

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

В паскале можно вызывать и использовать исключения. Их можно "ловить" с помощью конструкции try …​ except …​ end, также можно применять секцию "выполнить в конце" try …​ finally …​ end.

Обратите внимание, что раздел finally будет выполнен даже в случае, если выполнение будет прекращено командой Exit (из функции, процедуры или метода), операторами Break или Continue (внутри тела цикла).

Как и в большинстве других объектно-ориентированных языков, в Паскале имеются визуальные спецификаторы для ограничения "видимости" полей / методов / свойств.

Основные уровни видимости являются следующими:

Краткое описание private и protected, данное выше, не полностью верно. Код в текущем unit-е может преодолевать эти границы, и получать доступ к секции private и protected. Иногда это полезная особенность, позволяющая реализовывать тесно связанные классы. В остальных же случаях следует использовать strict private или strict protected для организации полной недоступности данных методов, полей или свойств извне класса. Детальнее этот вопрос рассматривается в разделе Различие private и strict private.

По умолчанию, если видимость не указана явно, то она соответствует public. исключение составляют классы, которые объявляются при включённой директиве {$M+}, либо наследники классов, которые были скомпилированы при {$M+}, что включает в себя всех потомков TPersistent, включая потомков TComponent, который сам является потомком TPersistent. Для таких классов по умолчанию видимость принимается published, которая подобна public, однако позволяет работать с ними с помощью потоковой (stream) системы.

Однако, не каждому типу поля или свойства позволено быть в секции published - не каждый тип может быть конвертирован в поток (stream), и лишь классы, состоящие из простых полей, могут передаваться потоком. Если нет необходимости создавать потоки, но нужно просто сделать что-то доступное для всех пользователей, то следует использовать public.

Если явно не объявить родительский класс, то по умолчанию каждый class наследует TObject.

Чтобы избежать утечек памяти, все экземпляры класса должны быть освобождены вручную. Хорошей практикой является использование опции компилятора FPC -gl -gh, чтобы обнаруживать утечки памяти (более подробно см. https://castle-engine.io/manual_optimization.php#section_memory).

Следует обратить внимание, что это не касается вызванных исключений (raised exceptions). Не смотря на то, что при вызове исключения действительно создаётся класс (и это вполне обычный класс, для этих целей также можно создавать и свои классы), такой экземпляр класса освобождается автоматически.

Самым удобным методом освобождения класса является операция FreeAndNil(A) из unit-а SysUtils вызванная для данного экземпляра класса. Она проверяет, не имеет ли A значение nil, и если нет — вызывает его деструктор (destructor), и устанавливает значение A в nil. Таким образом повторный вызов данной процедуры не приведёт к ошибке.

Приблизительно это соответствует следующему:

Впрочем, эта аналогия немного упрощена, поскольку процедура FreeAndNil совершает ещё одно полезное действие, сразу устанавливая A значение nil до того как будет вызван destructor данного класса. Это позволяет избежать целой группы ошибок благодаря тому, что "внешний" код не сможет случайно получить доступ к не до конца уничтоженному экземпляру класса.

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

Т.е. освобождает класс A, если он не равен nil.

Стоит отметить, что в нормальных условиях никогда не стоит вызывать метод класса, ссылка на который может оказаться nil. По этому A.Free может выглядеть подозрительно на первый взгляд, поскольку A вполне может иметь значение nil. Однако, метод Free является исключением из этого правила. Это выглядит немного "грязновато" — а именно, выполняется проверка Self <> nil. Такой фокус работает только для не-виртуальных методов (т.е. в случае, если не вызываются виртуальные методы и не требуется доступ к полям класса).

По этому лучше всегда использовать FreeAndNil(A), без исключений, и никогда не использовать метод Free или напрямую деструктор Destroy. Такой концепции придерживается Castle Game Engine. Это позволяет быть уверенным, что все ссылки либо равны nil, либо указывают на существующий рабочий экземпляр класса.

Во многих ситуациях, освобождение экземпляра класса не является чем-то сложным. Просто пишется destructor, как пара соответствующему constructor-у, и освобождает все классы, память для которых была выделена в constructor-е (а, точнее, в продолжении всего времени существования класса). Важно следить за тем, чтобы освобождать каждый класс лишь один раз. Хорошей практикой будет всегда присваивать освобождённой ссылке значение nil, а наиболее удобно сделать это, вызвав команду FreeAndNil(A).

Например:

Чтобы избежать необходимости каждый раз явным образом освобождать экземпляр класса, можно использовать полезную особенность TComponent, которая называется "owner" (владение дочерним классом). Класс у которого есть owner (владелец) будет автоматически освобождён его owner-ом. Механизм очень гибкий и никогда не освобождает классы, которые уже освобождены, т.е. всё будет работать правильно в случае, если класс был освобождён ранее. Таким образом предыдущий пример можно переписать следующим образом:

Следует обратить внимание, что также необходимо override виртуальный constructor от TComponent. Это, в свою очередь, означает, что нельзя изменять параметры constructor-а. Впрочем, всё-таки это возможно — объявив новый constructor с ключевым словом reintroduce. Однако здесь стоит быть осторожным, так как некоторый функционал, например, streaming, всё равно будет использовать виртуальный constructor, по этому следует удостовериться, что во всех возможных случаях всё будет работать корректно.

Обратите внимание, что всегда можно использовать nil в качестве owner-а. Таким образом для данного компонента не будет owner-класса и класс не будет освобождён автоматически. Это может оказаться полезным, если необходимо использовать класс на основе TComponent, сохранив при этом возможность освобождать его вручную. Таким образом просто создавать наследника компонента следующим образом: ManualGun := TGun.Create(nil);.

Ещё один удобный механизм автоматического освобождения памяти — функционал OwnsObjects (который по умолчанию равен true) классов-списков, таких, как TFPGObjectList или TObjectList. Т.е. можно сделать следующим образом:

Заметим, что механизм owner-ов классов-списков простой (без дополнительных проверок) и, в случае освобождения содержащегося в списке экземпляра класса сторонним кодом, впоследствии возникнет ошибка. Чтобы исключить что-либо из списка без освобождения используется метод Extract, однако это также означает, что в дальнейшем элемент придётся освободить вручную.

Например, в Castle Game Engine все наследники класса TX3DNode автоматически управляют памятью при добавлении другой TX3DNode в список children. Корневая X3DNode называется TX3DRootNode и, в свою очередь, обычно имеет своим owner-ом класс TCastleSceneCore. Другие классы также имеют простой механизм owner-а — обычно это обозначено параметром или свойством под названием вида OwnsXxx.

Если на экземпляр класса создано несколько ссылок, это эквивалентно тому, что две ссылки указывают на одну и ту же область памяти. Если освободить одну из них, вторая окажется "болтающимся" pointer-ом. Нельзя пытаться получить доступ к области памяти, которая была освобождена. Это может привести к runtime ошибке, либо может быть получено неопределённое значение ("мусор") — в случае, если эта область памяти уже была повторно выделена для других элементов внутри текущей программы.

В таком случае не достаточно просто вызывать FreeAndNil поскольку эта функция установит nil лишь для переданной ей ссылки — автоматического метода для подобных задач не существует. Рассмотрим следующий пример:

К решению такой проблемы есть несколько путей:

Для ввода / вывода в современных программах на Паскале используется класс TStream. У него также есть множество полезных производных классов, таких как TFileStream, TMemoryStream, TStringStream и т.п.

В Castle Game Engine следует использовать функцию Download для создания потока, который загружает данные с любого заданного URL. Это могут быть обычные файлы, ресурсы, хранящиеся на HTTP и HTTPS, Android assets и много других. Более того, для однозначного кросс-платформенного указания на папку игровых данных (хранящихся в папке data) следует использовать функцию ApplicationData или особый тип URL castle-data:/xxx URL. Например:

Чтобы прочитать обычный текстовый файл лучше использовать класс TTextReader из CastleClassUtils. Он предоставляет построчный API, как надстройку над TStream. URL можно задать через конструктор класса TTextReader, либо можно передать ему готовый TStream вручную.

Для создания различных списков переменной длинны, лично я советую использовать generic классы из unit-а FGL. Можно использовать TFPGList для простых типов данных (включая record-ы или устаревшие object-ы), и TFPGObjectList для списка экземпляров классов. В Castle Game Engine: можно также использовать TGenericStructList из CastleGenericLists для создания списков record-ов или устаревших object-ов. Это позволяет обойти проблему невозможности override их операторов в старых версиях FPC.

Применение таких списков является хорошей идеей по нескольким причинам: они типо-безопасны и их API имеет много полезных функций, таких как поиск, сортировка, итерация и т.п. Вообще говоря, не стоит использовать динамические массивы (array of X, SetLength(X, …​)) поскольку их API очень неудобный - можно применить лишь SetLength. Также не желательно использовать TList или TObjectList поскольку это потребует преобразование типа из общего TObject в конкретный тип класса при каждом обращении.

Стандартным подходом для создания копии экземпляра класса является наследование этим классом TPersistent с последующим override его метода Assign. Здесь нет ничего сложного, просто нужно в методе Assign прописать копирование полей, которые Вам необходимы.

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

Иногда более удобно написать альтернативный override метода AssignTo в копируемом классе, а не делать override метода Assign в классе, в который выполняется копирование.

Следует быть осторожным с inherited при написании Assign. Inherited из TPersistent.Assign должен вызываться исключительно в случаях, если Вы не можете самостоятельно выполнить копирование в своём коде (это позволит использовать метод AssignTo и создавать сообщения об ошибках, в случае, если копирование не может быть выполнено). С другой стороны, если данный класс является производным от класса, в котором уже есть метод Assign, то в данном случае следует обязательно вызывать inherited из TMyClass.Assign. См. пример выше.

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

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

Данные два примера абсолютно эквивалентны:

И второй вариант, в котором Square получает прямой доступ к переменной I:

Местные процедуры могут быть многократно вложенными — что означает, что внутри локальной процедуры можно определить местную локальную под-процедуру и т.д. Однако, не желательно этим увлекаться, поскольку в результате код может стать совершенно нечитабельным.

Они позволяют вызвать функцию не прямым указанием её названия, а посредством переменной. Эта переменная может быть назначена во время исполнения кода для указания на любую функцию с указанными типами параметров и возвращаемых величин.

Колбэки могут быть:

Generic-и - это очень мощная функция современных языков. Определение чего-либо (обычно - класса) может быть конкретизировано другим типом. Наиболее естественным примером является необходимость создать контейнер (список, словарь, дерево, граф…​): можно определить список типа T, а потом specialize (конкретизировать) его чтобы сразу получить список из integer, список из string, список из TMyRecord и т.д.

Generic-и в Паскале реализованы весьма подобно generic-ам в C++. Это означает, что они "конкретизируются" когда происходит specialize, что немного похоже на поведение макросов (однако, когда тип "конкретизирован", используются только эти конкретные определения, и таким образом невозможно "добавить" какое-либо неожиданное поведение в generic после его "конкретизации"). Преимуществом их является высокая скорость выполнения (оптимизированная для каждого конкретного типа) и поддержка типов любого размера. Можно использовать примитивные типы (integer, float) а также record, class и т.п. при specialize данного generic-а.

Возможности generic-ов не ограничиваются классами, можно создать generic функции и процедуры:

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

По умолчанию overload использует стиль FPC. Это означает, что абсолютно все имена в пространстве имён (в классе или unit-е) равны, и скрывает все остальные методы в пространстве имён с более низким приоритетом. Например, если создать класс с методом Foo(Integer) и Foo(string), и при этом класс наследует класс в котором уже есть Foo(Float), то метод Foo(Float) невозможно будет вызвать напрямую, только с помощью приведения типа данного класса к родительскому классу. Чтобы избежать такого поведения, при объявлении процедур и функций следует использовать ключевое слово overload.

Можно использовать простые директивы предобработки кода с целью:

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

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

Record является своеобразным контейнером для других переменных. Она является очень, очень упрощённым классом: в record-ах нет наследования, нет виртуальных методов. Они несколько подобны structure в C-подобных языках.

Применяя директиву {$modeswitch advancedrecords}, появляется возможность добавить методы и уровни видимости в record и использовать любые особенности языка, доступные классам, которые не нарушают простую и предсказуемую раскладку памяти для record.

В современном Паскале, в первую очередь лучше использовать class, а не record, поскольку классы имеют множество дополнительных полезных возможностей, как конструкторы и наследование. Однако, record-ы всё ещё могут оказаться полезными если необходима скорость или предсказуемая раскладка памяти:

Давным-давно, в Turbo Pascal был введён новый тип синтаксиса с функционалом, похожим на классы, который задавался ключевым словом object. По сути, это - нечто среднее между record и современным class.

В большинстве случаев крайне не советуется использовать устаревшие objects-ы. Современные class-ы имеют гораздо более широкий функционал. А в случае если необходимо повысить скорость выполнения, можно использовать record-ы (включая advanced records). Такие подходы обычно лучше, чем устаревшие object-ы.

В Паскале возможно создать pointer (указатель) на любой тип данных. Указатель на тип TMyRecord определяется с помощью синтаксиса ^TMyRecord, и чаще всего такие pointer-ы называют PMyRecord. В качестве классического примера рассмотрим связанный список целых чисел, организованный с помощью record:

Следует обратить внимание, что здесь было использовано рекурсивное определение (тип PMyRecord определяется с помощью TMyRecord, а TMyRecord использует в своём определении PMyRecord). Можно определить pointer на тип, который ещё не был объявлен, в том случае, если он будет определён в том же самом блоке type.

Можно распределять и освобождать память для pointer-ов с помощью методов New / Dispose, или (более низкоуровневых, но не типобезопасных) методов GetMem / FreeMem. Для доступа к данным, на которые pointer указывает, после него следует добавить оператор ^ (в виде MyInteger := MyPointerToInteger^). Обратная операция (получить pointer на существующую переменную) выполняется с помощью оператора-префикса @ (например, MyPointerToInteger := @MyInteger).

Существует также самый общий тип Pointer, который не указывает на конкретный тип данных и подобен void* в C-подобных языках. Он совершенно не типобезопасен, и его можно привести его тип в любой другой тип pointer-а.

Следует помнить, что экземпляр класса также является pointer-ом, хоть для работы с ним и не нужно использовать дополнительных операторов ^ и @. Рекурсивные определения также возможны и для классов, и в данном случае всё будет выглядеть ещё проще:

В Паскале существует возможность "перегрузить" (overload) значение многих операторов языка, например определить сложение и умножение пользовательских типов данных. Рассмотрим следующий пример:

Можно также перегружать операторы над классами. Учитывая то, что обычно в такой функции-операторе создаётся новый экземпляр класса, вызывающий код должен позаботиться об надлежащем освобождении памяти.

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

При работе с record-ами лучше использовать режим {$modeswitch advancedrecords} и перегружать операторы в виде class operator внутри объявления record-а. Такой подход позволяет использовать generic классы которые зависят от существования какого-либо оператора (например TFPGList, который зависит от доступности оператора равенства). В противоположном случае "глобальное" определение оператора (не внутри объявления данной record) не будет найдено (поскольку оно не доступно коду, который используется в TFPGList), и не удастся specialize список в виде specialize TFPGList<TMyRecord>.

Спецификатор видимости private означает что поле или метод не доступны извне данного класса. Однако из данного правила есть одно исключение: любой код в данном unit-е может преодолеть это ограничение и иметь полный доступ к private полям и методам. Программист на C++ сказал бы, что в Паскале все классы в одном unit-е являются "друзьями". Часто это весьма удобно.

Однако, при создании unit-ов большого размера со множеством не очень близко интегрированных классов, более безопасным является применение видимости strict private. Как можно легко догадаться, это означает что поле или метод не доступны извне данного класса. Точка. Никаких исключений.

Таким же образом различаются спецификаторы видимости protected (видимый наследникам данного класса или "друзьям" в том же unit-е) и strict protected (видимы только и исключительно наследникам данного класса. Точка).

Внутри определения класса можно создавать константы (const) или типы (type). Таким образом можно даже создать класс внутри класса. Спецификаторы видимости будут работать как обычно, и такие локальные классы могут быть private (не видимые "внешнему миру"), что иногда удобно.

Следует обратить внимание, чтобы определить поле после константы или типа будет необходимо использовать блок var:

Существуют методы, которые можно вызвать из класса вообще (TMyClass), не обязательно из его конкретного экземпляра.

Обратите внимание, что они также могут быть виртуальными — иногда это весьма удобно, особенно, если применяется совместно с понятием Ссылки на класс.

Следует отметить, что constructor всегда работает, как class method когда вызывается "обычным образом" (MyInstance := TMyClass.Create(…​);). Впрочем, можно вызвать конструктор в данном конкретном экземпляре класса как метод — и он тогда и сработает как обычный метод. Таким образом можно сделать удобную "цепочку" constructor-ов, когда один constructor (например, перегруженный для принятия дополнительных параметров) выполняет определённый код, а затем вызывает другой constructor (например, беспараметрический).

Ссылки на класс позволяют выбрать класс в процессе исполнения программы, например, для вызова class method-а или constructor-а не определив заранее, какой именно класс будет использоваться. Такой тип объявляется следующим образом: class of TMyClass.

Ссылки на класс можно комбинировать с виртуальными class method-ами. Работает это подобно классам с виртуальными методами — конкретный метод, который необходимо выполнить определяется уже в процессе выполнения программы.

Если есть экземпляр класса и необходимо создать ссылку на этот класс (не на какой-либо объявленный класс, а на конкретного наследника, который был использован при создании данного экземпляра класса), можно использовать свойство ClassType. Вообще говоря, объявленный тип ClassType является TClass, который в свою очередь является class of TObject. Его тип можно привести во что либо более конкретное, когда есть информация, чем именно является данный экземпляр.

ClassType также можно использовать для вызова виртуальных методов, включая виртуальные constructor-ы. Такой подход позволяет создать такие методы, как Clone которые создают экземпляр как точную копию данного класса в конкретный момент исполнения программы. Можно совместить такой подход с Assign (см. Клонирование классов: TPersistent.Assign) для того, чтобы метод возвращал новую, готовую к работе копию текущего экземпляра.

Следует обратить внимание, что подобный подход сработает только если constructor данного класса виртуальный. Например, его можно использовать с наследниками стандартного класса TComponent, поскольку все они выполняют override виртуального constructor-а TComponent.Create(AOwner: TComponent).

Метод является лишь процедурой внутри конкретного класса. Извне класса он вызывается с помощью специального синтаксиса MyInstance.MyMethod(…​). И через некоторое время приходит привычка, что если нужно произвести действие над классом X, следует писать X.Action(…​).

Однако, иногда возникает необходимость выполнить что-либо, что концептуально является действием на класс TMyClass, однако при этом не изменяя исходный код TMyClass. Причин тому может быть несколько. Например, это может быть исходный код, написанный другим программистом, который не следует или невозможно изменять. Также иногда причиной тому могут быть зависимости — добавление метода Render к классу TMy3DObject кажется вполне логичным, однако, возможно, имплементация класса TMy3DObject должна быть независимой от кода рендера? В таких случаях удобнее "расширить" существующий класс, добавив к нему функционал, при этом не изменяя его исходный код.

Наиболее простой путь сделать это - создать глобальную процедуру, которая будет принимать ссылку на TMy3DObject как параметр.

И это действительно сработает. Однако, недостаток такого подхода - он выглядит не очень красиво. Ведь обычно мы вызываем действия над классом с помощью X.Action(…​), а тут нам приходится использовать иной синтаксис: Render(X, …​). Было бы куда удобнее записать X.Render(…​), даже для случаев, когда Render не описан в unit-е, в котором находится TMy3DObject.

Для этого и существуют class helper-ы, дающие возможность создать процедуры/функции, которые оперируют данным классом и вызываются таким же образом, как и остальные методы класса. Однако они не являются "обычными" методами — они "добавляются" извне определения класса TMy3DObject.

Имя destructor-а всегда должно быть Destroy, и он всегда является virtual (поскольку он вызывается без указания конкретного класса при компиляции) и беспараметрический.

В качестве имени constructor-а принято использовать Create. Можно использовать и другое имя, однако здесь следует быть аккуратным — например, создав CreateMy, всегда создайте и Create, иначе constructor Create будет всё равно доступен из родительского класса и может быть вызван в обход конкретного CreateMy конструктора.

В базовом классе TObject constructor не является виртуальным, и при создании наследников его можно изменить. Новый constructor просто спрячет constructor родительского класса (примечание: не используйте overload, в данном случае это не сработает).

В наследниках же класса TComponent, следует выполнять constructor Create(AOwner: TComponent); override;. Для решения задач потоковой передачи данных, а также для создания класса без указания конкретного типа при написании программы, виртуальные constructor-ы являются очень удобными (см. раздел Ссылки на класс выше).

Что произойдёт если в процессе выполнения constructor-а возникнет ошибка? Строка

не будет выполнена до конца, и X не может быть присвоено какое-либо значение. Кто будет выполнять очистку после частично сконструированного класса?

В объектном Паскале существует следующее решение. Если возникла ошибка при исполнении constructor-а, то сразу вызывается destructor. Именно по этой причине этот destructor должен быть "дубовым", т.е. сработать в любом случае, даже на частично сконструированном классе. Обычно это не сложно, если освобождать всё безопасным образом, например, с помощью FreeAndNil.

Также можно полагаться на факт, что перед вызовом constructor-а вся память гарантированно обнуляется. Таким образом, при создании все ссылки внутри класса являются nil, а числа равны 0 и т.п.

Т.е. следующий код сработает без утечек памяти:

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

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

Интерфейсы CORBA в Object Pascal работают в значительной степени так, как и интерфейсы в Java (https://docs.oracle.com/javase/tutorial/java/concepts/interface.html) или в C# (https://msdn.microsoft.com/en-us/library/ms173156.aspx).

GUID-ы это на первый взгляд случайная последовательность букв и цифр ['{ABCD1234-…​}'] которую можно увидеть при каждом объявлении интерфейса. В действительности, они и являются случайными. Но, к сожалению, в них есть необходимость. Никакого особого смысла в них не вкладывается (если не планируется интеграция с технологиями COM или CORBA). Однако, для правильного исполнения программы они обязательны. И пусть не сбивает с толку компилятор, который, увы, позволяет создавать интерфейсы без GUID-ов.

Без присваивания (уникального) GUID-а, все интерфейсы будут идентичными для оператора is. Таким образом, он всегда будет возвращать true если данный класс поддерживает любой из используемых интерфейсов. "Волшебная" функция Supports(ObjectInstance, IMyInterface) работает несколько лучше в данном случае, поскольку выдаст ошибку компиляции для интерфейсов без GUID. Это касается и CORBA, и COM интерфейсов, для версии FPC 3.0.0.

Таким образом, необходимо обязательно объявлять GUID для каждого интерфейса. Можно использовать встроенный генератор GUID-ов Lazarus GUID generator (горячая клавиша Ctrl + Shift + G в режиме редактирования). Либо воспользоваться он-лайн сервисом, например https://www.guidgenerator.com/.

А можно вообще написать свой инструмент, использующий CreateGUID и GUIDToString функции из RTL. Например, следующим образом:

Использование COM интерфейсов даёт две дополнительных возможности:

На мой взгляд, неправильно переплетать интерфейсы с такими возможностями. Это усложняет использование интерфейсов для того, для чего они предназначены: когда у многих классов один и тот же API, однако они не могут происходить от одного родительского класса. Используя же COM интерфейс, следует помнить о механизме автоматического уничтожения и его отношении к технологии COM.

На практике это означает следующее:

Чтобы безопасно использовать COM интерфейсы необходимо

Ниже представлен пример использования такого интерфейса:

Как уже было упомянуто в прошлом разделе, в классах, наследующих TComponent (либо подобные классы, такие как TNonRefCountedInterfacedObject и TNonRefCountedInterfacedPersistent) отключено reference-counting для COM интерфейсов. Это позволяет использовать COM интерфейсы и при этом даёт возможность освобождать классы вручную.

Всё же, необходимо быть аккуратным в этом случае, чтобы не освободить класс, когда какая-либо переменная интерфейса ссылается на него и не забывать, что каждая операция приведения типа в виде Cx as IMyInterface также создаёт временную переменную интерфейса, которая может существовать вплоть до конца текущей процедуры. Этот пример иллюстрирует процедуру UseInterfaces, которая освобождает классы вне этой процедуры (когда мы можем быть уверены, что временная переменная интерфейса вышла из текущего поля переменных).

Чтобы избежать этих неудобств, лучше использовать интерфейсы CORBA, если в данной программе нет необходимости параллельного использования reference-counting и интерфейсов.

Этот раздел касается как CORBA, так и COM интерфейсов. Впрочем, также отмечены некоторые особенности CORBA интерфейсов.

Можете всё это попробовать, поиграв со следующим примером: