Java Sprite должен быть объединен со структурой данных - PullRequest
1 голос
/ 06 февраля 2011

Я создаю свой собственный подкласс JPanel в стиле Canvas, который будет рисовать график узлов и дуг. В рамках этого приложения я делегирую отрисовку узлов классу спрайтов Node, т.е.

Class Visualiser extends JPanel {

    ...

    paintComponent(Graphics g) {
        ...
        node.draw(g);
        ...
    }
}

Но у меня также есть класс Node для структуры данных. Меня не волнует номенклатура, я могу вызвать одного NodeSprite, чтобы избежать конфликтов и т. Д ...

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

Есть предложения?

Ответы [ 3 ]

3 голосов
/ 06 февраля 2011

Если NodeSprite ведет себя не так, как знает, как печатать себя, это нарушит принцип единственной ответственности .Если бы все, что он умеет делать, это рисовать, я бы оставил его таким и рассмотрел бы его переименование NodeSpritePrinter или что-то подобное.

1 голос
/ 06 февраля 2011

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

Кроме того, Node звучит как очень общее имя.В любом случае было бы неплохо дать ему более конкретное имя.

0 голосов
/ 06 февраля 2011

Недостатком было бы смешивание кода рисования с логикой домена узла.Это не было бы катастрофой, но это сделало бы код менее понятным для чтения.Шаблон параллельных наборов классов для моделирования объектов предметной области и их представления является старым и уважаемым и действительно используется в самом AWT - для каждого компонента существует соответствующий «нативный узел».Я бы взял подход двух классов;он лучше разделяет обязанности и не имеет реальных недостатков.

...