Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Для этого фильтры есть, зачем тебе наследование?

D>Кроме того, наследование (особенно template method, конкретно мною сделанный и полностью меня устраивающий) помогает структурировать мозги и код. А ещё по нему проще понять, что ожидается от реализации, чем от расположенных хрен знает где (и скорее всего даже не в одном месте, если среди них есть и библиотечные, и app-specific) третьих методов, пользы от которых для читаемости и обучения ничуть не больше, чем от жавовских аннотаций.

В asp.net mvc все построено на конвенциях. По умолчанию, если ты вызываешь /home/index, то ищется HomeController, в нем ищется метод Index. который должен вернуть IActionResult. Все, остальное не забота фреймворка и разруливается программистом. Причем ASP.NET MVC сам подсказывает что нужно сделать. Он честно скажет что не найден метод в таком-то классе и такой-то сигнатурой.

Кстати IActionResult имеет один метод Execute и вообще не было бы смысла плодить интерфейс, если бы делегаты работали быстрее и можно было делать алиасы для типов.

D>UPD. Т.е. слабая связность имеет и свои обратные стороны (которые, кстати, тут неоднократно упоминались в контексте DI-фреймворков): когда код вообще ни хрена не связан, концы вообще хрен найдёшь.
Ну это банальная история. Пишется код, который разбивается на набор классов, вызывающих друг друга. Потом для покрытия тестами создаются везде интерфейсы и ссылки на классы заменяются на ссылки на интерфейсы, а экземпляры подсовываются через IOC. Дальше оказывается, что внесение изменений требует правки интерфейса, класса и пересборки всех ссылающихся на интерфейс. Тогда приходит в голову гениальная идея, вместо прямого вызова сделть "общую шину", через которую вызывать другие классы и все, концов уже не найдешь.


А всего-то надо было не заморачиваться с тестами.

Здравствуйте, gandjustas, Вы писали:

G>Ну это банальная история.

История действительно банальная,

G>А всего-то надо было не заморачиваться с тестами.

но вывод, мягко говоря, спорный. Правильный вывод должен быть другим: серебрянных пуль нет, и больших семь шапок из овцы сложную логику в простой код невозможно впихнуть в принципе. UPD: а ещё — что тестирование "снизу вверх" без моков рулит.

Здравствуйте, dimgel, Вы писали:

D>>Здравствуйте, gandjustas, Вы писали:

G>>>Для этого фильтры есть, зачем тебе наследование?

D>Короче говоря, зачем мне фильтры, если есть наследование. У меня вообще складывается ощущение, что тут многие ненавидят ООП просто за то, что вот они его любили, а оно их разочаровало: оказалось не серебрянной пулей, а просто одним из паттернов. И они теперь принципиально не юзают его вообще нигде, даже там, где оно вполне нормально ложится.

Ну например затем, что фильтры можно утащить в другой проект, а код написанный внутри класса можно утащить только копипастой. Хотя предполагалось что ООП улучшает реюз, поэтому и не нравится. Реюз через наследование — слишком хреновый способ.

Здравствуйте, gandjustas, Вы писали:

G>В asp.net mvc все построено на конвенциях. По умолчанию, если ты вызываешь /home/index, то ищется HomeController, в нем ищется метод Index. который должен вернуть IActionResult. Все, остальное не забота фреймворка и разруливается программистом. Причем ASP.NET MVC сам подсказывает что нужно сделать. Он честно скажет что не найден метод в таком-то классе и такой-то сигнатурой.

Если он это скажет как compile error, то всё хорошо. Как раз сейчас я все свои наработки перефигачиваю под макросы именно с этой целью: некоторые иерархии, непроверяемые соглашения и т.п. превратить в соглашения, проверяемые на этапе компиляции макросами. Но не все, повторюсь; некоторые не смогу просто в силу ограничений макросов (начинаю уже почёсывать репу в сторону плагина компилятора — там возможностей вроде и не сильно больше, но для ряда сценариев это "несильно" оказывается ключевым), а кое-где меня ООП вполне устраивает.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>В asp.net mvc все построено на конвенциях. По умолчанию, если ты вызываешь /home/index, то ищется HomeController, в нем ищется метод Index. который должен вернуть IActionResult. Все, остальное не забота фреймворка и разруливается программистом. Причем ASP.NET MVC сам подсказывает что нужно сделать. Он честно скажет что не найден метод в таком-то классе и такой-то сигнатурой.

D>Если он это скажет как compile error, то всё хорошо.
Не скажет, ибо не знает никаким образом, что запрос придет на /home/index

Здравствуйте, gandjustas, Вы писали:

D>>Короче говоря, зачем мне фильтры, если есть наследование.

G>Ну например затем, что фильтры можно утащить в другой проект, а код написанный внутри класса можно утащить только копипастой. Хотя предполагалось что ООП улучшает реюз, поэтому и не нравится. Реюз через наследование — слишком хреновый способ.

Что реюз через наследование хренов, спорить глупо. Но реюз вообще хренов. Потому что в новом проекте мне почти всегда вдруг требуется какой-нибудь пустяковый преподвыподверт, в реюзанное не ложащийся. И кстати, совершенно пофиг, речь идёт про новый проект, новый модуль в том же проекте или вообще соседний метод в том же классе. Во всех случаях я буду рефакторить и подкручивать существующее API: в границах проекта оно зацепит все сорцы, где уже используется, а в новый проект — копипаста рулит, если не хочется трогать старый проект. (А вообще, it depends: иногда дешевле и/или выгоднее исправить и юзать общий код в нескольких проектах. Но оно по жизни всё так — it depends; с этой формулировочкой наперевес даже и спорить как-то скучно и не о чем.)

Здравствуйте, 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-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

D>>>Если он это скажет как compile error, то всё хорошо.
G>>Не скажет, ибо не знает никаким образом, что запрос придет на /home/index

D>Ну и низачот, чё. А у меня — скажет, потому что в моём абстрактном классе Page, кроме абстрактоного метда service() есть ещё uri(params: (String, String)*) (в реализациях по желанию добавляются overloaded статически типизированные uri(ParamObject)), и если хоть одна страница на данную ссылается, она вызывает её uri() для генерации ссылки, и ссылку на несуществующую страницу я при такой модели не пропущу. Про метод checkRights() я уже говорил... А в рамках вот этого повально популярного идиотизма с методом-на-URI вместо класса-на-URI такое не сделать, разве что ввести очередное naming convention типа Index_CheckRights, Index_URI и т.п. Которое, впрочем, компилятором опять же не проверится, так что один хрен низачот. Это раз.
Ну в ASP.NET MVC с первых версий есть хелперы, которые позволяют писать так:

Html.ActionLink<CatalogController>(c => c.Product(id))

И в разметке появится ссылка /Ctatalog/Product/{id}, ессено проверятся при компиляции. И для этого вовсе не надо контроллеры нагружать генерацией ссылок.

Да и не очень понятно зачем uri в классе Page, это ведь надо инстанцировать Page для получения ссылки.


D>Во-вторых, хрен отличишь обычный метод от HTTP-замапенного. В спринге это решается очередной <матерно>аннотацией</матерно>. Точнее, сразу несколькими (на класс, на метод, на параметры). В общем, утяжеляется всё сразу и резко.
В MVC по умолчанию работают соглашения, но при желании можно обвешать все атрибутами. Это смотря что тебе удобнее.

Здравствуйте, gandjustas, Вы писали:

G>Да и не очень понятно зачем uri в классе Page, это ведь надо инстанцировать Page для получения ссылки.

Page у меня stateless, я их инстанциирую при запуске в том же духе, как и BL-контроллеры. (UPD: Простыня, выполняющая связывание, генерируется автоматически.)

G>В MVC по умолчанию работают соглашения, но при желании можно обвешать все атрибутами. Это смотря что тебе удобнее.

Понятно, полный комплект извращений, выбирай на вкус. А мне удобнее так, как я написал.

D>Здравствуйте, gandjustas, Вы писали:

G>

G>Html.ActionLink<CatalogController>(c => c.Product(id))
G>

Длинно. И опять же, доведённая до абсурда философия развязывания всего и вся мне не нравится: геморрою больше, чем пользы. И ещё: а если у страницы несколько параметров, и часть идут в path, часть в query string?

G>И для этого вовсе не надо контроллеры нагружать генерацией ссылок.

Нет, наоборот. Если в одном и том же месте — в подклассе Page — URL и генерируется, и парсится, это очень хорошо, легко на одном экране проверить симметричность кода, "и для этого вовсе не надо" (с) городить внешние хелперы.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, andyag, Вы писали:

A>>>>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.
G>>>Прекрасный вывод, но кажется полдня назад ты утверждал что
G>>>

A>>>>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

A>>Если есть какое-то противоречие, я его не вижу. Давайте по-другому попробую. Если язык говорит, что через конструкцию "class XXX { ... }" можно описывать ООПшные классы, это:
A>>1. во-первых не означает, что ООПшные классы нужно описывать именно этой конструкцией
A>>2. во-вторых не означает, что этой конструкцией можно описывать только ООПшные классы
G>Логическую нестыковку выделил. В процитированном фрагменте был смысл что нужно писать классы и они являются априори ООП (что на самом деле не так).
G>Какое будет финальное мнение?

Давайте ещё раз попробуем:

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

Теоретически почти на любом ЯП можно использовать почти любую парадигму программирования. Можно заниматься ФП на C#, это всегда потребует как минимум одного класса как минимум с одним методом. Наличие класса с методом в этом случае не будет частью вашего дизайна, это будет просто выполнением требований языка.

всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

Практически любой код не имеет смысла без интеграции с внешним миром. Интеграция с внешним миром достигается через применение библиотек/фреймворков. Выбрав язык, вы одновременно выбираете и внешний мир. Когда вы делаете выбор в пользу C#, оказывается, что абсолютное большинство библиотек — "объекто ориентированные". Простой пример — реализация веб-сервиса. Вы берёте ASP.NET Web API и внезапно выясняется, что есть какие-то объекты-контроллеры, что для конструирования этих объектов-контроллеров вам предлагается описать другие объекты (типа IDependencyResolver, которые по сути своей являются реализацией паттерна проектирования service locator), а чтобы не изобретать велосипед, вы скорее всего возьмёте готовый IoC-контейнер типа Unity или Ninject, которые по своей сути являются чем-то вроде обобщённой фабрики. В итоге часть вашего решения будет иметь ФП-дизайн, а часть ООП-дизайн. Причём в контексте C# (чтобы не вылезло ещё одно противоречие: речь всё ещё идёт про интеграцию с внешним миром) гарантированно будет ООП, а ФП вполне может не быть.

A>>Т.е. если кто-то пишет на Haskell, в котором не классов, и у него нет проблем, всем нужно всё бросить и переходить на Haskell?
G>Нет, это ишь говорит, что в аскеле достаточно средств, чтобы писать код и не использовать ООП.
Хорошо. Т.е. ваше утверждение сводится к простому "на Haskell можно писать код". Что вы пытались сказать?

A>>Есть ещё другие люди — они пишут на C#, в котором есть классы, и у них тоже нет проблем. Всем нужно всё бросить и переходить на C#?
G>Это еще не значит, что используют ООП.
Если это не теоретики-исследователи, совершенно точно используют в том или ином виде. Чуть выше описал почему.

A>>Абсолютно пофигу, если кто-то счастлив работать с инструментами, которые сильно отличаются от моих или ваших. У людей разная мотивация: кто-то "работает программистом", кто-то любит "программирование", а кто-то любит "делать всякие штуки". Первому, очевидно, вообще всё пофигу — лишь бы не уволили. Второй наизусть помнит все задачки из SICP. Третий с большей радостью сделает какой-то новый недопродукт и заставит людей на него смотреть, чем будет вспоминать что делает этот кусок на Scheme, который ещё 10 минут назад казался абсолютно понятным.
G>К чему эта фраза? Увести разговор от обсуждения пользы паттернов и ООП в современных языках?
Эта фраза выражает мою точку зрения на ваше настроение "изучать ФП и SICP — круто, изучать паттерны — фигня". Мысль, которую я пытаюсь донести, очень проста: можно знать ФП, можно не знать ФП. Знать ФП не необходимо. Давайте ещё напомню с чего топик начался: я попросил подсказать литературу по конкретным темам. С тех пор вы неустанно пытаетесь меня убедить, что такая литература не нужна

G>>>ЗЫ. Кстати в книге pragmatic programmer, о которой я выше писал, рекомендуется изучать по одному языку в год.
A>>Это одна из моих всею душою любимых книг.
G>и тем не менее
G>

A>>изучением миллионов языков я уже переболел

Снова какое-то противоречие на пустом месте? Мне извиниться, что в этом году я задрачиваюсь по JavaScript, а не по Scheme?

Здравствуйте, andyag, Вы писали:

A>

A>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.

A>Теоретически почти на любом ЯП можно использовать почти любую парадигму программирования. Можно заниматься ФП на C#, это всегда потребует как минимум одного класса как минимум с одним методом. Наличие класса с методом в этом случае не будет частью вашего дизайна, это будет просто выполнением требований языка.
Это неверно. Если у тебя нет ФВП в языке, то практически тебе недоступно ФП (как в Java ранних версий). Если тебе недоступен динамический полиморфизм по неявному аргументу через указатель на объект, то у тебя нет ООП (как в haskell без расширений).


A>

A>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны

A>Практически любой код не имеет смысла без интеграции с внешним миром. Интеграция с внешним миром достигается через применение библиотек/фреймворков. Выбрав язык, вы одновременно выбираете и внешний мир. Когда вы делаете выбор в пользу C#, оказывается, что абсолютное большинство библиотек — "объекто ориентированные". Простой пример — реализация веб-сервиса. Вы берёте ASP.NET Web API и внезапно выясняется, что есть какие-то объекты-контроллеры, что для конструирования этих объектов-контроллеров вам предлагается описать другие объекты (типа IDependencyResolver, которые по сути своей являются реализацией паттерна проектирования service locator), а чтобы не изобретать велосипед, вы скорее всего возьмёте готовый IoC-контейнер типа Unity или Ninject, которые по своей сути являются чем-то вроде обобщённой фабрики. В итоге часть вашего решения будет иметь ФП-дизайн, а часть ООП-дизайн. Причём в контексте C# (чтобы не вылезло ещё одно противоречие: речь всё ещё идёт про интеграцию с внешним миром) гарантированно будет ООП, а ФП вполне может не быть.

Ты неверно понимаешь ООП. ООП это не наличие классов. Это проектирование приложения, через композицию объектов и полиморфизм через наследование.
Реализация интерфейса фактически не является ни в каком роде ООП, просто в языке типа C# нет другим способов объявить несколько связанных методов, кроме как создать класс, который реализует интерфейс.

Берем тот же MVC. В теории мы там наследуемся от класса controller на практике не переопределяем ни одного метода, то есть никакого полиморфизма нет, а наследование — просто кривой способ удовлетворения контракта, ибо другого не было на момент создания MVC. IDependencyResolver — отличный пример, который можно без потери функциональности заменить одной ФВП — Func<Type, IEnumerable<object>>. Но в C# нельзя алиас типа сделать, поэтому для лучшей читабельности делают интерфейс и реализацию в виде класса. То есть снова интерфейсы и классы — деталь реализации, зависящая от особенностей языка, а вовсе не от того, что это какие то паттерны.
Паттерны — лишь следствие особенностей языка, а не основополагающий аспект проетирования. Поэтому изучать паттерны большого смысла не имеет, скорее всего любое умышленное применение паттернов будет вредным.


A>Эта фраза выражает мою точку зрения на ваше настроение "изучать ФП и SICP — круто, изучать паттерны — фигня". Мысль, которую я пытаюсь донести, очень проста: можно знать ФП, можно не знать ФП. Знать ФП не необходимо. Давайте ещё напомню с чего топик начался: я попросил подсказать литературу по конкретным темам.
Если ФП поменять на "паттерны" будет то же самое. Тем не менее программисты, знающие ФП, на практике оказываются на голову лучше, тех, кто не знает. А вот с паттернами такое не наблюдается (особенно с теми, что GOF).

A>С тех пор вы неустанно пытаетесь меня убедить, что такая литература не нужна
Подмена понятий. Я говорил что паттерны нужны, а ссылки на всю литературу я привел, её обязательно надо читать, но относиться критически.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, andyag, Вы писали:

A>>

A>>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.

A>>Теоретически почти на любом ЯП можно использовать почти любую парадигму программирования. Можно заниматься ФП на C#, это всегда потребует как минимум одного класса как минимум с одним методом. Наличие класса с методом в этом случае не будет частью вашего дизайна, это будет просто выполнением требований языка.
G>Это неверно. Если у тебя нет ФВП в языке, то практически тебе недоступно ФП (как в Java ранних версий).

Вы наверное не знакомы с Java. Давайте расскажу. Вот так делалось ФП в Java до 1.8:

interface Func1<TResult, TArg1> {
  TResult apply(TArg1 arg1);
}

interface Func2<TResult, TArg1, TArg2> {
  TResult apply(TArg1 arg1, TArg2 arg2);
}
...
Func1<TResult, TArg2> bindFirst(Func2<TResult, TArg1, TArg2> func2, TArg1 arg1) {
  return new Func1<TResult, TArg2>() {
    TResult apply(TArg2 arg2) {
      return func2.apply(arg1, arg2);
    }
  };
}

Func2<Integer, Integer, Integer> add = new Func2() {
  Integer apply(Integer a, Integer b) {
    return a + b;
  }
};

Func1<Integer, Integer> addFive = bindFirst(add, 5);
int result = addFive.apply(3);
assertEquals(8, result);

Длинно и страшно — да. Невозможно — нет.

С выходом Java 1.8 появился синтаксический сахар: когда нужно реализовать интерфейс с единственным методом, можно делать вот так:

Func2<Integer, Integer, Integer> add = (a, b) -> a + b;

Поменялся только синтаксис языка — стало немного меньше мусора, но работает оно точно так же как и раньше. Даже вызов этих Func2 остаётся прежним:

int result = add.apply(2, 3);

G>Если тебе недоступен динамический полиморфизм по неявному аргументу через указатель на объект, то у тебя нет ООП (как в haskell без расширений).
Я не знаю где вы взяли эти критерии — скорее всего с потолка.
1. Посмотрите например на Майкрософтовский COM — это яркий пример объектно-ориентированного дизайна на не-ОО языке.
2. Вот тут аж целая книжка "Object-Oriented Programming With ANSI-C": http://www.cs.rit.edu/~ats/books/ooc.pdf
Снова, длинно и страшно — да. Невозможно — нет..

A>>Практически любой код не имеет смысла без интеграции с внешним миром. Интеграция с внешним миром достигается через применение библиотек/фреймворков. Выбрав язык, вы одновременно выбираете и внешний мир. Когда вы делаете выбор в пользу C#, оказывается, что абсолютное большинство библиотек — "объекто ориентированные". Простой пример — реализация веб-сервиса. Вы берёте ASP.NET Web API и внезапно выясняется, что есть какие-то объекты-контроллеры, что для конструирования этих объектов-контроллеров вам предлагается описать другие объекты (типа IDependencyResolver, которые по сути своей являются реализацией паттерна проектирования service locator), а чтобы не изобретать велосипед, вы скорее всего возьмёте готовый IoC-контейнер типа Unity или Ninject, которые по своей сути являются чем-то вроде обобщённой фабрики. В итоге часть вашего решения будет иметь ФП-дизайн, а часть ООП-дизайн. Причём в контексте C# (чтобы не вылезло ещё одно противоречие: речь всё ещё идёт про интеграцию с внешним миром) гарантированно будет ООП, а ФП вполне может не быть.

G>Ты неверно понимаешь ООП. ООП это не наличие классов. Это проектирование приложения, через композицию объектов и полиморфизм через наследование.
G>Реализация интерфейса фактически не является ни в каком роде ООП, просто в языке типа C# нет другим способов объявить несколько связанных методов, кроме как создать класс, который реализует интерфейс.

Перечитайте пожалуйста что я написал. Слова "объект" и "объекты" выделены жирным, чтобы показать их первостепенность, а "IDependencyResolver" нежирный и указан в скобках как уточнение о каких объектах идёт речь.

G>Берем тот же MVC. В теории мы там наследуемся от класса controller на практике не переопределяем ни одного метода, то есть никакого полиморфизма нет, а наследование — просто кривой способ удовлетворения контракта, ибо другого не было на момент создания MVC. IDependencyResolver — отличный пример, который можно без потери функциональности заменить одной ФВП — Func<Type, IEnumerable<object>>. Но в C# нельзя алиас типа сделать, поэтому для лучшей читабельности делают интерфейс и реализацию в виде класса. То есть снова интерфейсы и классы — деталь реализации, зависящая от особенностей языка, а вовсе не от того, что это какие то паттерны.

Вот снова вы. Конечно можно. Можно вообще все API ASP.NET сделать функциональными. Но это только у вас в голове, а на практике там ОО.

A>>Эта фраза выражает мою точку зрения на ваше настроение "изучать ФП и SICP — круто, изучать паттерны — фигня". Мысль, которую я пытаюсь донести, очень проста: можно знать ФП, можно не знать ФП. Знать ФП не необходимо. Давайте ещё напомню с чего топик начался: я попросил подсказать литературу по конкретным темам.
G>Если ФП поменять на "паттерны" будет то же самое. Тем не менее программисты, знающие ФП, на практике оказываются на голову лучше, тех, кто не знает. А вот с паттернами такое не наблюдается (особенно с теми, что GOF).

Это только ваша субъективная статистика. Я предпочёл бы, чтобы у многих моих коллег был GoF головного мозга, вместо того, что у них там сейчас. Я искренне предпочёл бы, чтобы джуниор писал всем ненавистный синглтон вместо статического класса с состоянием. Просто потому что синглтон лучше поддаётся рефакторингу в сторону DI. Но это, снова, субъективно.

Здравствуйте, dimgel, Вы писали:

D>>Здравствуйте, gandjustas, Вы писали:

G>>

G>>Html.ActionLink<CatalogController>(c => c.Product(id))
G>>

D>Длинно. И опять же, доведённая до абсурда философия развязывания всего и вся мне не нравится: геморрою больше, чем пользы.
Можно и сократить. Главное — собственно в вызове
D>И ещё: а если у страницы несколько параметров, и часть идут в path, часть в query string?
Тогда этот код начинает рулить ещё сильнее, т.к. изменения routing автоматически учитываются. Фреймворк берёт метод и ищет его роут, подставляя параметры ровно куда надо.
D>Нет, наоборот. Если в одном и том же месте — в подклассе Page — URL и генерируется, и парсится, это очень хорошо, легко на одном экране проверить симметричность кода, "и для этого вовсе не надо" (с) городить внешние хелперы.
Это верно. Просто в нормальном случае URL в классе Page не парсится. оттого и генерировать его там никакого желания нет.

Здравствуйте, LaptevVV, Вы писали:

LVV>То есть это все говорит, что нужно писать единую книжку.

LVV>Кто б из наших гуру занялся бы, а?
LVV>А я б редактировал.

Стань этим гуру — отредактируй книгу целиком.

+-----------------+
|                 |
|   Лаптев В.В.   |
|                 |
|   Всё об ООП    |
|                 |
|                 |
|                 |
|  Издательство   |
|      КЫВТ       |
|                 |
|      2015       |
+-----------------+

Здравствуйте, AleksandrN, Вы писали:

AN>Здравствуйте, LaptevVV, Вы писали:

LVV>>То есть это все говорит, что нужно писать единую книжку.

LVV>>Кто б из наших гуру занялся бы, а?
LVV>>А я б редактировал.

AN>Стань этим гуру — отредактируй книгу целиком.

AN>

AN>+-----------------+
AN>|                 |
AN>|   Лаптев В.В.   |
AN>|                 |
AN>|   Всё об ООП    |
AN>|                 |
AN>|                 |
AN>|                 |
AN>|  Издательство   |
AN>|      КЫВТ       |
AN>|                 |
AN>|      2015       |
AN>+-----------------+
AN>

Дык ее сначала написать надо.
А чтоб тебе было понятно, что я не с бодуна о редактировании написал — я редактировал вот эту книгу: http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/table_of_contents.html
Естественно, в переводе. Но пришлось читать оригинал, ибо переводчик явно использовал не мозги, а программу...

A>Посоветуйте пожалуйста.

Почти оффтоп.

Design Patterns in Dynamic Languages. http://www.norvig.com/design-patterns/

В функциональных языках многие паттерны органически «вшиты» в сам язык.