S>Вот это я называю дизайном здорового человека. Если вдуматься — внушает. Особенно если учесть, что формальных слоёв тут нет (скажем, стек xmlReader и стек xmlWriter друг с другом связаны разве что общим стилем), код отлично работает при использовании функционала с разных слоёв и при этом использование "высокоуровневого" кода остаётся вполне удобным.
S>Возвращаясь к теме — удачный дизайн не по наитию получается. И не как результат попыток сделать всемогутор (скорее наоборот, ни одного удачного не видел). А как результат "находим основные сценарии использования, думаем, как сделать public api с минимумом WTF moments, делаем".
А вот не рановато ли думать о public api до создания самой архитектуры? На мой взгляд, API тогда удачно получаются, когда продиктованы архитектурой, а не наоборот. Т.е. строим дом, потом врезаем окна, а не под сущ. окна строим дом.
На счет fdg я бы поспорил, т.к. интереснее, что читали сами авторы, ибо с первого раза спроетировать api на 15 лет это реально круто. Думается мне с математикой они дружили. Очень интересна с этой точки зрения книга Степанова "Elements of programming". Она вышла позже, но крайне любопытна и полезна ибо при дизайне чего-либо (архитектуры, api) советует смотреть на математику: архитектура должна быть похожа на построение доказательств в математике, только в обратную сторону. Т.е. есть ядро архитектуры (аксиомы), далее создается соотв. функционал (теоремы, леммы). Теорема 1 исп. в теореме 2 и т.д.
