Здравствуйте, Sharov, Вы писали:

S>А вот не рановато ли думать о public api до создания самой архитектуры? На мой взгляд, API тогда удачно получаются, когда продиктованы архитектурой, а не наоборот.

Как показывает практика — не рано, если говорить об инфраструктуре, для которой сценарии использования очевидны.

Тут важно само наличие формализованного public api, а не его качество, т.к. мы на самом раннем этапе получаем:
1. Набор ключевых сценариев для фреймворка.
2. Код с примерами использования этих сценариев, он же — готовые интеграционные тесты
3. Возможность проверить архитектуру на адекватность требованиям.

Т.е. на этом этапе public API играет роль спецификации/требований, с учётом которых строится архитектура и пишется реальный код.
В результате мы имеем адекватное представление о проекте в целом буквально с нулевого дня. В твоей аналогии

Т.е. строим дом, потом врезаем окна, а не под сущ. окна строим дом.

делаем модельку, которая прописывает уровень освещённости, вентиляцию и что там ещё по санпину и в процессе собственно проектирования дома постоянно проверяем, что мы в эти требования укладываемся. В общем, речь про подсобный инструмент, а не про замену собственно проектированию.


Как раз на этой идее про постоянную проверку практикой aka

Framework Design Principle
Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.

вся FDG и построена

S>На счет fdg я бы поспорил, т.к. интереснее, что читали сами авторы, ибо с первого раза спроетировать api на 15 лет это реально круто. Думается мне с математикой они дружили. Очень интересна с этой точки зрения книга Степанова "Elements of programming".
Ну это безусловно да. Проблема в том, что даже FDG осиливают единицы. Поэтому сначала ползать, затем летать

Здравствуйте, Sharov, Вы писали:

S>А вот не рановато ли думать о public api до создания самой архитектуры? На мой взгляд, API тогда удачно получаются, когда продиктованы архитектурой, а не наоборот.

Как показывает практика — не рано, если говорить об инфраструктуре, для которой сценарии использования очевидны.

Тут важно само наличие формализованного public api, а не его качество, т.к. мы на самом раннем этапе получаем:
1. Набор ключевых сценариев для фреймворка.
2. Код с примерами использования этих сценариев, он же — готовые интеграционные тесты
3. Возможность проверить архитектуру на адекватность требованиям.

Т.е. на этом этапе public API играет роль спецификации/требований, с учётом которых строится архитектура и пишется реальный код.
В результате мы имеем адекватное представление о проекте в целом буквально с нулевого дня. В твоей аналогии

Т.е. строим дом, потом врезаем окна, а не под сущ. окна строим дом.

делаем модельку, которая прописывает уровень освещённости, вентиляцию и что там ещё по санпину и в процессе собственно проектирования дома постоянно проверяем, что мы в эти требования укладываемся. В общем, речь про подсобный инструмент, а не про замену собственно проектированию.

upd хо, я даже сделал про это оговорку в предыдущем посте. Всё ок короче.

Аналогичный подход работает не только с конкретными типами, но и с инфраструктурой в целом. Только количество сценариев использования заметно больше выходит. Поэтому как правило сначала вчерновую собирают примеры того функционала, который нужно реализовать, а затем уже раскидывают ответственности по слоям, используя простой принцип "ничего не знает о". Ну, т.е. Stream отлично компилируется и работает без StreamReader, StreamReader знает о существовании Stream, но не догадывается о XmlReader и тыды и тыпы.

Как раз на этой идее про постоянную проверку практикой aka

Framework Design Principle
Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.

вся FDG и построена

S>На счет fdg я бы поспорил, т.к. интереснее, что читали сами авторы, ибо с первого раза спроетировать api на 15 лет это реально круто. Думается мне с математикой они дружили. Очень интересна с этой точки зрения книга Степанова "Elements of programming".
Ну это безусловно да. Проблема в том, что даже FDG осиливают единицы. Поэтому сначала ползать, затем летать