#java #c #swing #user-interface #interaction-design
#java #c #swing #пользовательский интерфейс #взаимодействие-дизайн
Вопрос:
Да, я был немного удивлен, когда интервьюер упомянул, что они используют графический интерфейс Java-swing для приложения на C / C . Мне было любопытно, и я спросил его, как они на самом деле объединяют их вместе, его ответ был «через обмен сообщениями». Интересно! Что ж, я новичок в таком подходе, и мне любопытно, действительно ли компании используют такой дизайн. Если да, то есть ли большое преимущество в этом дизайне? Мне немного сложно понять, как этот дизайн будет хорошо работать, если у вас есть какие-либо ссылки, пожалуйста, поделитесь.
К вашему сведению, продукт представляет собой приложение на основе резервного копирования данных (возможно, на платформе Linux / Unix). Спасибо.
РЕЗЮМЕ
Комментарии:
1. Я бы предположил, что единственная причина, по которой они разработали его таким образом, заключалась в том, что у них был «парень с C / C » и «парень с Java» для совместной работы над ним, и ни один из них не хотел развиваться за пределами своей зоны комфорта. Для меня это звучит как плохой дизайн.
2. Не уверен, что это вопрос StackOverflow или programmers.stackexchange . Я думаю, что это может быть связано с опытом их программистов — им может быть удобнее работать с графическим интерфейсом Java, но они в порядке с «кишками» C / C . В любом случае, я голосую за то, чтобы этот вопрос был перенесен на programmers.stackexchange как более подходящий сайт для такого типа вопросов.
3. Или кто-то с острыми волосами услышал, что Java отлично подходит для пользовательского интерфейса / переносимости (вероятно, в конце 90-х!) и Заставил использовать Java. Или, возможно, серверные системы зависели от большого количества собственного кода, поэтому было проще просто написать все это как отдельное приложение на C .
4. @Hovercraft. Как мне перенести этот вопрос в programmers.stackexchange
5. Хотя это, безусловно.. необычный, хороший стиль программирования заключается в том, чтобы отделить графический интерфейс и серверную часть в любом случае, и я полагаю, что такой подход гарантирует это почти наверняка 😉 Накладные расходы на использование обмена сообщениями (JNI, TCP, ..) должны быть довольно незначительными для кода пользовательского интерфейса, и во многих крупных проектах серверные ребята все равно не касаются кода GUI. Так в чем проблема?
Ответ №1:
Я не вижу в этом ничего плохого. Очень часто различные компоненты интегрируются с помощью обмена сообщениями. Я думаю, что в целом лучше иметь однородную среду (например, все приложения, написанные на Java, а не на Java и C ), однако часто бывает так, что вам необходимо интегрироваться с устаревшими или сторонними компонентами, написанными на других языках, либо по соображениям стоимости, либо потому, что другого выбора нет.
Обмен сообщениями — распространенный способ сделать это. Я рассматриваю HTTP под эгидой «обмена сообщениями», и почти на каждом языке есть библиотека HTTP, что делает его хорошим выбором в качестве общего «языка» обмена сообщениями. При интеграции очень разнородной системы существуют специальные инструменты / фреймворки не только для интеграции компонентов, но и для интеграции систем обмена сообщениями (например, ESB).
Комментарии:
1. Я согласен. Зачем переписывать рабочую систему, если вы можете просто добавить графический интерфейс, который взаимодействует с ней. Это происходит довольно часто в индустрии финансовых услуг, где устаревшая серверная система получает новый графический интерфейс, очень часто на Java, который обменивается сообщениями с серверной частью. На самом деле, очень большой процент решений для интернет-банкинга и даже банкоматов работают именно таким образом.
Ответ №2:
Трудно сказать, хороший ли это дизайн, без дополнительной информации о требованиях приложения.
Еще одна вещь, которую следует учитывать, это то, что иногда интервьюеры предлагают странные проекты, чтобы посмотреть, как реагируют кандидаты. Обычно я делаю это, когда нанимаюсь на должность, которая не является моей личной компетенцией, но в которой у меня был опыт (обычно я все исправляю). Моя цель — посмотреть, лучше ли кандидат решает проблему, чем я! Плохие кандидаты будут рабски принимать мое плохое решение. Лучшие кандидаты сразу же предложат лучшее решение. Лучшие кандидаты будут сравнивать и сравнивать мое слабое решение со своим лучшим решением и исследовать, когда каждый вариант имеет смысл.
Я бы предположил, что интерфейс Java был выбран из соображений переносимости. Я бы высказался за браузерный интерфейс для достижения тех же целей, но, возможно, их пользователи UI / UX действительно любили Java.
Комментарии:
1. «Плохие кандидаты будут рабски принимать мое плохое решение». — Разве это не хорошо? Босс выдает дизайн, и рабочие должны следовать ему без возражений, по крайней мере, на этом сосредоточено наше текущее образование. И говорить против власти считается табу в большинстве рабочих мест? Извините, я новичок, я просто спрашиваю.
2. Я могу говорить только о своем опыте работы в качестве IC и менеджера высокопроизводительных команд. Если цель состоит в создании отличного программного обеспечения, то задача каждого — постоянно повышать планку качества. Нереально ожидать, что руководство поймет каждую деталь. Хорошее руководство понимает это и ожидает рекомендаций от ICs. Единственная сложная часть — делать это дипломатично. (Обычно неразумно называть своего босса идиотом, даже если он один)
Ответ №3:
Могут быть ограничения относительно того, почему они должны вызывать функции C в первую очередь, а затем, кроме того, у них могли быть распределенные требования клиента. Как бы вы разработали решение, чтобы создать систему обмена сообщениями, которая взаимодействует с C на стороне сервера. В конце концов, это рабочее решение. Я бы не ожидал, что пользовательский интерфейс должен быть построен на C , потому что серверная часть написана на C , иногда вам нужно собрать разные технологии вместе, чтобы достичь вашего решения.
Ответ №4:
Это работоспособный / приемлемый подход, я видел, как он использовался в очень крупной (Fortune 20, если есть такая вещь) компании, когда я работал там в качестве подрядчика 2005-2006.
Когда я спросил, почему, мне сказали:
- Нужен графический интерфейс Linux, java / SWING — достойный выбор. Я также думаю, что у них были некоторые разработчики Java, которым нужна была работа.
- У них была большая, критически важная для производительности кодовая база на C / C.
- Они уже широко использовали обмен сообщениями и имели библиотеки для этого.
- Интерфейс обмена сообщениями, хотя и более дорогой в разработке, позволяет команде писать тестовые программы (например, заменить рабочий графический интерфейс скриптом python).
Все это говорит о том, что Qt и GTK / Gtkmm — очень хорошие графические фреймворки, почему бы их не использовать?