Переход на относительную систему координат

[kstrizhov]

Перейти от шкалы пикселей экрана к относительным координатам (0;0) - (1;1).

[kstrizhov]

@aurusov @bogachev-pa Хотел уточнить по поводу прокси-класса. Где-то читал про антипаттерны проектирования, что нужно избавляться от классов, содержащих только статические переменные и константы. У меня есть прокси-класс RelativeCoords, в котором содержатся данные об экране устройства и методы преобразования. Нужно ли это распихать по уже существующим классам, или можно оставить как вспомогательный класс?

[aurusov]

Конечно оставить. Попробуй найти антипаттерн на этот случай, обсудим.

[kstrizhov]

http://habrahabr.ru/post/217847/

Вроде эта статья. Там есть в признаках класс, содержащий только методы и константы.

Вообще у меня есть уже класс GraphControl, в котором хранятся методы вызовов графа из интерфейсов трассировки и дерева объектов. Он статический. Есть GraphFrame, который собственно и реализует окно. Мне показалось удобнее закинуть методы преобразования относительных коордиант в пиксели в последний, потому как в них можно тогда будет ссылаться на конструкции типа this.getSize(). Ведь мы создаем окно в относительных числах к экрану, а граф строим в относительных координатах самого окошка, так?

И еще вопрос, больше абстракный, не к теме, нормально ли, если класс, у которого есть вполне себе экземпляры, ну то есть его объекты не статически, имеет статические и нестатические методы и переменные? А то у меня сложилось мнение, что если мы создаем где-то объекты класса, то он не статический и его переменные объявляются после инициализации экземпляра класса, а статические классы как раз содержат перменные, существующие от начала и до конца работы программы.

Несколько сумбурно, но надеюсь понять можно.

[aurusov]

Вроде эта статья. Там есть в признаках класс, содержащий только методы и константы.

Мне кажется, что ты зацепился за один из признаков. Вот что там еще говорится

• Их эффективный жизненный цикл непродолжителен. - у нас он класс есть всегда и всегда используется для отображения
• Проблема полтергейстов решается удалением их из иерархии классов - твой класс в иерархии вообще участвует ?

Мне твой класс кажется нужным.

Ведь мы создаем окно в относительных числах к экрану, а граф строим в относительных координатах самого окошка, так?

Верное только второе. Первое может быть в абсолютный пикселях. Это не должно быть принципиально для второго.

нормально ли, если класс, у которого есть вполне себе экземпляры, ну то есть его объекты не статически, имеет статические и нестатические методы и переменные?

Вполне

[kstrizhov]

В общем я подумал, попробовал, удобнее иметь методы преобразований относительных координат в пиксели в моем классе окшка GraphFrame, потому в нем они по большей части используются. Иначе постоянно приходится писать RelativeCoords.setWidth() и тп, не вижу в этом смысла. Константу размеров монитора перенес в класс, где она используется по прямому назначению.

Остался открытым лишь вопрос по ортнормированию осей. Можно ввести коэффициент по одной из осей, чтобы было что то вроде

frameWidth * 0.1 * k, где

k = frameHeight / frameWidth.

Но тогда уж проще просто сразу везде написать во всех методах frameHeight, потому что другая величина сокращается.

[aurusov]

Этот коэффициент называется aspect ratio. И считается наоборот.

[kstrizhov]

Ну хорошо, допустим, не проблема поменять местами и не умножать, а делить.

Вопрос остался открытым, я не понял как лучше, через коэффициент или через задание одной из величин во всех методах? Например

public static int setWidth(Dimension d, double relativeWidth) {
    return (int) (d.width * relativeWidth);
}

public static int setHeight(Dimension d, double relativeHeight) {
    return (int) (d.width * relativeHeight);
}

Потому как после домножения на коэффициент выражение как раз и принимает такой вид, ведь знаменатель сокращается.

[aurusov]

Ну хорошо, допустим, не проблема поменять местами и не умножать, а делить.

Ну спасибо за одолжение.

Вопрос остался открытым, я не понял как лучше

Сделай

• рабочий
• хорошо читаемый код

Мне кажется, что это должно работать

public static int getWidth(double relativeWidth, Dimension dimension) {
    return (int) (relativeWidth * dimension.width / dimension.aspectRatio);
}

public static int getHeight(double relativeHeight, Dimension dimension) {
    return (int) (relativeHeight * dimension.height * dimension.aspectRatio);
}

[kstrizhov]

Ну спасибо за одолжение.

Это не одолжение, вы меня неправильно поняли, просто пытаюсь понять, как лучше.

Сделаю.

После этого можно заливать в общую ветвь?

[aurusov]

Заливать нет, а вот поставить пул-реквест - да. Читал гитфлоу ? Куда собираешься ставить ?

[kstrizhov]

Собираюсь заливать пока в свою общую ветвь grapher.

[kstrizhov]

public static int getWidth(double relativeWidth, Dimension dimension) {
    return (int) (relativeWidth * dimension.width / dimension.aspectRatio);
}
public static int getHeight(double relativeHeight, Dimension dimension) {
    return (int) (relativeHeight * dimension.height * dimension.aspectRatio);
}

Так в итоге там все в одном и в другом методе сократится все, если

aspectRatio = frameDimension.width / frameDimension.height,

то в методе getWidth() сократится width и останется height, а в методе getHeight() сократится height и останется width. Мне кажется нужно приводить все к масштабу какой-либо одной из осей, предположительно меньшей, то есть высоте.

[aurusov]

Собираюсь заливать пока в свою общую ветвь grapher.

К себе - сколько угодно.

[aurusov]

Сделай

• рабочий
• хорошо читаемый код

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

Вот кусок отсюда http://insidecpp.ru/antipatterns/premature_optimization/

В 99,9% случаев оптимизация происходит в жертву красоте решения, а именно в жертву универсальности, инкапсуляции, переносимости, возможности быть повторно использованным (использованной), и так далее. Любой из перечисленных аспектов является несравнимо дороже производительности.