softwarer2. Ваше мнение по поводу именования класса в стиле константы как следствия его употребления в коде вместо константы.
Красиво конечно, но как-то не то...
Лучше использовать паттерн "стратегия" в стандартном исполнении.
Тем более, что объект класса может создаватся с параметрами в конструкторе.
Решение не гибкое, получается.
Да и не нужно все задачи сводить к максимальному использовании свойств [property], не всегда это уместно, как мне кажется.

softwarer Я с интересом выслушаю альтернативные предложения в задаче "объекту должен задаваться режим работы (одно из трёх на текущий момент возможных значений); должна быть возможность узнать текущий режим работы объекта".
Раз уж со свойствами, то может быть так:
Установка свойства так:
Что касается своего опыта: когда создается абстрактный класс, а потом от него наследуются другие, то в конструкторах появляются различные параметры. Что резонно, т.к. добавляются новые переменные в классе. Для каждого подкласса список параметров может быть разный, поэтому, через какую-нибудь абстрактную функцию Init выкрутится по-нормальному не удастся.
Обычно стратегия сама по себе не работает, а пользуется ссылками на другие объекты.
Поэтому использование конструктора с параметрами - вполне обычное явление для паттерна "стратегия", хотя и не обязательная.
Хотя можно и обойтись и инструкцией case и обычым свойством, которой номер стратегии указывает. Тут нужно по ситуации смотреть.

softwarerИмхо неактуально.
Мож я напутал чего, но подставляю я стратегию, поэтому путаница в терминах.
Module.XYStrategy := TXYStrategy1.Create(...);
Да и у атомарного свойства вряд ли может быть такое:
function Something (..); virtual; abstract;
Поэтому Вам нужно определится, что же Вам нужно реализовать: простое свойство или паттерн "стратегия"?

softwarerВы предложите реализовать иначе?
Да вообще по-разному можно, Ваш вариант вполне работоспособен.
Я конечно много лишнего тут понаписал, не сообразил сразу, не судите строго.
softwarerименования класса в стиле константы как следствия его употребления в коде вместо константы

Это меня и сбило с толку.

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