Closed kstrizhov closed 9 years ago
@aurusov
@bogachev-pa
Хотел уточнить по поводу прокси-класса. Где-то читал про антипаттерны проектирования, что нужно избавляться от классов, содержащих только статические переменные и константы. У меня есть прокси-класс RelativeCoords
, в котором содержатся данные об экране устройства и методы преобразования. Нужно ли это распихать по уже существующим классам, или можно оставить как вспомогательный класс?
Конечно оставить. Попробуй найти антипаттерн на этот случай, обсудим.
http://habrahabr.ru/post/217847/
Вроде эта статья. Там есть в признаках класс, содержащий только методы и константы.
Вообще у меня есть уже класс GraphControl, в котором хранятся методы вызовов графа из интерфейсов трассировки и дерева объектов. Он статический. Есть GraphFrame, который собственно и реализует окно. Мне показалось удобнее закинуть методы преобразования относительных коордиант в пиксели в последний, потому как в них можно тогда будет ссылаться на конструкции типа this.getSize()
. Ведь мы создаем окно в относительных числах к экрану, а граф строим в относительных координатах самого окошка, так?
И еще вопрос, больше абстракный, не к теме, нормально ли, если класс, у которого есть вполне себе экземпляры, ну то есть его объекты не статически, имеет статические и нестатические методы и переменные? А то у меня сложилось мнение, что если мы создаем где-то объекты класса, то он не статический и его переменные объявляются после инициализации экземпляра класса, а статические классы как раз содержат перменные, существующие от начала и до конца работы программы.
Несколько сумбурно, но надеюсь понять можно.
Вроде эта статья. Там есть в признаках класс, содержащий только методы и константы.
Мне кажется, что ты зацепился за один из признаков. Вот что там еще говорится
Их эффективный жизненный цикл непродолжителен.
- у нас он класс есть всегда и всегда используется для отображенияПроблема полтергейстов решается удалением их из иерархии классов
- твой класс в иерархии вообще участвует ?Мне твой класс кажется нужным.
Ведь мы создаем окно в относительных числах к экрану, а граф строим в относительных координатах самого окошка, так?
Верное только второе. Первое может быть в абсолютный пикселях. Это не должно быть принципиально для второго.
нормально ли, если класс, у которого есть вполне себе экземпляры, ну то есть его объекты не статически, имеет статические и нестатические методы и переменные?
Вполне
В общем я подумал, попробовал, удобнее иметь методы преобразований относительных координат в пиксели в моем классе окшка GraphFrame, потому в нем они по большей части используются. Иначе постоянно приходится писать RelativeCoords.setWidth()
и тп, не вижу в этом смысла. Константу размеров монитора перенес в класс, где она используется по прямому назначению.
Остался открытым лишь вопрос по ортнормированию осей. Можно ввести коэффициент по одной из осей, чтобы было что то вроде
frameWidth * 0.1 * k
, где
k = frameHeight / frameWidth
.
Но тогда уж проще просто сразу везде написать во всех методах frameHeight
, потому что другая величина сокращается.
Этот коэффициент называется aspect ratio. И считается наоборот.
Ну хорошо, допустим, не проблема поменять местами и не умножать, а делить.
Вопрос остался открытым, я не понял как лучше, через коэффициент или через задание одной из величин во всех методах? Например
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);
}
Потому как после домножения на коэффициент выражение как раз и принимает такой вид, ведь знаменатель сокращается.
Ну хорошо, допустим, не проблема поменять местами и не умножать, а делить.
Ну спасибо за одолжение.
Вопрос остался открытым, я не понял как лучше
Сделай
Мне кажется, что это должно работать
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);
}
Ну спасибо за одолжение.
Это не одолжение, вы меня неправильно поняли, просто пытаюсь понять, как лучше.
Сделаю.
После этого можно заливать в общую ветвь?
Заливать нет, а вот поставить пул-реквест - да. Читал гитфлоу ? Куда собираешься ставить ?
Собираюсь заливать пока в свою общую ветвь grapher.
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
. Мне кажется нужно приводить все к масштабу какой-либо одной из осей, предположительно меньшей, то есть высоте.
Собираюсь заливать пока в свою общую ветвь grapher.
К себе - сколько угодно.
Сделай
- рабочий
- хорошо читаемый код
Ты в очередной раз объясняешь мне, с доводами и железной логикой, как нарушить второе правило. Молодец, хвалю, безупречно. Но уже хватит. То, что ты предлагаешь, называется преждевременная оптимизация.
Вот кусок отсюда http://insidecpp.ru/antipatterns/premature_optimization/
В 99,9% случаев оптимизация происходит в жертву красоте решения, а именно в жертву универсальности, инкапсуляции, переносимости, возможности быть повторно использованным (использованной), и так далее. Любой из перечисленных аспектов является несравнимо дороже производительности.
Перейти от шкалы пикселей экрана к относительным координатам (0;0) - (1;1).