Можем ли мы использовать EiffelBuild для большого проекта или нам следует ограничить его использование для прототипирования?

Question

EiffelBuild — это графический инструмент для создания графического интерфейса ISE, посвященный Eiffel.

Я попробовал его и считаю, что он очень удобен для пользователя, но меня немного беспокоит использование такого инструмента в большом проекте.Использование инструмента создания графического пользовательского интерфейса может быть ограничительным.

Поскольку наследование Эйфеля упрощает создание компонентов, в долгосрочной перспективе, возможно, лучше использовать наши собственные специализированные версии графических объектов, чем использовать стандартные.

Знаете ли вы о каких-либо ограничениях EiffelBuild, которые оправдывали бы отказ от его использования в крупных проектах?

Answer 1

Я бы ограничил использование EiffelBuild созданием прототипов.Это хороший инструмент, но в долгосрочной перспективе управлять проектами EiffelBuild станет все сложнее (и это верно для большинства дизайнеров):

• Новые версии estudio выпускаются каждые 6 месяцев, что затрудняет поддержание работы ваших проектов EiffelBuild от одной версии к другой, как ожидается, и время от времени придется сталкиваться с миграциями.Теперь весь ваш код Eiffel будет подвергаться одним и тем же проблемам, но в проектах в EiffelBuild вам придется иметь дело как с изменениями в языке, так и с EiffelBuild (а иногда и с обоими одновременно...).
• Если версии N+1 и N несовместимы, вам придется создать ветку ваших проектов EiffelBuild для поддержки обеих версий, хотя бы во время переходного периода.
• Может быть сложно интегрировать несколько проектов EiffelBuild.
• Некоторые графические компоненты может быть сложно повторно использовать в EiffelBuild, например, специализированный компонент диаграммы (т. е. набор классов...), особенно если этот компонент сам по себе не является проектом EiffelBuild.
• Мне было трудно повторно использовать части, созданные из одного приложения EiffelBuild, в другом, тогда как с достаточно хорошо спроектированными компонентами это гораздо менее проблематично.

Надеюсь это поможет.

Answer 2

  

Я пробую это и нахожу это очень удобным для пользователя, но я немного обеспокоен использованием такого инструмента для большого проекта. Использование инструмента для создания GUI может быть ограничительным.

Как это "ограничительно"? И как размер проекта вступает в игру?

Если вы имеете в виду, что это генератор кода, и вы не понимаете код, который выходит из него полностью, то я полностью согласен. Генерация кода работает только в тех случаях, когда вы пишете код вручную, а генератор помогает вам сэкономить, экономя трудную работу. В этом случае вы чувствуете себя полностью уверенно в изменении и поддержке сгенерированного кода.

  

Поскольку наследование Eiffel позволяет очень легко создавать компоненты, в долгосрочной перспективе может быть лучше использовать наши собственные специализированные версии графических объектов, чем стандартные.

Какую специализацию вы добавляете? Я бы тщательно обдумал это, потому что это означает написание, отладку и поддержку большой иерархии классов в perpetuam. Прежде чем сделать этот шаг, будьте абсолютно уверены, что специализация необходима, стоит затрат и недоступна для любых других средств. Приложите честные усилия, чтобы определить стоимость, прежде чем принять решение.

Я бы проголосовал за написание собственного генератора кода, как только вы достаточно наложили код, используя классы GUI библиотеки. Это устойчивое решение, ИМО.

ОБНОВЛЕНИЕ:

Я выучил Eiffel в аспирантуре, которая в середине 90-х годов решила, что это лучший объектно-ориентированный язык. В то время C ++ был выдающимся, но считался сложным, Java не выбралась из лабораторий Sun, а C # даже не стал проблеском в глазах Андерса. Преподаватели в этом заведении были очарованы дизайном по контракту, и это означало верность академической строгости.

Я прочитал «Мейерса» «Создание объектно-ориентированного программного обеспечения». Первое издание представило DbC и сделало Майерса чем-то вроде звезды в объектно-ориентированном мире. На мой взгляд, второе издание было раздутым, что положило конец его восхождению.

Честно говоря, если вы пишете эту большую систему для работодателя, я бы посоветовал вам отказаться от Eiffel и перейти на более распространенный язык для вас и ради вас. C # может быть хорошим выбором, если вы работаете на платформе Windows; используйте Java, если у вас гетерогенная среда или вы не можете позволить себе стек Microsoft.

У SO есть все четыре вопроса с тегами об Eiffel. Я думаю, что объем говорит что-то. Вы можете быть правы, что популярность не всегда лучший показатель качества. Мне говорят, что бета-версия была лучшим техническим решением, чем VHS, но дело в том, что она проиграла на рынке и сегодня нигде не встречается. То же самое с Эйфелевой. Я бы бросил его на твоем месте.

ОБНОВЛЕНИЕ 2:

Очень хорошо - я не мог сказать из вашего оригинального поста, каков был ваш опыт работы с другими языками.

" Высокое ожидание качества " подразумевает, что вы уверены, что Eiffel будет поддерживать качество на уровне языка таким образом, чтобы его нельзя было дублировать с другими языками. Я бы не согласился с этим. Качество кода больше связано с навыками и практикой разработчиков, чем с самим языком.

Дизайн по контракту полностью перепродан, ИМО. Я читал, что он часто отключается в производстве, потому что он представляет собой снижение производительности. Если это правда для вас, как еще вы ожидаете, что Eiffel будет способствовать повышению качества?

Я бы позаботился о том, чтобы клиент, для которого вы пишете это приложение, понимал все последствия, к которым может привести решение пойти с Eiffel: ограниченный пул разработчиков для его поддержки, персонал, маргинализованный из-за использования мертвого языка и т. д. Убедитесь, что вы не перепродаете его из-за субъективного желания.