Здравствуйте, andyag, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, andyag, Вы писали:
A>>>Эти штуки C#/.NET безусловно рвут Java в плане скорости разработки и защиты от ошибок, но всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. G>>Для Linq все методы являются методами-расширениями, которые по сути стирают различия между method(a,b) a.method(b). А классы в этом случае не более чем пространства имен. В новом C# имена классов можно писать в using и не использовать квалифицированные имена методов других классов.
A>Благодаря тому, что в последние несколько лет в C# регулярно появляется всё больше не-чисто-ООПшных штук, вполне ожидаемо, что в C# комьюнити появляются люди, которые пытаются всё тянуть под эти самые не-ООПшные штуки. Но за этим ничего нет — просто обязательно кто-то будет пытаться убедить оппонента, что в C# можно делать всё по-другому. Можно. А зачем?
1) меньше кода
2) больший контроль со стороны компилятора
3) меньше связность
4) Чистые функции (меньше ошибок)
G>>Да и вообще есть scriptcs, в котом классы в C# писать не обязательно. A>В мире Java есть Groovy — тоже можно не писать классы. К чему это?
Ты не понял? groovy это другой язык, а scriptcs это тот же самый C#, в котором нет необходимости писать классы.
A>>>И где-то в этой точке одновременно появляются паттерны и исчезает разница между .NET и Java. G>>Нет такой точки самой по себе. Она только в голове программиста.
A>Такая точка появляется при любой попытке заинтегрировать свой LINQ-only код с 99% фреймворков — начиная с MSTest/NUnit, где надо писать классы и вешать на них аттрибуты, и заканчивая ASP.NET WebAPI, где вообще от ApiController наследоваться нужно.
Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано. Да и раньше достаточно было реализовать IController только. ControllerBase нужен только для того, чтобы методы вызывать без префикса-имени класса. А, как уже писал выше в C# новой версии это не нужно, поэтому и потребность в базовом классе отпала, а да и в каком либо интерфейсе.
Просто ASP.NET MVC появился тогда, когда появился .NET 3.5 и на тот момент ООП еще будоражило умы людей. А webapi тупо скопировал дизайн ASP.NET MVC. Прошло 5 лет и народ попроще стал относится к ООП, перестал плодить абстрактные фабрики стратегий.
A>>>Не поймите меня неправильно: я последние несколько лет пишу параллельно на C# и Java, отлично понимаю разницу между одной выразительной строчкой на LINQ и сотней плохочитаемых строчек в JPA, отлично знаю какой это геморрой делать UI без async/await. Но это всё просто инструменты языка — где-то они заменяют нагромождение классов, где-то уменьшают это нагромождение, а где-то от них ни холодно, ни жарко. A>>>ИМХО, вещи совершенно параллельные. G>>Самое главное что эти методы позволяют по другому строить программы. Не как рекурсивную композицию объектов, а как композицию функций. A>Не соглашусь. Эта ценность есть только у вас в голове.
Ну не соглашайся, твое дело.
Попробуй просто на досуге собрать на принципах ООП (применяя любые паттерны из GOF) чтонить вроде linq.
Здравствуйте, andyag, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, andyag, Вы писали:
A>>>Здравствуйте, gandjustas, Вы писали:
G>>>>2) паттерн претендуют на незвисимость от языка и платформы A>>>Неправда. Если взять паттерны GoF, речь "официально" идёт только о языках, умеющих ООП. Прямо на обложке написано. G>>И неправильно написано. Речь идет о языках, умеющих только ООП. Почувствуй разницу.
A>Это какой-то флуд уже пошёл. Не бывает языков, которые умеют _только_ ООП.
Как это? simula, smalltalk, C++ ранних версий. Там кроме ООП практически нет средств и подульности, ни композиции.
A>>>К чему тут слово "платформа" — не понял. G>>Например MVC, про который говоритс в GOF совершенно не нужен в WPF, где во всю рулит MVVM.
A>MVC в GoF? Вы уверены, что читали книгу?
Уверен, а ты?
В русском издании раздел 1.2 имеет название" Паттерны проектирования в схеме MVC в языке Smalltalk".
A>Если стоит задача "не применять", то не-применять можно всё что угодно. Почему это должны быть именно паттерны GoF?
Потому что их слишком легко применять неправильно и не к месту.
G>>Когда изучишь 50 способов сделать тоже самое, то поймешь почему паттерны не нужно применять. A>Сомнительный подход. Не получится потом, что находишь себя 40-летним дядькой, который единственное что умеет — делать одну и ту же ненужную хрень 50 разными способами?
Для начала попробуй сделать ProblemK хотя бы на 10 разных яызках.
После этого можешь броить разработку, написать книгу по архитектуре и проводить безумно дорогие тренинги для неофитов.
Re[11]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано.
D>Обычно это означает — меньший контроль со стороны компилятора.
А раньше какой контроль был?
Пример
public class HomeController: Controller
{
ActionResult Index()
{
return View();
}
}
Какие использовались соглашения:
1) Имя класса контроллера заканчивается на Controller
2) Action возвращает ActionResult (хотя может возвращать что угодно, главное не void)
Что из них проверяется компилятором? Внезапно ничего.
Единственная ценность наследования в данном случае — это писать return View(), а не return new ViewResult().
Но в новом C# можно написать return View(), даже если метод View находится в другом классе.
Re[10]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, andyag, Вы писали:
A>>Это какой-то флуд уже пошёл. Не бывает языков, которые умеют _только_ ООП. G>Как это? simula, smalltalk, C++ ранних версий. Там кроме ООП практически нет средств и подульности, ни композиции.
Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО. Точно так же как и в языках без поддержки ООП из коробки можно самостоятельно сделать своё ООП. В первом случае программиста назовут идиотом, потому что он использует "слишком мало" возможностей языка, во втором случае — потому использует язык, возможностей которого не хватает для избранного подхода к дизайну.
A>>MVC в GoF? Вы уверены, что читали книгу? G>Уверен, а ты? G>В русском издании раздел 1.2 имеет название" Паттерны проектирования в схеме MVC в языке Smalltalk".
Сорри — утверждение проинтерпретировалось как "MVC — паттерн из GoF". То что он там где-то в районе предисловия был вполне допускаю.
A>>Если стоит задача "не применять", то не-применять можно всё что угодно. Почему это должны быть именно паттерны GoF? G>Потому что их слишком легко применять неправильно и не к месту.
Ага, то ли дело — изучить ФП.
G>>>Когда изучишь 50 способов сделать тоже самое, то поймешь почему паттерны не нужно применять. A>>Сомнительный подход. Не получится потом, что находишь себя 40-летним дядькой, который единственное что умеет — делать одну и ту же ненужную хрень 50 разными способами? G>Для начала попробуй сделать ProblemK хотя бы на 10 разных яызках.
Спасибо, изучением миллионов языков я уже переболел, парсеры и обход графа делать умею.
Re[12]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Какие использовались соглашения: G>1) Имя класса контроллера заканчивается на Controller G>2) Action возвращает ActionResult (хотя может возвращать что угодно, главное не void) G>Что из них проверяется компилятором? Внезапно ничего.
Если так, то может быть. Но у меня кроме Index() обычно ещё куча всяких вспомогательных методов в контроллере (проверка прав, например; а в случае REST-двигла там вообще развесистый template method), и наследование начинает рулить со страшной силой: code completion, защита от опечаток и т.п. В этой связи я когда-то высказывался (в теме, называвшейся что-то типа "что вам не нравится в языках, на которых вы пишете") про жаву, что ейные фреймворки целиком на POJO+аннотациях вместо наследования — уничтожают саму идею статики.
Re[11]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, andyag, Вы писали:
A>>>Это какой-то флуд уже пошёл. Не бывает языков, которые умеют _только_ ООП. G>>Как это? simula, smalltalk, C++ ранних версий. Там кроме ООП практически нет средств и подульности, ни композиции.
A>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО.
Прекрасный вывод, но кажется полдня назад ты утверждал что
A>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны
A>Точно так же как и в языках без поддержки ООП из коробки можно самостоятельно сделать своё ООП. В первом случае программиста назовут идиотом, потому что он использует "слишком мало" возможностей языка, во втором случае — потому использует язык, возможностей которого не хватает для избранного подхода к дизайну.
И как же люди на haskell или scheme пишут... там вообще классов нет. Да и линукс написан на голом С без классов.
Видимо в ООП не так много ценности, что его так игнорируют и не страдают.
A>>>MVC в GoF? Вы уверены, что читали книгу? G>>Уверен, а ты? G>>В русском издании раздел 1.2 имеет название" Паттерны проектирования в схеме MVC в языке Smalltalk". A>Сорри — утверждение проинтерпретировалось как "MVC — паттерн из GoF". То что он там где-то в районе предисловия был вполне допускаю.
Его жизнь началась с GOF, до этого никто не слышал о таком. Если посмотреть историю, то до GOF было два упоминания MVC в публичном доступе, что в отсутствии повсеместного доступа в интернет означало, что об MVC не знал никто.
По сути до появления массового общедоступного интернета знания распространялись только в книгах. Сейчас таким носителем служат скорее блоги, записи выступлений, вебкасты? презентации и StackOverflow.
G>>>>Когда изучишь 50 способов сделать тоже самое, то поймешь почему паттерны не нужно применять. A>>>Сомнительный подход. Не получится потом, что находишь себя 40-летним дядькой, который единственное что умеет — делать одну и ту же ненужную хрень 50 разными способами? G>>Для начала попробуй сделать ProblemK хотя бы на 10 разных яызках. A>Спасибо, изучением миллионов языков я уже переболел, парсеры и обход графа делать умею.
Вот в этом и фишка. Парсеры и обходы графов умеют многие, а сделать из этого приложение, выполняющее осмысленные действия — почти никто. И ключевой навык нужный для этого — композиция.
Поэтому и полезно решать такие задачи, причем на разных языках, потому что появляется навык применять нереальное число способов композиции.
ЗЫ. Кстати в книге pragmatic programmer, о которой я выше писал, рекомендуется изучать по одному языку в год.
Re[10]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, andyag, Вы писали:
A>>Благодаря тому, что в последние несколько лет в C# регулярно появляется всё больше не-чисто-ООПшных штук, вполне ожидаемо, что в C# комьюнити появляются люди, которые пытаются всё тянуть под эти самые не-ООПшные штуки. Но за этим ничего нет — просто обязательно кто-то будет пытаться убедить оппонента, что в C# можно делать всё по-другому. Можно. А зачем?
G>1) меньше кода G>2) больший контроль со стороны компилятора G>3) меньше связность G>4) Чистые функции (меньше ошибок)
Это ваша субъективная любовь к ФП или есть какие-то исследования, где 2 группы обезьян пишут на ФП и ООП?
A>>В мире Java есть Groovy — тоже можно не писать классы. К чему это? G>Ты не понял? groovy это другой язык, а scriptcs это тот же самый C#, в котором нет необходимости писать классы.
До тех пор пока оно не компилируется csc, это не C#. Если вы закрываете на это глаза, Groovy ничем не отличается от Java кроме необязательности классов.
A>>Такая точка появляется при любой попытке заинтегрировать свой LINQ-only код с 99% фреймворков — начиная с MSTest/NUnit, где надо писать классы и вешать на них аттрибуты, и заканчивая ASP.NET WebAPI, где вообще от ApiController наследоваться нужно. G>Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано. Да и раньше достаточно было реализовать IController только. ControllerBase нужен только для того, чтобы методы вызывать без префикса-имени класса. А, как уже писал выше в C# новой версии это не нужно, поэтому и потребность в базовом классе отпала, а да и в каком либо интерфейсе.
Не расслышал — вы говорите, всё ещё надо классы писать или мне показалось?
Re[12]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, andyag, Вы писали:
A>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, andyag, Вы писали:
A>>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО. G>Прекрасный вывод, но кажется полдня назад ты утверждал что G>
A>>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны
Если есть какое-то противоречие, я его не вижу. Давайте по-другому попробую. Если язык говорит, что через конструкцию "class XXX { ... }" можно описывать ООПшные классы, это:
1. во-первых не означает, что ООПшные классы нужно описывать именно этой конструкцией
2. во-вторых не означает, что этой конструкцией можно описывать только ООПшные классы
A>>Точно так же как и в языках без поддержки ООП из коробки можно самостоятельно сделать своё ООП. В первом случае программиста назовут идиотом, потому что он использует "слишком мало" возможностей языка, во втором случае — потому использует язык, возможностей которого не хватает для избранного подхода к дизайну. G>И как же люди на haskell или scheme пишут... там вообще классов нет. Да и линукс написан на голом С без классов. G>Видимо в ООП не так много ценности, что его так игнорируют и не страдают.
Т.е. если кто-то пишет на Haskell, в котором не классов, и у него нет проблем, всем нужно всё бросить и переходить на Haskell?
Есть ещё другие люди — они пишут на C#, в котором есть классы, и у них тоже нет проблем. Всем нужно всё бросить и переходить на C#?
Абсолютно пофигу, если кто-то счастлив работать с инструментами, которые сильно отличаются от моих или ваших. У людей разная мотивация: кто-то "работает программистом", кто-то любит "программирование", а кто-то любит "делать всякие штуки". Первому, очевидно, вообще всё пофигу — лишь бы не уволили. Второй наизусть помнит все задачки из SICP. Третий с большей радостью сделает какой-то новый недопродукт и заставит людей на него смотреть, чем будет вспоминать что делает этот кусок на Scheme, который ещё 10 минут назад казался абсолютно понятным.
G>ЗЫ. Кстати в книге pragmatic programmer, о которой я выше писал, рекомендуется изучать по одному языку в год.
Это одна из моих всею душою любимых книг.
Re[2]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Про MVC — нет такого, до GOF цельной инфы об MVC не было, да и GOF не внесли ясности. Разве что тут — http://rsdn.ru/forum/design/5406934.1
У Фаулера была статья, где он разбирал все эти MVC, MVP и т.п. Рассказ, помнится, начинался с утверждения, что нынче обзывают MVC всё что ни попади, а термин идёт от smalltalk и ихний самый первый и потому истинный MVC выглядел так: ... Как он выглядел, не помню, и вообще никакой конкретики оттуда не помню, да и пофиг, потому что меня поразило, насколько все эти паттерны друг на дружку похожи. Буквально: одним крошечным рефакторингом друг в дружку превращаются. Я хз как такое вообще запомнить и имеет ли смысл, если я рефакторингами получу то же самое или даже лучше. На днях появилась у меня версия: мода на баззворды пошла от убогого американского образования. Их учат не систематическому взгляду на мир, а разрозненным howto. Поэтому каждый чих должен иметь своё название.
Re[11]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, andyag, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, andyag, Вы писали:
A>>>Благодаря тому, что в последние несколько лет в C# регулярно появляется всё больше не-чисто-ООПшных штук, вполне ожидаемо, что в C# комьюнити появляются люди, которые пытаются всё тянуть под эти самые не-ООПшные штуки. Но за этим ничего нет — просто обязательно кто-то будет пытаться убедить оппонента, что в C# можно делать всё по-другому. Можно. А зачем?
G>>1) меньше кода G>>2) больший контроль со стороны компилятора G>>3) меньше связность G>>4) Чистые функции (меньше ошибок)
A>Это ваша субъективная любовь к ФП или есть какие-то исследования, где 2 группы обезьян пишут на ФП и ООП?
А при ем тут любовь? Вполне объективные факторы:
1) используем лямбды — не пишем вручную замыкания в командах (передачу параметров), не пишем сами классы команд — кода меньше, котроля со стороны компилятора больше.
2) Используем чистые фукнции (комбинаторы) — опять таки меньше кода, меньше связность (чистая функция зависит от параметров).
3) Не используем функциональную композицию — снижаем связность между классами и связность по состоянию.
4) про async\await вообще молчу, аснихронных код без async\await и честных замыканий написать нереально сложно.
И дело не только в ФП. Micosoft добивается высокой продуктивности разработчиков на C#, внедряя в язык эти самые паттерны. Просто многие фишки берут из ФЯ, ибо там многие паттерны уже 20-30 лет как реализованы.
A>>>В мире Java есть Groovy — тоже можно не писать классы. К чему это? G>>Ты не понял? groovy это другой язык, а scriptcs это тот же самый C#, в котором нет необходимости писать классы. A>До тех пор пока оно не компилируется csc, это не C#. Если вы закрываете на это глаза, Groovy ничем не отличается от Java кроме необязательности классов.
Оно компилируется Roslyn, который и есть компилятор C#, сделанный взамен древнего csc.
A>>>Такая точка появляется при любой попытке заинтегрировать свой LINQ-only код с 99% фреймворков — начиная с MSTest/NUnit, где надо писать классы и вешать на них аттрибуты, и заканчивая ASP.NET WebAPI, где вообще от ApiController наследоваться нужно. G>>Открою тайну, в ASP.NET 5 уж не нужно ни от чего наследоваться. там все на conventions сделано. Да и раньше достаточно было реализовать IController только. ControllerBase нужен только для того, чтобы методы вызывать без префикса-имени класса. А, как уже писал выше в C# новой версии это не нужно, поэтому и потребность в базовом классе отпала, а да и в каком либо интерфейсе.
A>Не расслышал — вы говорите, всё ещё надо классы писать или мне показалось?
Только как средство группирования методов. Другого пока не придумали в C#. Важно что не используется наследование, полиморфизм и композиция объектов. Даже identity таким объектам не нужен.
Re[13]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Какие использовались соглашения: G>>1) Имя класса контроллера заканчивается на Controller G>>2) Action возвращает ActionResult (хотя может возвращать что угодно, главное не void) G>>Что из них проверяется компилятором? Внезапно ничего.
D>Если так, то может быть. Но у меня кроме Index() обычно ещё куча всяких вспомогательных методов в контроллере (проверка прав, например; а в случае REST-двигла там вообще развесистый template method), и наследование начинает рулить со страшной силой: code completion, защита от опечаток и т.п.
Для этого фильтры есть, зачем тебе наследование? Или this.UpdateModel(model,form) лучше, чем ModelBinder.UpdateModel(model,form)? Особенно в случае, когда ни this., ни ModelBinder. можно не писать.
D>В этой связи я когда-то высказывался (в теме, называвшейся что-то типа "что вам не нравится в языках, на которых вы пишете") про жаву, что ейные фреймворки целиком на POJO+аннотациях вместо наследования — уничтожают саму идею статики.
Надо по ситуации смотреть, не всегда есть смысл в наследовании от базовых классов. Например в asp.net 5 его нет.
Re[4]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, Sinix, Вы писали:
S>Для явы — . Она по-моему безнадёжно пропитана паттернами.
В силу своей убогости. Тут даже уместно будет [в целом спорное] утверждение, что паттерн — это поименованный и узаконенный костыль. Отсутствие ФВП фиксим костылём под названием "стратегия". Отсутствие вложенных функций — объектной декомпозицией и приватными методами. Мне тут один джавер на днях выкатил претензию — мол в моей реализации тестового задания слишком глубокая вложенность. МакКоннелом тряс. Ага, давайте лучше контракт класса засрём, даже если и приватными методами — размазанную на сотню маленьких методов логику ему видимо проще читать, чем в одном месте. А на МакКоннела нехай молодняк маструбирует, находящийся на стадии "никогда не делайте то-то"
Здравствуйте, dimgel, Вы писали:
D>Если так, то может быть. Но у меня кроме Index() обычно ещё куча всяких вспомогательных методов
Так соглашения по именованию не отменяют наследования, можно писать и в старом стиле.
D>ейные фреймворки целиком на POJO+аннотациях вместо наследования — уничтожают саму идею статики.
Пока от статики "избавились" только там, где она и так особой роли не играла, это просто сахар для DI. Скорее наоборот, ошибок будет меньше: с рослином гораздо проще добавить проверки, которые нарушения соглашений будут ловить на лету, при написании кода.
Re[13]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
A>>>Есть объектно-ориентированный дизайн, а есть средства для его реализации. Наличие классов/объектов на уровне языка совершенно не означает, что любая программа на этом языке будет ОО. G>>Прекрасный вывод, но кажется полдня назад ты утверждал что G>>
A>>>всё что вы перечислили нужно писать в каких-то методах, а методы — в каких-то классах. И где-то в этой точке одновременно появляются паттерны
A>Если есть какое-то противоречие, я его не вижу. Давайте по-другому попробую. Если язык говорит, что через конструкцию "class XXX { ... }" можно описывать ООПшные классы, это: A>1. во-первых не означает, что ООПшные классы нужно описывать именно этой конструкцией A>2. во-вторых не означает, что этой конструкцией можно описывать только ООПшные классы
Логическую нестыковку выделил. В процитированном фрагменте был смысл что нужно писать классы и они являются априори ООП (что на самом деле не так).
Какое будет финальное мнение?
A>Т.е. если кто-то пишет на Haskell, в котором не классов, и у него нет проблем, всем нужно всё бросить и переходить на Haskell?
Нет, это ишь говорит, что в аскеле достаточно средств, чтобы писать код и не использовать ООП.
A>Есть ещё другие люди — они пишут на C#, в котором есть классы, и у них тоже нет проблем. Всем нужно всё бросить и переходить на C#?
Это еще не значит, что используют ООП.
A>Абсолютно пофигу, если кто-то счастлив работать с инструментами, которые сильно отличаются от моих или ваших. У людей разная мотивация: кто-то "работает программистом", кто-то любит "программирование", а кто-то любит "делать всякие штуки". Первому, очевидно, вообще всё пофигу — лишь бы не уволили. Второй наизусть помнит все задачки из SICP. Третий с большей радостью сделает какой-то новый недопродукт и заставит людей на него смотреть, чем будет вспоминать что делает этот кусок на Scheme, который ещё 10 минут назад казался абсолютно понятным.
К чему эта фраза? Увести разговор от обсуждения пользы паттернов и ООП в современных языках?
G>>ЗЫ. Кстати в книге pragmatic programmer, о которой я выше писал, рекомендуется изучать по одному языку в год. A>Это одна из моих всею душою любимых книг.
и тем не менее
A>изучением миллионов языков я уже переболел
Re[14]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Для этого фильтры есть, зачем тебе наследование? Или this.UpdateModel(model,form) лучше, чем ModelBinder.UpdateModel(model,form)? Особенно в случае, когда ни this., ни ModelBinder. можно не писать.
ХЗ что такое фильтры, но подозреваю, это что-то C#-specific, а у меня скала. В шарпе есть какая-то мулька, аналогичная скаловским implicits, но я всё время забываю, как она называется (ты её уже упоминал в этой ветке). Но implicits я не люблю: нагрузка на компилятор и запутывание кода. Хотя для пущей красивости DSL-ей иногда приходится.
Re[14]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Для этого фильтры есть, зачем тебе наследование?
Кроме того, наследование (особенно template method, конкретно мною сделанный и полностью меня устраивающий) помогает структурировать мозги и код. А ещё по нему проще понять, что ожидается от реализации, чем от расположенных хрен знает где (и скорее всего даже не в одном месте, если среди них есть и библиотечные, и app-specific) третьих методов, пользы от которых для читаемости и обучения ничуть не больше, чем от жавовских аннотаций.
UPD. Т.е. слабая связность имеет и свои обратные стороны (которые, кстати, тут неоднократно упоминались в контексте DI-фреймворков): когда код вообще ни хрена не связан, концы вообще хрен найдёшь.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Для этого фильтры есть, зачем тебе наследование? Или this.UpdateModel(model,form) лучше, чем ModelBinder.UpdateModel(model,form)? Особенно в случае, когда ни this., ни ModelBinder. можно не писать.
D>ХЗ что такое фильтры, но подозреваю, это что-то C#-specific, а у меня скала.
Ничего там C#-specific нет, просто набор объектов-обработчиков (паттерн chain of responsibility). При желании можно навешивать в виде атрибутов на классы\методы (для большей гранулярности)
D>В шарпе есть какая-то мулька, аналогичная скаловским implicits, но я всё время забываю, как она называется (ты её уже упоминал в этой ветке).
Extension methods называется.
D>Но implicits я не люблю: нагрузка на компилятор и запутывание кода. Хотя для пущей красивости DSL-ей иногда приходится.
По этому поводу есть рекомендации в FDG для C#.
Re[16]: Паттерны/идиомы/стереотипы ООП/ООД кроме GoF и PoEAA
Здравствуйте, gandjustas, Вы писали:
G>Extension methods называется.
Угу, они самые.
G>По этому поводу есть рекомендации в FDG для C#.
Англичанин русскому: с моста прыгать нельзя!
Русский: да плевал я на ваши запреты!
UPD. Я имею в виду, что нету у меня желания забивать голову чтивом в таком объёме, который ты осилил за сравнительно короткий срок, превратившись в тутошнего гуру (ну или активно претендуя на ). Я всю жизнь на позициях простого девелопера, вечное пиши-код-[beep].рф (сайтец кстати давно заблокировали), и привык проверять всё своим собственным лбом. Долго, но интересно. И очень надёжно.
D>Здравствуйте, gandjustas, Вы писали:
G>>Для этого фильтры есть, зачем тебе наследование?
Короче говоря, зачем мне фильтры, если есть наследование. У меня вообще складывается ощущение, что тут многие ненавидят ООП просто за то, что вот они его любили, а оно их разочаровало: оказалось не серебрянной пулей, а просто одним из паттернов. И они теперь принципиально не юзают его вообще нигде, даже там, где оно вполне нормально ложится.
. Она по-моему безнадёжно пропитана паттернами.
