Мне кажется, рассуждения автора (о молотке сотоварищи) совсем не о framework'ах, а о том, что принято называть выражениями overengineering и design overkill (не могу подобрать подходящих русских аналогов).
Далее в обсуждении:
The distinction between a library and a framework is subtle, but I think critical. A library is a collection of code that I don't have to write myself. It provides me with a set of objects and methods that I can use to build me application. If the library doesn't do quite what I want, I can make some small modifications or throw it away and use a different library.
A framework, on the other hand, always attempts to redefine the entire applilcation architecture. And, if the framework ends up not meeting my needs, I need to throw away my entire application, because everything I've written is defined in terms of the framework's methodology.
A library is something *contained* within my code.
A framework is a *container* for my application.
Из этих высказываний совсем неочевидно, что framework — Плохая Вещь.
Что плохого в "навязывании архитектуры", если эта архитектура хорошо проецируется на предметную область?
Может, автора огорчает немного другое?
Why is it so difficult to find simple libraries that provide these kinds of services?
См. выделенное. Думаю, беда в том что frameworks редко бывают простыми и легкими (по крайней мере, я не встречал ).
Получается, "framework" становится синонимом "overkilled" и "overengineered"
Но почему? На первый взгляд кажется, что причина в следующем: для того, чтобы быть "контейнером" для приложения, framework должен обладать обладать
достаточным знанием о прикладной области
достаточной гибкостью
Но, очевидно, точно такие же проблемы имеют обычные библиотеки (libraries), которые простыми и легкими бывают.
Вообщем, есть о чем задуматься
Re[2]: The Joel on Software Discussion Group - Why I Hate Fr
[offtopic]
P.S. Павел, у вас на сайте (например, здесь) написано, что команда использует помимо прочего number of frameworks.
Если не коммерческая тайна — можешь привести пример используемых framework'ов на C++?
[/offtopic]
Re[3]: The Joel on Software Discussion Group - Why I Hate Fr
Здравствуйте, Alxndr, Вы писали:
A>Отличная статься, но.
A>Но почему? На первый взгляд кажется, что причина в следующем: для того, чтобы быть "контейнером" для приложения, framework должен обладать обладать A>
A>достаточным знанием о прикладной области A>достаточной гибкостью A>
+1
Получается, что фреймворк навязываает правила приложению.
И приложению, для чтобы иметь возможность работать в контейнере фреймворка, нужно следовать этим правилам.
Иначе оно "не в танке".
-- Андрей
Re[2]: The Joel on Software Discussion Group - Why I Hate Fr
> framework, on the other hand, always attempts to redefine the entire applilcation architecture. And, if the framework ends up not meeting my needs, I need to throw away my entire application, because everything I've written is defined in terms of the framework's methodology.
> Из этих высказываний совсем неочевидно, что framework — Плохая Вещь. > Что плохого в "навязывании архитектуры", если эта архитектура хорошо проецируется на предметную область?
По крайней мере, позиция автора, вроде, ясна, если смотреть на выделенное выше.
> Думаю, беда в том что frameworks редко бывают простыми и легкими (по крайней мере, я не встречал ). > Получается, "framework" становится синонимом "overkilled" и "overengineered" > Но почему?
Имхо, предоставляя решение в виде framework, автор вынужденно должен делать его существенно более полным и общим, чем библиотеку, т.к. frameworks пользователям очень сложно расширять непредусмотренными автором методами и в непредусмотренных автором местах, и, как написанно выше, в случае невозможности изменить поведение framework нужным образом, от него придется отказаться, плюс "перелопатить" все свое приложение. Соответственно, даже в случае простого использования пользователю придется иметь дело с "фабрикой фабрики фабрик", т.к. она уже там, во framework, для общности.
Библиотеки же просто предоставляют некоторые услуги пользователю, без претензии на организацию всей архитектуры использующего приложения. Соответственно, изначально могут позволить себе быть значительно более простыми, т.к. при необходимости что-то изменить у пользователя будет заметно больше свободы, в т.ч. и в отказе от данной библиотеки без изменения структуры своего приложения.
Другой проблемой frameworks является большая сложность/невозможность совместного использования нескольких из них. В случае библиотек (почти?) всегда можно как-нибудь выкрутиться, в крайнем случае изолировав их в разных модулях, и снабдив своими переходниками.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: The Joel on Software Discussion Group - Why I Hate Fr
Alxndr,
> P.S. Павел, у вас на сайте (например, здесь) написано, что команда использует помимо прочего number of frameworks. Если не коммерческая тайна — можешь привести пример используемых framework'ов на C++?
Number of proprietary frameworks. Очевидно, их в качестве примера привести будет сложно, придется описывать. Из сторонних же, пожалуй, можно упомянуть MFC, которую, правда, мы используем в режиме библиотеки, а не framework, для реализации некоторых окошек в старом коде, и существенно переработанную версию MacApp, которая тоже осталась от "старых времен", которую мы не слишком любим, но от которой теперь очень нелегко отказаться, как это обычно и происходит с frameworks...
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[2]: The Joel on Software Discussion Group - Why I Hate Fr
.
Для решаемых им задач на самом деле не сложный и легкий (его собственный код всего ~40000 физических строк, остальное -- это сопутсвующие библиотеки). Хотя сейчас и очевидно, что можно было бы еще проще.
Еще Ruby On Rails не самый тяжелый и сложный, как мне показалось. Да еще и состоит из относительно независимых библиотек (ActiveRecord, ActionPack, ActionMailer и др.), которые можно использовать отдельно (ActiveRecord использовал сам).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: The Joel on Software Discussion Group - Why I Hate Frame
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ох... Как же ты бываешь быстр в суждениях Это и не Джоэл вовсе. Просто сообщение в его форуме (см. выделенное выше).
Хм. Да там еще и люди водятся?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: The Joel on Software Discussion Group - Why I Hate Fr
Здравствуйте, Alxndr, Вы писали:
A>Думаю, беда в том что frameworks редко бывают простыми и легкими (по крайней мере, я не встречал ).
ИМХО, frameworks стоит делить не на простые и сложные, а на хорошо и плохо спроектированные Вот ACE — сложный, но хорошо спроектированный framework. Несмотря на всю свою монструозность, он позволяет пользоваться его составляющими как отдельными библиотеками. Более того, его разработчики в скором будущем собираются физически разбить ace.lib на несколько библиотек меньшего размера.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Re[3]: The Joel on Software Discussion Group - Why I Hate Fr
Здравствуйте, kwas, Вы писали:
K>Более того, его разработчики в скором будущем собираются физически разбить ace.lib на несколько библиотек меньшего размера.
Во-во. Ключевое слово выделено
Re[4]: The Joel on Software Discussion Group - Why I Hate Fr
Здравствуйте, Alxndr, Вы писали:
K>>Более того, его разработчики в скором будущем собираются физически разбить ace.lib на несколько библиотек меньшего размера.
A>Во-во. Ключевое слово выделено
Это неправильное ключевое слово Правильное — "физически"
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
).
