Java Swing Design: статический против экземпляра

Question

Я разработал html-редактор документов и мне нужна помощь в решении проблемы дизайна в нем. Проблема в следующем -

Редактор документов состоит из поверхности (JFrame) и строки меню. Внутри поверхности у меня есть три панели - панель инструментов, текстовая панель и панель состояния (все они являются расширениями JPanel). Текстовая панель имеет настраиваемую текстовую панель (расширение JTextPane). Теперь проблема в том, что существует множество сценариев, когда меню и элементы виджетов на панели инструментов нуждаются в доступе к базовой модели документа JTextPane. Например. Чтобы реализовать функцию перетаскивания списка / абзаца, линейка должна знать положение каретки внутри модели документа, чтобы можно было пометить абзац, левую вставку которого мне нужно увеличить.

Способ, которым я организовал свой дизайн прямо сейчас, заключается в том, что поверхность - это одноэлементный объект, поэтому для доступа к модели документа html внутри JTextPane вам необходимо кодировать свой путь через следующий лабиринт -

Дай мне поверхность -> перейти к панели текста -> перейти к панели текста -> перейти к документу панели текста

Еще одна альтернатива - сделать ссылку на документ внутри текстовой панели статической, чтобы к ней можно было получить прямой доступ.

TextPane.getTextDocument ()

Кроме того, HTML-документ внутри текстовой панели, которую я использую, сейчас не настроен. Поэтому я просто использую HTMLDocument по умолчанию, возвращаемый текстовой панелью. Хотя в будущем мне, возможно, придется заменить его более индивидуальным расширением HTMLDocument (например, для реализации тегов Cusom)

Я начинающий дизайнер. Может ли какой-нибудь дизайнерский гуру пролить свет на это?

Answer 1

Я думаю, что если вы получите 10 ответов, вы получите 11 ответов.: -)

Во-первых, нет необходимости в синглтоне.В этом сценарии это просто способ обмана с помощью глобальной переменной.А что происходит, когда вы хотите открыть два или три текстовых документа?

Имеют ли ваши меню свободный доступ к панели инструментов?Поскольку панель инструментов является родственным элементом текстовой панели, и в отношении 1-1 (я думаю?) Для панели инструментов несколько «разумно» знать о текстовом документе (иметь ссылку на него) и вспомогательном методе getTextDocument ().И кажется разумным, чтобы ваши виджеты знали об их непосредственном родителе, панели инструментов.

Это был бы мой способ решения проблемы - какие связи между объектами «имеют смысл».Вы хотите как можно меньше сцепления, но есть места, где вам нужно сцепление.Возможно, я неправильно понял вашу проблему, или, может быть, вы думаете по-другому, чем я, и в этом случае вы должны сделать это по-другому.Кроме того, вы делаете предположение о том, как ваш код может развиваться в будущем.Удачи с этим!: -)

Один большой вопрос для любого решения - меняется ли текстовый документ?(например, есть ли меню Файл-> Новое или меню Файл-> Открыть?).Если это так, это необходимо учитывать.В моем предложении JFrame в File-> Open создал бы текстовый документ и затем изменил бы ссылку на него в панели инструментов.

ps пуристы MVC - пожалуйста, добавьте соответствующие модели и контроллеры!Я только что говорил о графических компонентах, чтобы упростить задачу ...

pps Примеры «обдумывания» для разумных улучшений

1. Будет ли это обрабатывать несколько JFrames, открытых одновременно?Да.
2. Будет ли это обрабатывать один JFrame, но с несколькими документами (скажем, интерфейс с вкладками для текстового документа)?Почти.Метод должен быть немного умнее, чтобы знать, какой из многих документов активен, но вы легко можете себе представить, как это сделать.
3. Как насчет того, когда мне нужно хранить гораздо больше информации о диктовке, например, имя(таким образом, Save дает хорошее значение по умолчанию), при последнем сохранении, является ли он "грязным", HTML или XHTML или что-то еще ... На данный момент, вы, вероятно, захотите добавить еще один слой модели.Но вы можете себе представить, что с еще одним уровнем косвенности (еще одной ссылкой) это нормально, так что это зависит от того, насколько вы близки к реализации # 3, как вы хотите проектировать.