Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>К сожалению, как правило, "огребают" сопровождающий программист и компания, разрабатывающая программу, т.к. в связи с тем, что модель не расширяема, компании приходится либо отказываться от расширения функциональности, либо вкладывать кучу денег в то, чтобы полностью переделать решение.
Видишь ли, в современных условиях (читай, наличие автоматизированных средств рефакторинга, хороших компиляторов, unit-тестирования), сложность рефакторинга определяется совсем не количеством изменяемого кода, а его читаемостью и простотой изменений. Например, изменение интерфейса с точки зрения поддержки не страшно, потому что компилятор заставит реализовать это изменение везде. Не страшно переименование или удаление ненужных методов, потому что это можно осуществить нажатием одной кнопки.
Зато по прежнему страшен рефакторинг сложного и запутанного кода. Страшен рефакторинг классов с кучей взаимопересекающейся логики. Страшен рефакторинг контрактов, выраженных не ввиде формальных структур ЯП, а ввиде императивного кода. Страшен рефакторинг кусков, проблемы в которых можно найти только в процессе эксплуатации кода.
С этой точки зрения прямой зависимости между количеством классов и интерфейсов и сложностью (читай стоимостью) рефакторинга нет. Однако кое какая корреляция имеется, и она отнюдь не в пользу кода, в котором в один класс или интерфейс упихано максимальное количество аспектов.
P.S. Кстати, а как с точки зрения твоей теории выглядит АОП? Как совсем неверный подход?
... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>
Андрюш, дело в том что твой собеседник вобще не понимает что такое КОП. Соотв. и решение, направленное на поддержку этого самого КОП он воспринять просто не в состоянии. И получается разговор слепого с глухим.
... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Андрюш, дело в том что твой собеседник вобще не понимает что такое КОП. Соотв. и решение, направленное на поддержку этого самого КОП он воспринять просто не в состоянии. И получается разговор слепого с глухим.
То что предлагает он я прекрасно понимаю. И понимаю чем это черевато.
Но вобще лично мне просто пофлеймить охота и возможно кто-то другой что-то полезное для себя узнает.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Но вобще лично мне просто пофлеймить охота и возможно кто-то другой что-то полезное для себя узнает.
Да, да, интересный флейм получается. Я как раз сейчас подобными вещами занят. Хотелось бы ещё услышать флейм по поводу того, как в одном флаконе соединяются редакторы win- и web-форм, а то это задача одна из актуальнейших, но подойти к ней как-то тяжело.
Здравствуйте, konsoletyper, Вы писали:
K>Да, да, интересный флейм получается. Я как раз сейчас подобными вещами занят. Хотелось бы ещё услышать флейм по поводу того, как в одном флаконе соединяются редакторы win- и web-форм,
С редактором поступили очень цинично. Взяли то что упакован во фреймворк. Поищи в сети должны быть примеры реализации IDesignerHost и компании.
Но редактор это так. Семечки...
K>а то это задача одна из актуальнейших, но подойти к ней как-то тяжело.
Скрестить win и web это еще та задачка.
Расписывать ее по полочкам чисто ради флейма не осилю.
Но пару советов могу дать:
Старайся сделать описание UI максимально декларативным. В крейнем случае некие самописные скрипты (совсем без кода сложно).
Это нужно чтобы можно было генерить по этому делу и жабаскрипт, и серверные проверки правильности ввода, и проверки в win-клиенте.
На жабаскрипт пологаться не стоит. Он может быть банально отключен. И это если про кулхацкеров не вспоминать.
Также имей в виду что будет засада с лейаутами. Уж больно они разные у win и web.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>Также имей в виду что будет засада с лейаутами. Уж больно они разные у win и web.
Есть хорошая идея: в Win пользоваться только Flow layout.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>Также имей в виду что будет засада с лейаутами. Уж больно они разные у win и web. S>Есть хорошая идея: в Win пользоваться только Flow layout.
В web есть еще как минимум grid layout.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: WH>В web есть еще как минимум grid layout.
Его нужно запретить под страхом смертной казни (вместе с постбэком. Впрочем, за последний можно ограничиться двадцатью пятью годами заключения).
Это слабая подделка под изначально корявую модель позиционирования в win.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>В web есть еще как минимум grid layout. S>Его нужно запретить под страхом смертной казни (вместе с постбэком. Впрочем, за последний можно ограничиться двадцатью пятью годами заключения). S>Это слабая подделка под изначально корявую модель позиционирования в win.
Не понял что плохого в table?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
WH>>Не понял что плохого в table? S>grid layout никакого отношения к table не имеет.
Ты с дефолтным виндовым (который по пикселям работает) не путаешь?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
Гм. Это ты что-то с чем-то путаешь.
Grid Layout в Web изобретен Microsoft, которые с упорством, достойным лучшего применения, сделали его дефолтным в MS VS 2003. Этот layout никакого отношения к таблицам не имеет, а использует тупое абсолютное позиционирование контролов, ровно как в Windows. Название свое он получил из типографской практики, см. http://en.wikipedia.org/wiki/Grid_%28page_layout%29
Если ты имел в виду джавовскую трактовку Grid Layout, то в вебе ее называют table layout, и страшно критикуют за разнообразные прегрешения. Впрочем, большинство дизайнеров таки признают, что "без таблиц сверстать мало-мальски сложный сайт для кроссбраузерного отображения практически невозможно".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
WH>>Также имей в виду что будет засада с лейаутами. Уж больно они разные у win и web. S>Есть хорошая идея: в Win пользоваться только Flow layout.
aka50,
E>>Нашлась бы добрая душа, да на пальцах бы объяснила, в чем смысл рассматриваемой в этом tech report-е проблемы. И чтобы примеры были более жизненные, а не Plus, PlusNeg и DblPlusNeg.
E>>А то все закручено, заморочено и сложно понять, нужно это вообще или нет?
A>А если в кратце, то там описывается техника deep mixin composition, т.е. глубокая модификация иерархии путем подмешивания в нее нужной функциональности.
Я уже начал помаленьку лабать статью на эту тему . В принципе обобщение простого наследования, то есть композиция через with и линеаризация — имхо это одни из самых сложных мест в Скале. Уже вторую неделю ломаю голову, как лучше описать их, чтобы было достаточно кратко и понятно.
ps: Надеюсь сим откровением твои планы не разрушил
Здравствуйте, Sinclair, Вы писали:
S>Grid Layout в Web изобретен Microsoft, которые с упорством, достойным лучшего применения, сделали его дефолтным в MS VS 2003. Этот layout никакого отношения к таблицам не имеет, а использует тупое абсолютное позиционирование контролов
Точно путаешь. Grid layout (термин из Swing, WPF) это то, что в вебе реализуется как раз таки при помощи таблиц и называется табличной версткой. То, о чем ты говоришь, так и называется absolute position layout (Canvas в WPF, в Swing не помню уже).
S>, ровно как в Windows. Название свое он получил из типографской практики, см. http://en.wikipedia.org/wiki/Grid_%28page_layout%29
A typographic grid is a two-dimensional structure made up of a series of intersecting vertical and horizontal axis used to structure content.
Это никак не абсолютное позиционирование. Там же пример есть:
Очень хорошо видно, что грид тут совсем никак не пиксельная сетка.
Ну и наконец — при разговоре о GUI под grid layout (не только в Swing) подразумевается вполне конкретная вещь.
Здравствуйте, AndrewVK, Вы писали: AVK>Точно путаешь. Grid layout (термин из Swing, WPF) это то, что в вебе реализуется как раз таки при помощи таблиц и называется табличной версткой.
Может быть, может быть. Хотя, насколько я помню SWING, его grid layout значительно жестче, чем даже table layout в вебе, т.к. компоненты не могут пересекать границы клеток. AVK> То, о чем ты говоришь, так и называется absolute position layout (Canvas в WPF, в Swing не помню уже). S>>, ровно как в Windows. Название свое он получил из типографской практики, см. http://en.wikipedia.org/wiki/Grid_%28page_layout%29 AVK>
A typographic grid is a two-dimensional structure made up of a series of intersecting vertical and horizontal axis used to structure content.
AVK>Это никак не абсолютное позиционирование. Там же пример есть: AVK> AVK>Очень хорошо видно, что грид тут совсем никак не пиксельная сетка.
Ну, я так понял, что выбор самих направляющих в значительной мере произволен; и что привязка выполняется только для левого верхнего угла — обрати внимание, как свободно тексты пересекают границы ячеек. Т.е. речь идет о независимом позиционировании элементов, и собственно grid сводится к фиксации возможных значений top и left. Нет никаких намеков на поведение позиционирования при изменении размеров элементов. AVK>Ну и наконец — при разговоре о GUI под grid layout (не только в Swing) подразумевается вполне конкретная вещь. AVK>
Может быть, может быть. То, что называлось Grid Layout в VS 2003/2005 — преступление против эстетики и здравого смысла.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>aka50,
E>>>Нашлась бы добрая душа, да на пальцах бы объяснила, в чем смысл рассматриваемой в этом tech report-е проблемы. И чтобы примеры были более жизненные, а не Plus, PlusNeg и DblPlusNeg.
E>>>А то все закручено, заморочено и сложно понять, нужно это вообще или нет?
A>>А если в кратце, то там описывается техника deep mixin composition, т.е. глубокая модификация иерархии путем подмешивания в нее нужной функциональности.
LCR>Я уже начал помаленьку лабать статью на эту тему . В принципе обобщение простого наследования, то есть композиция через with и линеаризация — имхо это одни из самых сложных мест в Скале. Уже вторую неделю ломаю голову, как лучше описать их, чтобы было достаточно кратко и понятно.
Для меня пока слжное место — self type и абстрактные типы. В частности не очень понимаю, почему
trait Base {
type T <: A
trait A requires T {
def fun(v: T)
}
}
trait Base1 extends Base {
type T = A1
class A1 extends A {
val v = 1
def fun(v: T) = println(v)
}
}
object base1 extends Base1
trait Base11 extends Base1 {
class A11 extends A1
}
object base11 extends Base11
object Test extends Application {
val v1 = new base1.A1
val v11 = new base11.A11
v1.fun(v11); // this code
v11.fun(v1); // not work
}
pathdep.scala:29: error: type mismatch;
found : base11.A11
required: base1.T
v1.fun(v11);
^
pathdep.scala:30: error: type mismatch;
found : base1.A1
required: base11.T
v11.fun(v1);
^
Почему после refinement (как это по русски? ) type T = A1 по идее дальше во всех наследниках тип T должен иметь вполне конктретный тип Base1.A1, но компилятор продолжает упорно втыкать Base11.this.T Base1.this.T и т.д. Т.е. делкарация requires не дает возможности нормально наследоваться, т.к. все методы будут постоянно требовать переорпеледения типа и будут тотально несовместимы при любом refinement...
ЗЫ: за эту проблемку eao197 спасибо , это он озадачил...
LCR>ps: Надеюсь сим откровением твои планы не разрушил
Нарушил , но я тебе мыло отослал, только ты пока не ответил...
Здравствуйте, aka50, Вы писали:
A>Почему после refinement (как это по русски? ) type T = A1 по идее дальше во всех наследниках тип T должен иметь вполне конктретный тип Base1.A1, но компилятор продолжает упорно втыкать Base11.this.T Base1.this.T и т.д. Т.е. делкарация requires не дает возможности нормально наследоваться, т.к. все методы будут постоянно требовать переорпеледения типа и будут тотально несовместимы при любом refinement...
А вот и ответ в рассылке дали
you're forgetting that when you write type T = A1, you're really writing type T=this.A1, so that
base11.T = base11.A1 (actually, type T=this.type#A1 and base11.type#T = base11.type#A1)
Т.е. я собственно что-то подобное себе и представлял (когда описывал проблему Евгению), но "математически" выразить не мог...
Здравствуйте, Sinclair, Вы писали:
S>Может быть, может быть. Хотя, насколько я помню SWING, его grid layout значительно жестче, чем даже table layout в вебе,
Во-первых он настраиваемый, во-вторых есть еще GridBagLayout, в третьих в WPF Grid это умеет. Вобщем, это уже мелочи, не влияющие на принцип.
AVK>>Очень хорошо видно, что грид тут совсем никак не пиксельная сетка. S>Ну, я так понял, что выбор самих направляющих в значительной мере произволен; и что привязка выполняется только для левого верхнего угла — обрати внимание, как свободно тексты пересекают границы ячеек.
Но это же типографский термин. Здесь речь идет уже о GUI, а там этот термин трактуют несколько иначе.
. В принципе обобщение простого наследования, то есть композиция через with и линеаризация — имхо это одни из самых сложных мест в Скале. Уже вторую неделю ломаю голову, как лучше описать их, чтобы было достаточно кратко и понятно.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
.png)
) type T = A1 по идее дальше во всех наследниках тип T должен иметь вполне конктретный тип Base1.A1, но компилятор продолжает упорно втыкать Base11.this.T Base1.this.T и т.д. Т.е. делкарация requires не дает возможности нормально наследоваться, т.к. все методы будут постоянно требовать переорпеледения типа и будут тотально несовместимы при любом refinement... 
, это он озадачил...
, но я тебе мыло отослал, только ты пока не ответил...
