DP Delphi / Pascal · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Модули и области видимости

Этот тест проверяет не память на названия, а способность разбирать код, видеть границы механизма и выбирать исправление, которое не ломает соседние сценарии. Внутри 20 вопросов, из них 12 с фрагментами Object Pascal. Отдельные результаты показываются по разделам: «Устройство модуля», «Секции interface и implementation», «Зависимости uses» и «Инициализация модулей».

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: В каждом вопросе выберите один ответ из пяти. На весь тест отведено 55 минут. Код лучше сначала разобрать вручную: правильный вариант должен объяснять механизм, а не только совпадать с одним запуском.

Вопрос 1 из 20

Проследите изменение состояния в PriceApi: в `PriceApi` сначала встречается `function WithTax(const Value: TPrice): TPrice;`, а затем `Result := Value * (1 + TaxRate);`. Какой вывод можно сделать только после чтения обеих строк?

// Проследите фактическое поведение PriceApi.
unit PriceApi;
interface

type
  TPrice = Currency;
function WithTax(const Value: TPrice): TPrice;

implementation

const TaxRate = 0.20;
function WithTax(const Value: TPrice): TPrice;
begin
  Result := Value * (1 + TaxRate);
end;
end.

Все объявления модуля публичны, если явно не помещены в секцию `private`. Внутреннюю функцию можно вызвать из другого модуля по полному имени unit, даже если она в `implementation`. Модуль объявляет публичный контракт в `interface`, а реализацию и внутренние имена — в `implementation`. Чем больше типов экспортировано из `interface`, тем проще сохранять совместимость модуля. Объявление из `implementation` доступно клиенту, если у имени нет модификатора `private`.

Вопрос 2 из 20

Какой сценарий по теме «Секции interface и implementation» отличит исправную реализацию от версии со скрытым дефектом?

Объявления из `implementation` доступны всем модулям, перечисленным в его `uses`. Перенос любого `uses` из `interface` в `implementation` не влияет на экспортируемые типы и совместимость модуля. Глобальное состояние из `implementation` создаётся заново при каждом обращении к модулю. Глобальное состояние модуля живёт дольше отдельного вызова и требует явного контроля инициализации. Секция `implementation` влияет только на расположение кода, но не на видимость имён.

Вопрос 3 из 20

Правка по теме «Зависимости uses» должна сохранить полезное поведение и убрать риск на соседнем сценарии. Какое требование она обязана выполнить? Рассмотрите вариант, где меняется состояние, но внешний интерфейс остаётся прежним.

Порядок `initialization` совпадает с алфавитным порядком имён модулей. Зависимость в `interface` не влияет на перекомпиляцию клиентов модуля. Любую зависимость можно перенести из `interface uses` в `implementation uses` без изменения публичных типов. Цикл между модулями устраняется перестановкой имён в списке `uses`. `uses` в секции `interface` создаёт публичную зависимость и чаще участвует в циклах.

Вопрос 4 из 20

Какой сценарий по теме «Инициализация модулей» отличит исправную реализацию от версии со скрытым дефектом?

Секции `initialization` выполняются в алфавитном порядке имён модулей. `finalization` идёт в том же порядке, что и `initialization`. Долгие сетевые операции в `initialization` безопасны, потому что интерфейс приложения уже создан. Тяжёлые действия и скрытые взаимные ожидания здесь делают запуск и остановку хрупкими. `finalization` выполняется в том же порядке, что и `initialization`, чтобы зависимости оставались доступными.

Вопрос 5 из 20

Какое свойство темы «Устройство модуля» становится решающим на граничном входе или при другом порядке действий?

Все объявления модуля публичны, если явно не помещены в секцию `private`. Чем больше типов экспортировано из `interface`, тем проще сохранять совместимость модуля. Объявление из `implementation` доступно клиенту, если у имени нет модификатора `private`. Наружу следует выпускать минимальный набор типов и процедур. Внутреннюю функцию можно вызвать из другого модуля по полному имени unit, даже если она в `implementation`.

Вопрос 6 из 20

Модуль, использующий тему «Секции interface и implementation», передают другой команде. Какую ответственность нужно закрепить во внешнем договоре?

Объявления из `implementation` доступны всем модулям, перечисленным в его `uses`. Имя, объявленное только в `implementation`, не видно клиентам модуля. Секция `implementation` влияет только на расположение кода, но не на видимость имён. Глобальное состояние из `implementation` создаётся заново при каждом обращении к модулю. Перенос любого `uses` из `interface` в `implementation` не влияет на экспортируемые типы и совместимость модуля.

Вопрос 7 из 20

Модуль, использующий тему «Зависимости uses», передают другой команде. Какую ответственность нужно закрепить во внешнем договоре?

Зависимость в `interface` не влияет на перекомпиляцию клиентов модуля. Цикл между модулями устраняется перестановкой имён в списке `uses`. Любую зависимость можно перенести из `interface uses` в `implementation uses` без изменения публичных типов. Перенос зависимости в `implementation` допустим лишь тогда, когда она не нужна в экспортируемых объявлениях. Порядок `initialization` совпадает с алфавитным порядком имён модулей.

Вопрос 8 из 20

В теме «Инициализация модулей» есть две независимые границы поведения. Какой внешний договор не смешивает их в одно расплывчатое правило?

Во внешний договор включают только второе свойство: тяжёлые действия и скрытые взаимные ожидания здесь делают запуск и остановку хрупкими; первое считают внутренней деталью. Во внешний договор включают только первое свойство: секции `initialization` выполняются в порядке зависимостей модулей, а `finalization` — в обратном; второе оставляют неявным. Обе границы заменяют предположениями «Долгие сетевые операции в `initialization` безопасны, потому что интерфейс приложения уже создан» и «`finalization` выполняется в том же порядке, что и `initialization`, чтобы зависимости оставались доступными». Первую границу заменяют предположением «Долгие сетевые операции в `initialization` безопасны, потому что интерфейс приложения уже создан», сохраняя только вторую. Внешний договор должен раздельно учитывать, что секции `initialization` выполняются в порядке зависимостей модулей, а `finalization` — в обратном, и что тяжёлые действия и скрытые взаимные ожидания здесь делают запуск и остановку хрупкими.

Вопрос 9 из 20

Две реализации темы «Устройство модуля» совпадают на обычном примере. Какое различие всё же меняет их договор?

Объявление из `implementation` доступно клиенту, если у имени нет модификатора `private`. Чем больше типов экспортировано из `interface`, тем проще сохранять совместимость модуля. Модуль объявляет публичный контракт в `interface`, а реализацию и внутренние имена — в `implementation`. Все объявления модуля публичны, если явно не помещены в секцию `private`. Внутреннюю функцию можно вызвать из другого модуля по полному имени unit, даже если она в `implementation`.

Вопрос 10 из 20

В практическом сценарии по теме «Секции interface и implementation» меняются входные данные и порядок действий. Какой вывод остаётся корректным?

Перенос любого `uses` из `interface` в `implementation` не влияет на экспортируемые типы и совместимость модуля. Глобальное состояние модуля живёт дольше отдельного вызова и требует явного контроля инициализации. Секция `implementation` влияет только на расположение кода, но не на видимость имён. Глобальное состояние из `implementation` создаётся заново при каждом обращении к модулю. Объявления из `implementation` доступны всем модулям, перечисленным в его `uses`.

Вопрос 11 из 20

В теме «Зависимости uses» есть две независимые границы поведения. Какой внешний договор не смешивает их в одно расплывчатое правило?

Обе границы заменяют предположениями «Порядок `initialization` совпадает с алфавитным порядком имён модулей» и «Цикл между модулями устраняется перестановкой имён в списке `uses`». Во внешний договор включают только первое свойство: `uses` в секции `interface` создаёт публичную зависимость и чаще участвует в циклах; второе оставляют неявным. Во внешний договор включают только второе свойство: перенос зависимости в `implementation` допустим лишь тогда, когда она не нужна в экспортируемых объявлениях; первое считают внутренней деталью. Внешний договор должен раздельно учитывать, что `uses` в секции `interface` создаёт публичную зависимость и чаще участвует в циклах, и что перенос зависимости в `implementation` допустим лишь тогда, когда она не нужна в экспортируемых объявлениях. Первую границу заменяют предположением «Порядок `initialization` совпадает с алфавитным порядком имён модулей», сохраняя только вторую.

Вопрос 12 из 20

Какое наблюдение должен зафиксировать тест именно для последовательности `initialization` → `finalization` в `RuntimeLog`?

// Определите реальную гарантию в RuntimeLog.
unit RuntimeLog;
interface
procedure WriteStartup;
implementation
uses System.SysUtils;
var
  Buffer: TStringBuilder;
procedure WriteStartup;
begin
  Buffer.AppendLine('started');
end;
initialization
  Buffer := TStringBuilder.Create;
finalization
  Buffer.Free;
end.

Секции `initialization` выполняются в алфавитном порядке имён модулей. Долгие сетевые операции в `initialization` безопасны, потому что интерфейс приложения уже создан. `finalization` выполняется в том же порядке, что и `initialization`, чтобы зависимости оставались доступными. Секции `initialization` выполняются в порядке зависимостей модулей, а `finalization` — в обратном. `finalization` идёт в том же порядке, что и `initialization`.

Вопрос 13 из 20

Реализацию темы «Устройство модуля» заменяют без изменения интерфейса. Какое наблюдаемое свойство обязано сохраниться?

Чем больше типов экспортировано из `interface`, тем проще сохранять совместимость модуля. Все объявления модуля публичны, если явно не помещены в секцию `private`. Наружу следует выпускать минимальный набор типов и процедур. Объявление из `implementation` доступно клиенту, если у имени нет модификатора `private`. Внутреннюю функцию можно вызвать из другого модуля по полному имени unit, даже если она в `implementation`.

Вопрос 14 из 20

Для темы «Секции interface и implementation» готовят регрессионный набор из двух разных сценариев. Какой набор действительно закрывает обе границы?

Проверка должна разделить два сценария: в первом наблюдается, что имя, объявленное только в `implementation`, не видно клиентам модуля; во втором — что глобальное состояние модуля живёт дольше отдельного вызова и требует явного контроля инициализации. Оба сценария опираются на предположения «Перенос любого `uses` из `interface` в `implementation` не влияет на экспортируемые типы и совместимость модуля» и «Перенос любого `uses` из `interface` в `implementation` не влияет на экспортируемые типы и совместимость модуля». Проверяется только второй сценарий: глобальное состояние модуля живёт дольше отдельного вызова и требует явного контроля инициализации; первое свойство не фиксируется. Проверяется только первый сценарий: имя, объявленное только в `implementation`, не видно клиентам модуля; второй не отделяется от обычного пути. Первый сценарий строят на предположении «Перенос любого `uses` из `interface` в `implementation` не влияет на экспортируемые типы и совместимость модуля», а второй оценивают без наблюдаемого результата.

Вопрос 15 из 20

Почему зависимость `Orders` от `Customers` становится частью публичного контракта модуля, а не только деталью реализации?

// Проследите фактическое поведение Orders.
unit Orders;
interface
uses Customers;
type
  TOrder = record
    Customer: TCustomer;
  end;
implementation
uses System.SysUtils;
end.

Порядок `initialization` совпадает с алфавитным порядком имён модулей. Цикл между модулями устраняется перестановкой имён в списке `uses`. Зависимость в `interface` не влияет на перекомпиляцию клиентов модуля. `uses` в секции `interface` создаёт публичную зависимость и чаще участвует в циклах. Любую зависимость можно перенести из `interface uses` в `implementation uses` без изменения публичных типов.

Вопрос 16 из 20

Две реализации темы «Инициализация модулей» совпадают на обычном примере. Какое различие всё же меняет их договор?

Тяжёлые действия и скрытые взаимные ожидания здесь делают запуск и остановку хрупкими. Долгие сетевые операции в `initialization` безопасны, потому что интерфейс приложения уже создан. Секции `initialization` выполняются в алфавитном порядке имён модулей. `finalization` идёт в том же порядке, что и `initialization`. `finalization` выполняется в том же порядке, что и `initialization`, чтобы зависимости оставались доступными.

Вопрос 17 из 20

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

На граничном пути нужно учитывать оба условия: модуль объявляет публичный контракт в `interface`, а реализацию и внутренние имена — в `implementation`; одновременно наружу следует выпускать минимальный набор типов и процедур. Первую границу заменяют предположением «Все объявления модуля публичны, если явно не помещены в секцию `private`», сохраняя лишь вторую. Граница определяется только первым условием: модуль объявляет публичный контракт в `interface`, а реализацию и внутренние имена — в `implementation`; второе не проверяется. Оба условия заменяют предположениями «Все объявления модуля публичны, если явно не помещены в секцию `private`» и «Внутреннюю функцию можно вызвать из другого модуля по полному имени unit, даже если она в `implementation`». Граница определяется только вторым условием: наружу следует выпускать минимальный набор типов и процедур; первое не учитывается.

Вопрос 18 из 20

В `CounterState` сначала встречается `Result := LastId;`, а затем `LastId := 100;`. Какое наблюдаемое следствие относится именно к сценарию CounterState?

// Отделите правило языка от удачного запуска CounterState.
unit CounterState;
interface
function NextId: Integer;
implementation
var
  LastId: Integer;
function NextId: Integer;
begin
  Inc(LastId);
  Result := LastId;
end;
initialization
  LastId := 100;
end.

Объявления из `implementation` доступны всем модулям, перечисленным в его `uses`. Секция `implementation` влияет только на расположение кода, но не на видимость имён. Глобальное состояние из `implementation` создаётся заново при каждом обращении к модулю. Перенос любого `uses` из `interface` в `implementation` не влияет на экспортируемые типы и совместимость модуля. Имя, объявленное только в `implementation`, не видно клиентам модуля.

Вопрос 19 из 20

Правка по теме «Зависимости uses» должна сохранить полезное поведение и убрать риск на соседнем сценарии. Какое требование она обязана выполнить?

Зависимость в `interface` не влияет на перекомпиляцию клиентов модуля. Любую зависимость можно перенести из `interface uses` в `implementation uses` без изменения публичных типов. Перенос зависимости в `implementation` допустим лишь тогда, когда она не нужна в экспортируемых объявлениях. Порядок `initialization` совпадает с алфавитным порядком имён модулей. Цикл между модулями устраняется перестановкой имён в списке `uses`.

Вопрос 20 из 20

Реализацию темы «Инициализация модулей» заменяют без изменения интерфейса. Какое наблюдаемое свойство обязано сохраниться?

`finalization` идёт в том же порядке, что и `initialization`. Долгие сетевые операции в `initialization` безопасны, потому что интерфейс приложения уже создан. Секции `initialization` выполняются в порядке зависимостей модулей, а `finalization` — в обратном. Секции `initialization` выполняются в алфавитном порядке имён модулей. `finalization` выполняется в том же порядке, что и `initialization`, чтобы зависимости оставались доступными.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу