Запреты и послабления
В последнем примере два множества компонентов, будучи теоретически избыточными, практически являются различными. Конечно же, не следует вводить новый компонент, если есть старый, выполняющий аналогичную работу, о чем говорит предложение S3 в рекомендациях Списка Требований. Это предложение более требовательное, чем может показаться с первого взгляда. В частности:
- Предположим, вы хотите изменить порядок аргументов в подпрограмме для совместимости с другими подпрограммами. Но вас сдерживает совместимость с уже существующим ПО. Решение не может состоять в том, чтобы иметь оба компонента с тем же статусом, - это противоречило бы рекомендации S3. Вместо этого следует использовать библиотечный механизм эволюции obsolete, который чуть позже будет описан в этой лекции.
- Аналогично следует поступать для обеспечения значений аргументов, требуемых некоторой программе. Не следует предоставлять две версии, одну со специальными аргументами, а другую - общую, основанную на умолчаниях, как обсуждалось ране в этой лекции. Сделайте один интерфейс официальным, а другой обеспечьте через механизм obsolete.
- Если вы колеблетесь в выборе имени компонента, следует почти всегда сопротивляться попытке сделать имена синонимами. В библиотеке ISE единственное исключение сделано для фундаментальных компонентов, имеющих инфиксное имя и идентификатор, например доступ к массиву может осуществляться двояко: my_array.item (some_index) или my_array @ some_index. Каждая форма предпочтительнее в определенном контексте. Но это редкая ситуация. Как правило, проектировщик должен выбрать имя, не перекладывая ответственность на клиентов.
Как вы заметили, наша политика в результате представляет смесь из запретов и послаблений. Она смягчена, поскольку допускает компоненты, не являющиеся основными. Но она достаточно строга, поскольку определяет жесткие условия для компонента. Компоненты класса могут покрывать столько потребностей, сколько это необходимо, но они должны покрывать только релевантные потребности, и каждой из них должен соответствовать ровно один компонент.
|
Политика Списка Требований возможна только потому, что мы следуем систематической политике сохранения минимальности языка. Минималистская позиция в проектировании языка - небольшое число чрезвычайно мощных конструкций и никакой избыточности - позволяет разрешить разработчикам класса не быть минималистами. Каждый разработчик должен знать язык, поскольку язык минимален, то разработчик знает о нем все. Классы используются только клиентами и они могут пропустить то, что они не используют. |
Следует связать Рекомендации Списка Требований с предшествующей дискуссией о размере компонентов. Трудности использования класса определяются не числом его компонентов, а их индивидуальной сложностью. Более точно, размер класса является некоторой проблемой лишь на первых порах. После завершения этапа освоения разработчик будет постоянно иметь дело с компонентами, скорее всего, подмножеством компонентов, Размер компонента становится приоритетным, а размер класса перестает быть таковым. Не следует пользоваться численными критериями типа: "никакой класс не должен иметь более n строк или m компонентов", - разделение класса на такой основе может лишь сделать его более трудным в использовании.
Урок для разработчиков класса, вытекающий из Рекомендаций Списка Требований: следует заботиться о качестве класса, в частности о его концептуальной целостности и размере его компонентов, но не о размере самого класса.
