Сообщение Re[18]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA от 25.12.2014 23:23
Изменено 26.12.2014 0:47 dimgel
Здравствуйте, gandjustas, Вы писали:
D>>Если он это скажет как compile error, то всё хорошо.
G>Не скажет, ибо не знает никаким образом, что запрос придет на /home/index
Ну и низачот, чё. А у меня — скажет, потому что в моём абстрактном классе Page, кроме абстрактоного метда service() есть ещё uri(ParamObject), и если хоть одна страница на данную ссылается, она вызывает её uri() для генерации ссылки, и ссылку на несуществующую страницу я при такой модели не пропущу. Про метод checkRights() я уже говорил... А в рамках вот этого повально популярного идиотизма с методом-на-URI вместо класса-на-URI такое не сделать, разве что ввести очередное naming convention типа Index_CheckRights, Index_URI и т.п. Которое, впрочем, компилятором опять же не проверится, так что один хрен низачот. Это раз.
Во-вторых, хрен отличишь обычный метод от HTTP-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.
D>>Если он это скажет как compile error, то всё хорошо.
G>Не скажет, ибо не знает никаким образом, что запрос придет на /home/index
Ну и низачот, чё. А у меня — скажет, потому что в моём абстрактном классе Page, кроме абстрактоного метда service() есть ещё uri(ParamObject), и если хоть одна страница на данную ссылается, она вызывает её uri() для генерации ссылки, и ссылку на несуществующую страницу я при такой модели не пропущу. Про метод checkRights() я уже говорил... А в рамках вот этого повально популярного идиотизма с методом-на-URI вместо класса-на-URI такое не сделать, разве что ввести очередное naming convention типа Index_CheckRights, Index_URI и т.п. Которое, впрочем, компилятором опять же не проверится, так что один хрен низачот. Это раз.
Во-вторых, хрен отличишь обычный метод от HTTP-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.
Здравствуйте, gandjustas, Вы писали:
D>>Если он это скажет как compile error, то всё хорошо.
G>Не скажет, ибо не знает никаким образом, что запрос придет на /home/index
Ну и низачот, чё. А у меня — скажет, потому что в моём абстрактном классе Page, кроме абстрактоного метда service() есть ещё uri(params: (String, String)*) (в реализациях по желанию добавляются overloaded uri(ParamObject)), и если хоть одна страница на данную ссылается, она вызывает её uri() для генерации ссылки, и ссылку на несуществующую страницу я при такой модели не пропущу. Про метод checkRights() я уже говорил... А в рамках вот этого повально популярного идиотизма с методом-на-URI вместо класса-на-URI такое не сделать, разве что ввести очередное naming convention типа Index_CheckRights, Index_URI и т.п. Которое, впрочем, компилятором опять же не проверится, так что один хрен низачот. Это раз.
Во-вторых, хрен отличишь обычный метод от HTTP-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.
D>>Если он это скажет как compile error, то всё хорошо.
G>Не скажет, ибо не знает никаким образом, что запрос придет на /home/index
Ну и низачот, чё. А у меня — скажет, потому что в моём абстрактном классе Page, кроме абстрактоного метда service() есть ещё uri(params: (String, String)*) (в реализациях по желанию добавляются overloaded uri(ParamObject)), и если хоть одна страница на данную ссылается, она вызывает её uri() для генерации ссылки, и ссылку на несуществующую страницу я при такой модели не пропущу. Про метод checkRights() я уже говорил... А в рамках вот этого повально популярного идиотизма с методом-на-URI вместо класса-на-URI такое не сделать, разве что ввести очередное naming convention типа Index_CheckRights, Index_URI и т.п. Которое, впрочем, компилятором опять же не проверится, так что один хрен низачот. Это раз.
Во-вторых, хрен отличишь обычный метод от HTTP-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.