Здравствуйте, Arsen.Shnurkov, Вы писали:
S>>Цитату плиз.
AS>2.1 PROGRESSIVE FRAMEWORKS
AS>Designing a single framework for a broad range of developers, scenarios, and languages is a difficult and costly enterprise.
Так, давай наконец как-то чётче формулировать свои мысли. А то внезапно
Вы путаетесь. Сначала вы (ссылаясь на FDG) говорили, что при дизайне фреймворка
нужно рассматривать максимально широкий спектр задач потенциальных пользователей.
превращается в цитату, которую я не приводил, и которая ещё и понята неверно.
AS>Но указывают, что если фреймворк прогрессивный, то сценариев он покрывает как правило много.
Гхмм... вообще-то там говорится о переходе от отдельных узкоспециализированных фреймворков (mfc/atl, как пример) к фреймворку как к платформе, которая включает в себя разные наборы API для разных задач.
Т.е. широта охвата — это не отдельное API-всемогутор, а возможность использовать в одном приложении разные API от разных вендоров без особых проблем, т.к. они выполнены в общем архитектурном стиле.
The main drawback3 is that the multitude of frameworks makes it difficult for developers using one of the frameworks to transfer their knowledge to the next skill level or scenario (which often requires a different framework). For example, when there is a need to implement a different application that requires more powerful functionality, developers hit a very steep learning curve, because they have to learn a completely different way of programming,
______
3Other drawbacks include slower time to market for frameworks that are wrappers on top ofother frameworks, duplication of effort, and lack of common tools.
AS>Итак, текущее состояние обсуждения:
А, как обычно — с каждой стороны выглядит по своему
За всех участников не скажу, но как минимум я точно никаких набросов аля "ты дурачок" делать не собирался, если так было воспринято — мои извинения. Серьёзно, сорри.
Насчёт остального — да, фреймворки это сложно. Не в том смысле сложно, что "не знаешь — не лезь и даже не пытайся", это дурость полная. Тут любой проектировщик API в одинаковых условиях будет. Смысл в том, что на начальном этапе очень легко допустить ошибки, которые потом так и останутся. Или, в лучшем случае, просто сделать кучу работы на выброс.
Поэтому перед тем как "делать что-то" обязательно надо определиться, что именно должно получиться в итоге и провести предварительную разведку. Если такой подход не нравится, то можно посмотреть на альтернативу — проектирование от паттернов — но это уже к яве.
А вот определиться у нас хронически не получается, не в последнюю очередь из-за того, что тебе пишут одно а ты воспринимаешь совсем другое. Серьёзно. Сформулируй наконец ответ на простой вопрос: какие ключевые сценарии использования у будущего фреймворка. Я не про отдельные фичи, а про проблемы, которые с его помощью можно решать, типовой шаблон "что есть-что надо-ограничения" в прошлом посте писал. После этого уже можно будет определиться с тем, что брать за основу — всё с нуля, форк проекта, или просто набор хелперов поверх библиотеки и уже тогда задумываться об архитектуре.
