Об информационных контекстах

API.html

@@ -80,12 +80,14 @@
     <h4>Иерархия знаний</h4>
     <p>Уровни абстракций можно выделять и снизу вверх: самыми низкоуровневыми сущностями объявляются те, которые работают в терминах нижележащей платформы. Интерфейсы, оперирующие байтами, буферами и флагами — самые примитивные. Чем более специфичный, т.е. требующий знаний об устройстве платформы, код требуется написать — тем ниже уровень абстракции. Напротив, объекты, интерфейс которых не содержит никаких знаний о среде исполнения, образуют верхний уровень. В том же примере с аудио в вебе: сущности, работающие напрямую с «сырыми» данными — аудио буферы — низкоуровневые. Сущности, оперирующие буферами — различные операции над звуком — стоят чуть выше: чтобы работать с ними, уже не нужно знать о разрядности или частоте дискретизации. Ещё чуть выше — функциональность группировки операций и аудио контексты; и так далее. На вершине пирамиды — HTMLAudioElement, интерфейс которого не содержит никаких знаний и легко может быть быть применён не к воспроизведению звука в вебе, а, скажем, к API патефона, если кто-то вдруг задумает его сделать.</p>
     <p>Иными словами, тот объект выше, интерфейс которого не поменяется, если вся нижележащая логика полностью изменится вплоть до смены платформы и физических принципов работы.</p>
-    
+    <h3>Информационный контекст</h3>
+    <p>Как альтернативу традиционному разделению на уровни абстракции можно рассмотреть вашу иерархию сущностей с точки зрения информации, которая через эту иерархию протекает. Любое API, в конечном счёте, предоставляет доступ к некоторой информации.</p>
+    <p></p>
         <h3>Code style</h3>
         — "так здесь принято" vs здравый смысл
-        <h3>Именование</h3>
+    <h3>Именование</h3>
     <p>Если говорить и чисто программной составляющей API, то, пожалуй, именно именование важнее всего. Всё остальное, в конечном счёте, можно подправить или переписать, но вот номенклатура сущностей — это лицо вашего API, это фасад, с которым будет работать ваш пользователь.</p>
-    <p>Удивительно, но заставить разработчиков называть сущности правильно — гораздо более сложная задача, чем кажется.</p>
+    <p>Первое и важнейшее правило именования весьма просто: имя сущности должно понятно и однозначно описывать смысл этой сущности. Имя метода должно показывать, какие действия произойдут при вызове этого метода; имя поля — какой объект хранится в этом поле; имя класса — что из себя будет представлять экземпляр этого класса; и так далее.</p>
         — делать именно то, что нужно
         — сайдэффекты
         - build и update