Я начинаю проект школьной группы на Java, используя Swing. Это простой графический интерфейс для настольного приложения базы данных.
Профессор дал нам код из прошлогоднего проекта, чтобы мы могли видеть, как он работает. Мое первоначальное впечатление состоит в том, что код гораздо сложнее, чем должен быть, но я представляю, что программисты часто думают об этом, глядя на код, который они не просто пишут.
Я надеюсь найти причины, почему его система хороша или плоха. (Я спросил профессора, и он сказал, что я увижу позже, почему так лучше, что меня не устраивает.)
По сути, чтобы избежать какой-либо связи между его постоянными объектами, моделями (бизнес-логикой) и представлениями, все делается с помощью строк. Постоянные объекты, которые хранятся в базе данных, являются хеш-таблицами строк, а модели и представления «подписываются» друг на друга, предоставляя строковые ключи для «событий», на которые они подписываются.
Когда событие инициируется, представление или модель отправляет строку всем своим подписчикам, которые решают, что делать для этого события. Например, в одном из методов слушателя действия views (я полагаю, это просто устанавливает bikeMakeField на постоянный объект):
else if(evt.getSource() == bicycleMakeField)
{
myRegistry.updateSubscribers("BicycleMake", bicycleMakeField.getText());
}Этот вызов в конечном итоге попадает в этот метод в модели Vehicle:
public void stateChangeRequest(String key, Object value) {
... bunch of else ifs ...
else
if (key.equals("BicycleMake") == true)
{
... do stuff ...Профессор говорит, что этот способ работы более расширяемый и поддерживаемый, чем просто представление, просто вызывающее метод объекта бизнес-логики. Он говорит, что между взглядами и моделями нет связи, потому что они не знают о существовании друг друга.
Я думаю, что это худший тип связывания, потому что для работы и представление, и модель должны использовать одни и те же строки. Если вы удалите представление или модель или сделаете опечатку в строке, вы не получите ошибок компиляции. Это также делает код намного длиннее, чем я думаю.
Я хочу обсудить это с ним, но он использует свой отраслевой опыт, чтобы противостоять любым аргументам, которые я, неопытный студент, мог бы выдвинуть. Есть ли какое-то преимущество в его подходе, которого мне не хватает?
Чтобы уточнить, я хочу сравнить вышеупомянутый подход с тем, чтобы представление было явно связано с моделью. Например, вы можете передать объект модели транспортного средства в представление, а затем изменить «марку» транспортного средства, сделав это:
vehicle.make = bicycleMakeField.getText();Это позволит сократить 15 строк кода, которые в настоящее время используются ТОЛЬКО для установки марки автомобиля в одном месте, до одной читаемой строки кода. (И поскольку такого рода операции выполняются сотни раз по всему приложению, я думаю, это было бы большим выигрышем для удобочитаемости и безопасности.)
Обновить
Мы с руководителем группы реструктурировали структуру так, как мы хотели, используя статическую типизацию, сообщили об этом профессору и в итоге дали ему демо. Он достаточно щедр, чтобы позволить нам использовать наш фреймворк до тех пор, пока мы не попросим его о помощи, и если мы сможем поддерживать остальную часть нашей команды в быстром темпе, что кажется нам справедливым.