Delphi: Запишите конструктора по сравнению с функцией фабрики
Безоговорочно, я рекомендую Последовательный порт Java с serialio.com; у меня были значительные проблемы устойчивости с Sun, IBM и RxTx последовательный пакет. SerialPort был горным телом в производстве 24/7 больше 5 лет.
Они поддерживают стандартный Java последовательный API, а также их собственный альтернативный собственный. Я придерживался бы стандартного API, хотя, если Вам действительно не нужно что-то их, имеет это, стандартный не делает, только чтобы не торопиться с решением.
3 ответа
Я предпочитаю классы, но если мне приходится использовать записи, я предпочитаю обращаться с ними как с похожими классами. Поэтому я использую конструктор записей.
Но есть досадная ошибка с записями и единицами измерения. Если функция возвращает запись (с методами), она вызывает внутреннюю ошибку, если вы хотите получить доступ к этим методам. Вы можете обойти это, назначив его другой переменной:
type
TMyRec = record
..
procedure X;
end;
function GetRec: TMyRec;
procedure Test;
var
r1, r2 : TMyRec;
begin
r1 := GetRec;
r1.X; // internal error
r2 := r1;
r2.X; // No internal error;
В проекте Delphi, который я создал, я использовал записи вместо классов, чтобы уменьшить количество накладных расходов на список. У меня было бы несколько сотен записей в динамическом массиве, поэтому я создал две записи. Первая запись касалась самого предмета. Поля были сделаны частными (да, вы можете использовать частные / защищенные с записями) и добавили свойства только для чтения в общедоступный раздел. Также был добавлен дополнительный конструктор для правильной инициализации записи. Эта установка позволила мне защитить содержимое этой записи от других разработчиков. Вторая запись была просто оберткой вокруг динамического массива предыдущего типа записи. Массив будет частным, и я добавил методы для получения, добавления и удаления записей в этом списке. В результате весь список защищен от неправильного использования другими разработчиками, а также имеет намного меньше накладных расходов, чем обычное решение TList / TObjectList.
Помните, что записи не являются классами. Вы не можете наследовать конструкторы и другие методы. У них меньше функциональности, чем у настоящих классов в среде WIN32. В .NET их снова просто переводят в классы. И не очень полезно использовать конструктор добавления, когда разработчики могут легко изменять содержимое каждого поля в вашей записи. Вместо этого вы должны использовать конструкторы для защиты этих полей.
Обычно я не создаю конструкторы для записей. Он не совместим со всеми версиями (и FPC). Более того, как правило, они используются только в одном месте, и часто бывает достаточно fillchar.