И в NH и в EF, есть чисто идеологические проблемы. Ясен байт Орен нахваливает NH и заводит свою любимую песню о том, что MS не учитывает опыт накопленый сообществом (он ноет по этому поводу уже года два), подразумевая «почему они не взяли мой NH». Но зачем нужен второй NH? Один уже есть. С другой стороны EF тоже не идеал, они таки делают еще один ORM, точно такой же, но другой.
Мне очень нравилось как это начиналось, но… Впрочем история построения ORM в MS весьма богата, напомню в краце основные вехи:
Давным давно, еще до выхода FW 1.1 на конференции PDC 2003, традиционно проходящей в Лос-Анжелесе, MS официально объявил о начале работ над технологией взаимодействия с данными под официальным названием «ObjecSpaces». Суть в том, что команда OS нашла фатальный недостаток в существующих ORM (их придумали не они), и решила этот недостаток устранить. Ну, поскольку дело хорошее, то с песнями и плясками приступили, и на вышеупомянутом PDC был предложен даже некий прототип… Но что-то пошло не так, что именно сейчас уже дело темное, и спустя какое-то время проект был заморожен. Тем временем, активно шли работы над другим забавным проектом, под названием WinFS — грубо говоря, это должна была быть объектная файловая система, причем данные должны были лежать в SQLServer-е. Очевидно при таком сценарии без ORM никуда вот и команда ObjectSpaces быстро нашла фатальный недостаток в их системе мапинга (ее придумали не они) и дружно влилась в стройные ряды WinFS team (причем предполагалось, что ObjecSpaces будет поставляться вместе с WinFS в качестве библиотеки). Но, что-то пошло не так, сейчас уже дело темное, и проект WinFS оказался заморожен. Тем временем, в светлую голову Эрика Мейера, пришла идея LINQ и он сумел вложить ее в головы Коробкина, Хайлсберга и других талантливых ребят из MS, и они начали ее продвигать и разрабатывать. Ясен байт, что подсистема LINQ-а, отвечающая за работу с RDBMS практически ORM (тогда она называлась DLINQ) и команда OS не смогла устоять перед искушением, нашла, по привычной схеме, фатальный недостаток и занялась рализацией DLINQ. В этот момент я, признаюсь, стал тревожится за успех этого во всех отношениях достойного мероприятия.
Далее случился гениальный ход, DLINQ трансформировался в LINQ2SQL, и образовался еще один проект — EF (тяжелый ORM для «серьезных» задач), куда и перешла команда ObjectSpase. После этого LINQ2SQL зарелизился практически в срок, а выход EF отложили на год-полтора…
Я уже было вздохнул спокойно, но тут произошла досадная фигня — LINQ2SQL остался без хозяина, его разрабатывала часть команды компилятора шарпа и дальше его поддерживать им было не с руки. Какое то время этот проект помыкался бесхозным, его пытались всучить команде MS SQL и в итоге его приписали к команде EF, где и сгнобили по тихому, пообещав реализовать его функционал в рамках EF.
А между делом, таки да, свершилось чудо и EF вышел. Правда первая версия была совсем сырая и к продакшену не пригодная, но ее просто нужно было выпускать. Сейчас вроде по лучше, но идеология там все-таки не для легковесных ORM, да и косяков по прежнему много.
Из того, чем можно пользоваться сейчас:
1. NH — меня он не устраивает по идеологическим причинам и в силу своей тяжеловестности. Да, я знаю, я все знаю. Орен действительно прав, за долгие годы существования этого продукта, его таки вылизали до невозможного состояния и действительно смогли сделать достаточно гибким, чтобы им можно было пользоваться практически как угодно. Но за это же время он оброс кучей всякого хлама и использовать его правильно сильно сложнее, чем неправильно. Начинающему разработчику, в серьезном проекте, без присмотра старших — строго не рекомендуется.
2. EF — все еще сырой, идеологические косяки те же что и в NH, да еще и не достаточно гибкий, так как изначальная архитектура еще ObjectSpase в нем до сих пор ощущается. Задумка в самом начале была не плоха, при условии ориентации этого продукта на достаточно узкий класс задач, но когда из него попытались сделать универсальный инструмент, получилась какая-то фигня.
3. Linq2SQL — так как делалася талантливыми дядьками, четко представляющими, что они хотят получить в конечном итоге, и не замахивающимися на универсальные всемогутеры, то получился отличный инструмент, с правильной идеологией. Вообще, удивительный факт — первый и единственный релиз оказался на столько удачным, что им можно пользоваться в продакшене до сих пор. Что я с удовольствием и делаю в нескольких проектах. Очень жаль, что MS не стал развивать его как отдельный продукт.
4. На мой взгляд, лучшим на данный момент ORM подобным инструментом является BLToolKit (http://bltoolkit.net). Это то, каким должен был бы быть LINQ2SQL, если бы MS его не забросил. Отличительные особенности:
— правильная идеология (ORM не делает ничего лишнего и не пытается защитить хрупкий мозг разработчика от БД, а просто избавляет его от рутинной работы)
— отличная поддержка LINQ
— поддержка около 20 различных СУБД
— это самый быстрый ORM на данный момент (того же NH на некоторых задачах рвет в десятки раз)
— в ближайшее время должен появиться (если еще не.) LINQ DML. Вот это вообще мегафича.
Я ответил на конретную претензию про исходники. Меня мало волнует, что вы там считаете открытым «по человечески», а что нет.
И да, я примерно представляю, кто здесь извращает понятие OSS. =)
Исходники .Net берутся на сайте MS. Вплоть до того, что следующий R# будет вытаскивать их с сайта и подкладывает рядом, если нужно по ним подебажиться.
Rotor — был доступен еще с версии .Net 1.0
Увы, но это практически не реально. ((
Дело в том, что любой полноценный солюшен — это не только шарповский проект, но еще и всякая дополнительная фигня, типа asp.Net-а, DB проектов, тестов, разных MVC, WPF, WF, WCF, офиса, сервилада, диаграм и еще байт знает какой лабуды, включая поддержку других языков, так как и смешанные проекты тоже не редкость. И чтобы пользовались новой IDE, она должна все это поддерживать иначе она будет никому не нужна. Масштабы такого проекта переоценить сложно.
Если кто не в курсе, MS в свое время тоже не потянул создание альтернативной студии. Код текущей VS тянется с середины девяностых, и в районе появления 05 студии было принято решение попробовать написать все заново. Ядро студии назвалось проект Nautilus, а сама студия имела кодовое название Гаваи — это то, что должна была представлять из себя VS 2010.
Но в итоге, в районе 08-года проект закрыли и из всего, что было в гаваях, в 2010-й студии только редактор, ну и еще кое что по мелочи…
Я, конечно, верю в ребят из JB, но боюсь, что проект просто не окупится.
>К сожалению, про ту практику, «которую я даю» Вы категорично судите, имея
>о ней лишь отдалённое представление, почерпнутое из вступительных лекций
Естественно. Более того, я сужу не о практике, а именно о лекциях — лекции на институтские не тянут ни при каком раскладе, уж извините.
Что же касается практики, то Вы о ней сами заговорили, напирая на то, что Вы исключительно практик, но вот как раз практики я здесь-то и не увидел.
> Если не секрет, какой курс читаете? Мне, действительно интересно.
Базы данных.
>О какой практике?
О той, которую Вы даете.
>Если в вашей компании удобнее брать людей, не знающих, что такое абстрактная фабрика, стратегия
>или декоратор, то либо я неправильно понимаю направление вашей деятельности, либо у вас
>достаточно времени и бюджета, чтобы этому обучать по ходу работы, на «живых» продуктах.
Да, совершенно верно, от стажера нам ни разу не нужны знания об абстрактной фабрике, стратегии, декораторе, упаси байт, синглтоне или визиторе. Лучше, если у него их нет. За три месяца испытательного срока мы все равно научим его здесь лучше, чем в любом ВУЗе, и так как надо нам. Направление нашей деятельности — производство коробочного софта.
>Моя задача — познакомить их с применением этого ООП на практике. В наиболее распространённых
>случаях. Т.е. показать, что такое паттерны проектирования и как ими пользоваться. Для этого мне
>надо напомнить основные принципы. Именно напомнить.
Тогда я вообще не понимаю, зачем рассказы про машинки. Они рассчитаны на того, кто до этого ООП не знал вообще и дальше разбираться в нем особо не собирается.
> Если не секрет, какой курс читаете? Мне, действительно интересно.
Базы данных.
>О какой практике?
О той, которую Вы даете.
>Если в вашей компании удобнее брать людей, не знающих, что такое абстрактная фабрика, стратегия
>или декоратор, то либо я неправильно понимаю направление вашей деятельности, либо у вас
>достаточно времени и бюджета, чтобы этому обучать по ходу работы, на «живых» продуктах.
Да, совершенно верно, от стажера нам ни разу не нужны знания об абстрактной фабрике, стратегии, декораторе, упаси байт, синглтоне или визиторе. Лучше, если у него их нет. За три месяца испытательного срока мы все равно научим его здесь лучше, чем в любом ВУЗе, и так как надо нам. Направление нашей деятельности — производство коробочного софта.
>Моя задача — познакомить их с применением этого ООП на практике. В наиболее распространённых
>случаях. Т.е. показать, что такое паттерны проектирования и как ими пользоваться. Для этого мне
>надо напомнить основные принципы. Именно напомнить.
Тогда я вообще не понимаю, зачем рассказы про машинки. Они рассчитаны на того, кто до этого ООП не знал вообще и дальше разбираться в нем особо не собирается.
Вы наверное ВУЗ с техникумом или ПТУ перепутали, вот там действительно нужна суровая практика и ничего больше.
Помимо того, что я иногда преподаю, на основной работе я руковожу группой разработки в «фирме, которая занимается серьезной разработкой ПО», и в связи с этим могу рассмотреть ситуацию со всех сторон.
Так вот, мне, как практику, от стажера знания «си с классами» на уровне машинок, не только не нужны, но и вредны, потому что в этом случае его все равно приходится переучивать. Понимать ООП на таком уровне, я и сам в состоянии его обучить за пару недель. Собственно, ровно по этому у нас в компании, на начальные позиции, предпочитают брать вообще не имеющих никакой подготовки, чем обремененных знаниями о такой «практике».
В то же время сейчас бывает так, что мне, как практикующему разработчику с довольно серьезным опытом и не плохой квалификацией, тем не менее, не хватает теоретических знаний, которые мне могли бы дать в ВУЗе — приходится наверстывать. С другой стороны, не смотря на то, что моя специальность вообще теоретическая физика, и, казалось бы, теоретические знания о фуллереновых пленках и уравнении описывающим изменение состояния задаваемого волновой функцией в гамильтоновых квантовых системах, на практике мне не нужны, наверстывание это больших проблем не составляет, так как в ВУЗе мне преподавали не «практику», а учили обращаться с теорией. Как говорил нам один из преподавателей — «мы учим вас видеть за формулой процесс». Ваш же подход заставляет просто заучивать формулы, причем зачастую неверные.
Кроме того, я не понимаю этого противопоставления «теории» и «практики». CS одна из тех редких областей, где от теории до практики вообще полшага, все на расстоянии нескольких строк кода, как не понимая этого вообще можно преподавать? Доходчиво объяснить не только основные постулаты ООП, но и откуда у них растут ноги, займет не на много больше времени, чем рассказы о машинках. Собственно, непосредственно против машинок я ничего не имею, плохо то, что они являются основой на которой все строится, а не метафорой призванной лишь проиллюстрировать один из аспектов.
Да, преподаю. В ВУЗе.
То, что студенты учиться не хотят — это не проблема. Проблема в том, что даже если и хотят, то иллюстрациями на машинках знания по ООП до них не донесешь. По моему мнению, преподавание в ВУЗе должно вестись на совершенно другом уровне. Может быть мне повезло и в свое время я еще застал то, как это должно быть, на излете правда, но то как дают это сейчас вызывает только уныние.
Мда… Прямо ребятам о зверятах. И это рассказывают в ВУЗе? На профильном предмете?
Я понимаю, если бы это был факультатив для старшеклассников, но для вуза это вообще не серьезно.
И полиморфизм, и инкапсуляция отлично живут и без ООП и классов, и давать эти определения на основе ООП-шных классов — это все равно, что, ну не знаю, производные без пределов рассказывать, это как заклинание зазубрить. Это для вуза? При этом сухие формальные определения, в данном случае, гораздо понятнее, чем наглядные метафоры вокруг автомобиля.
Полиморфная переменная, это переменная, которая может принимать значения разных типов. Все, дальше весь полиморфизм строится на этом определении:
Полиморфная функция, это функция у которой хотя бы один аргумент является полиморфной переменной.
Выделяют два вида полиморфных функций:
— ad hoc, функция ведет себя по разному для разных типов аргументов, например, функция Draw — рисует по разному фигуры разных типов.
— параметрический, функция ведет себя одинаково для аргументов разных типов, например, функция Add — одинаково кладет в контейнер элементы разных типов.
И это все не имеет никакого отношения к классам и ООП.
Если язык не оборудован поддержкой полиморфизма, то такой полиморфизм называется искуственным, пример — Си-шная функция printf — информация о типах аргументов пропихивается отдельным параметром. Если же язык обородован такой поддержкой, то полиморфизм считается естественным, пример — неявный аргумент this в том же C++.
Вот здесь уже можно начинать рассказывать про ООП, и есть повод объяснить, что наследование в статически типизированных ООП языках появилось именно для поддержки полиморфизма и не забыть упомянуть про наследование контрактов и реализаций.
С инкапсуляцией та же история…
А так можно вырастить только специалистов по «Си с классами», а не людей понимающих что такое ООП и чего от него ждать.
криво парсит html
— подсвечивает как ошибку Conditional comments, я эту багу в трекере еще полгода назад заводил. Да и вообще пытается парсить комментарии и естественно что-то там находит не то.
— некоторые теги парсит некорректно, например <img align=«absmiddle»… подсвечивает как ошибку.
Причем пока что от билда к билду все хуже. На одном и том же проекте находятся все больше и больше ошибок, которые на самом деле не ошибки.
Может вообще html-ные ошибки как варнинги трактовать?
Вообще, ситуация в студии лично меня немного удручает…
Ситуация такова, что действительно эффективно работать в студии, можно только при наличии решарпера и ряда подобных инструментов. И это нормально, это правильно.
Проблема в том, что даже идеально написанный тул, типа решарпера, ужасно сложно интегрировать в студию, чтобы он еще при этом и эффективно работал… Кто не верит, может попробовать поставить CodeRush — на тех проектах, где решарпер еще ведет себя довольно приемлимо (пара десятков мегабайт исходников), CR перестает подавать признаки жизни, но речь не о том.
Речь о том, что в этой ситуации в MS принимается решение реализовать в студии то, что уже есть в R#. Этим занимается две команды на редкость талантливых людей, реально серьезных товарищей, без дураков. Одна команда делает рефакторинги, вторая compiler as service.
Что мы ждем от compiler as service? Лично мне эта штука интересна в качестве инструмента для метапрограммирования, для того чтобы вклинится в пайплайн компилятора и поменять на лету AST. Но эту фичу не дадут, а все примеры использования ориентированы на то, как полазить по исходному коду и поделать рефакторинг. Кто-то собирается делать собственные рефакторинги для студии? Если кто и собирается, то у того же R# есть уже готовая инфраструктура, включая механизм плагинов, а без инфраструктуры это вообще мало кому интересно.
И так, что мы имеем.
MS в IDE занимается тем, что лечит симптомы вместо болезни. Примерно к 12-й версии VS мы получим в студии функционал, который уже сейчас есть в тулах типа решарпера. И на это уйдут ресурсы в количестве двух команд по пару десятков человек в каждой в течении 3-4 лет. Причем, повторюсь, не абы кого, а реально крутых товарищей, я знаю, я проверял. И это вместо того, чтобы отправить этих товарищий на вылизывание API и SDK студии таким образом, чтобы плагины типа решарпера не тормозили и не состояли процентов на пятьдесят из обхода косяков студии. Или такой факт, вы знаете, например, что одна из основных причин бедности C# 4 на фичи заключается в том, что у команды студии не хватило ресурсов эти фичи поддержать у себя? И в такой ситуации большое количество ресурсов бросается на реализацию того, что и так уже есть.
Да, я понимаю, это очень популярное решение — все хотят решарпер нахаляву… Но это решение очень не дальновидное. Это еще больше отодвинет появление нормальной студии. Разработчики из MS огребут ровно те же самые проблемы, что сейчас ребята из JB и их решение не будет сильно быстрее или качественнее, скорее наоборот… Кроме того, это подкосит рынок плагинов — кто захочит писать хороший плагин к студии, если через некоторое время придет MS и напишет точно такой же плагин, но другой?
Прошу прощения за поток сознания, я просто под впечатлением, наболело…
P. S.
Я не имею никакого отношения к JetBrains вообще и к решарперу в частности… :)
На самом деле R#5 сам по себе существенно быстрее предыдущих версий. Проблема в новой студии, новом редакторе и старых студийных болячках. В каких-то местах студию существенно улучшили, а в каких-то она наоборот стала просто чудовищьно тормозить. Переход на WPF заставил вылизать остальной код, но так как основные тормоза по прежнему в редакторе, то сильно это делу не помогло.
Ну и плюс, кривой студийный API — без слез не взглянешь… Ну это все разговоры в пользу бедных.
На данный момент важно одно — те бенефиты которые я получаю от использования R# настолько превышают дискомфорт от чуть более чем обычно тормозящей студии, что я полюбому голосую за решарпер.
Это альтернатива. Альтернативой созданию себе трудностей собственными руками, является не создавание себе трудностей. Хорошо, переформулирую свою мысль — «делай не DDD».
По признанию самого Фаулера, область применения Rich Dmain Model — очень узка, по моим наблюдениям, ее не видно и в микроскоп, но в последнее время складывается впечатление, что как только девелопер открывает книжку про DDD, мозг у него отключается. Народ начинает писать строго следуя тому, что завещал великий (Фаулер/ Эванс/Нильсен — нужное подчеркнуть), а потом мужественно борется с последствиями и на выходе получаются такие вот фреймворки по снижению негативного влияния других фреймворков.
Поэтому, прежде чем влезать в DDD надо задать себе вопрос «а зачем?», «какую проблему я решаю, применяя здесь DDD, Rich Domain и прочие околоархитектурные изыски?». Такой вопрос в принципе неплохо бы себе по чаще задавать…
Есть еще более правильный путь — понять, что стоит за DDD, и при разработке пользоваться базовыми принципами. И если следуя этоим базовым принципам, таки получилось что-то похожее на DDD, значит в этом проекте действительно должно быть DDD, но вот если DDD не срастается — значит не судьба. В этом случае, необходимость в подобных автомаперах сильно уменьшится, а код будет проще, понятнее и его будет легче сопровождать и расширять, проверено на людях.
Скажем, загрузка шарпных проектов стала быстрее раза в два.
Мне очень нравилось как это начиналось, но… Впрочем история построения ORM в MS весьма богата, напомню в краце основные вехи:
Давным давно, еще до выхода FW 1.1 на конференции PDC 2003, традиционно проходящей в Лос-Анжелесе, MS официально объявил о начале работ над технологией взаимодействия с данными под официальным названием «ObjecSpaces». Суть в том, что команда OS нашла фатальный недостаток в существующих ORM (их придумали не они), и решила этот недостаток устранить. Ну, поскольку дело хорошее, то с песнями и плясками приступили, и на вышеупомянутом PDC был предложен даже некий прототип… Но что-то пошло не так, что именно сейчас уже дело темное, и спустя какое-то время проект был заморожен. Тем временем, активно шли работы над другим забавным проектом, под названием WinFS — грубо говоря, это должна была быть объектная файловая система, причем данные должны были лежать в SQLServer-е. Очевидно при таком сценарии без ORM никуда вот и команда ObjectSpaces быстро нашла фатальный недостаток в их системе мапинга (ее придумали не они) и дружно влилась в стройные ряды WinFS team (причем предполагалось, что ObjecSpaces будет поставляться вместе с WinFS в качестве библиотеки). Но, что-то пошло не так, сейчас уже дело темное, и проект WinFS оказался заморожен. Тем временем, в светлую голову Эрика Мейера, пришла идея LINQ и он сумел вложить ее в головы Коробкина, Хайлсберга и других талантливых ребят из MS, и они начали ее продвигать и разрабатывать. Ясен байт, что подсистема LINQ-а, отвечающая за работу с RDBMS практически ORM (тогда она называлась DLINQ) и команда OS не смогла устоять перед искушением, нашла, по привычной схеме, фатальный недостаток и занялась рализацией DLINQ. В этот момент я, признаюсь, стал тревожится за успех этого во всех отношениях достойного мероприятия.
Далее случился гениальный ход, DLINQ трансформировался в LINQ2SQL, и образовался еще один проект — EF (тяжелый ORM для «серьезных» задач), куда и перешла команда ObjectSpase. После этого LINQ2SQL зарелизился практически в срок, а выход EF отложили на год-полтора…
Я уже было вздохнул спокойно, но тут произошла досадная фигня — LINQ2SQL остался без хозяина, его разрабатывала часть команды компилятора шарпа и дальше его поддерживать им было не с руки. Какое то время этот проект помыкался бесхозным, его пытались всучить команде MS SQL и в итоге его приписали к команде EF, где и сгнобили по тихому, пообещав реализовать его функционал в рамках EF.
А между делом, таки да, свершилось чудо и EF вышел. Правда первая версия была совсем сырая и к продакшену не пригодная, но ее просто нужно было выпускать. Сейчас вроде по лучше, но идеология там все-таки не для легковесных ORM, да и косяков по прежнему много.
Из того, чем можно пользоваться сейчас:
1. NH — меня он не устраивает по идеологическим причинам и в силу своей тяжеловестности. Да, я знаю, я все знаю. Орен действительно прав, за долгие годы существования этого продукта, его таки вылизали до невозможного состояния и действительно смогли сделать достаточно гибким, чтобы им можно было пользоваться практически как угодно. Но за это же время он оброс кучей всякого хлама и использовать его правильно сильно сложнее, чем неправильно. Начинающему разработчику, в серьезном проекте, без присмотра старших — строго не рекомендуется.
2. EF — все еще сырой, идеологические косяки те же что и в NH, да еще и не достаточно гибкий, так как изначальная архитектура еще ObjectSpase в нем до сих пор ощущается. Задумка в самом начале была не плоха, при условии ориентации этого продукта на достаточно узкий класс задач, но когда из него попытались сделать универсальный инструмент, получилась какая-то фигня.
3. Linq2SQL — так как делалася талантливыми дядьками, четко представляющими, что они хотят получить в конечном итоге, и не замахивающимися на универсальные всемогутеры, то получился отличный инструмент, с правильной идеологией. Вообще, удивительный факт — первый и единственный релиз оказался на столько удачным, что им можно пользоваться в продакшене до сих пор. Что я с удовольствием и делаю в нескольких проектах. Очень жаль, что MS не стал развивать его как отдельный продукт.
4. На мой взгляд, лучшим на данный момент ORM подобным инструментом является BLToolKit (http://bltoolkit.net). Это то, каким должен был бы быть LINQ2SQL, если бы MS его не забросил. Отличительные особенности:
— правильная идеология (ORM не делает ничего лишнего и не пытается защитить хрупкий мозг разработчика от БД, а просто избавляет его от рутинной работы)
— отличная поддержка LINQ
— поддержка около 20 различных СУБД
— это самый быстрый ORM на данный момент (того же NH на некоторых задачах рвет в десятки раз)
— в ближайшее время должен появиться (если еще не.) LINQ DML. Вот это вообще мегафича.
И да, я примерно представляю, кто здесь извращает понятие OSS. =)
Rotor — был доступен еще с версии .Net 1.0
Дело в том, что любой полноценный солюшен — это не только шарповский проект, но еще и всякая дополнительная фигня, типа asp.Net-а, DB проектов, тестов, разных MVC, WPF, WF, WCF, офиса, сервилада, диаграм и еще байт знает какой лабуды, включая поддержку других языков, так как и смешанные проекты тоже не редкость. И чтобы пользовались новой IDE, она должна все это поддерживать иначе она будет никому не нужна. Масштабы такого проекта переоценить сложно.
Если кто не в курсе, MS в свое время тоже не потянул создание альтернативной студии. Код текущей VS тянется с середины девяностых, и в районе появления 05 студии было принято решение попробовать написать все заново. Ядро студии назвалось проект Nautilus, а сама студия имела кодовое название Гаваи — это то, что должна была представлять из себя VS 2010.
Но в итоге, в районе 08-года проект закрыли и из всего, что было в гаваях, в 2010-й студии только редактор, ну и еще кое что по мелочи…
Я, конечно, верю в ребят из JB, но боюсь, что проект просто не окупится.
>о ней лишь отдалённое представление, почерпнутое из вступительных лекций
Естественно. Более того, я сужу не о практике, а именно о лекциях — лекции на институтские не тянут ни при каком раскладе, уж извините.
Что же касается практики, то Вы о ней сами заговорили, напирая на то, что Вы исключительно практик, но вот как раз практики я здесь-то и не увидел.
Базы данных.
>О какой практике?
О той, которую Вы даете.
>Если в вашей компании удобнее брать людей, не знающих, что такое абстрактная фабрика, стратегия
>или декоратор, то либо я неправильно понимаю направление вашей деятельности, либо у вас
>достаточно времени и бюджета, чтобы этому обучать по ходу работы, на «живых» продуктах.
Да, совершенно верно, от стажера нам ни разу не нужны знания об абстрактной фабрике, стратегии, декораторе, упаси байт, синглтоне или визиторе. Лучше, если у него их нет. За три месяца испытательного срока мы все равно научим его здесь лучше, чем в любом ВУЗе, и так как надо нам. Направление нашей деятельности — производство коробочного софта.
>Моя задача — познакомить их с применением этого ООП на практике. В наиболее распространённых
>случаях. Т.е. показать, что такое паттерны проектирования и как ими пользоваться. Для этого мне
>надо напомнить основные принципы. Именно напомнить.
Тогда я вообще не понимаю, зачем рассказы про машинки. Они рассчитаны на того, кто до этого ООП не знал вообще и дальше разбираться в нем особо не собирается.
Базы данных.
>О какой практике?
О той, которую Вы даете.
>Если в вашей компании удобнее брать людей, не знающих, что такое абстрактная фабрика, стратегия
>или декоратор, то либо я неправильно понимаю направление вашей деятельности, либо у вас
>достаточно времени и бюджета, чтобы этому обучать по ходу работы, на «живых» продуктах.
Да, совершенно верно, от стажера нам ни разу не нужны знания об абстрактной фабрике, стратегии, декораторе, упаси байт, синглтоне или визиторе. Лучше, если у него их нет. За три месяца испытательного срока мы все равно научим его здесь лучше, чем в любом ВУЗе, и так как надо нам. Направление нашей деятельности — производство коробочного софта.
>Моя задача — познакомить их с применением этого ООП на практике. В наиболее распространённых
>случаях. Т.е. показать, что такое паттерны проектирования и как ими пользоваться. Для этого мне
>надо напомнить основные принципы. Именно напомнить.
Тогда я вообще не понимаю, зачем рассказы про машинки. Они рассчитаны на того, кто до этого ООП не знал вообще и дальше разбираться в нем особо не собирается.
Помимо того, что я иногда преподаю, на основной работе я руковожу группой разработки в «фирме, которая занимается серьезной разработкой ПО», и в связи с этим могу рассмотреть ситуацию со всех сторон.
Так вот, мне, как практику, от стажера знания «си с классами» на уровне машинок, не только не нужны, но и вредны, потому что в этом случае его все равно приходится переучивать. Понимать ООП на таком уровне, я и сам в состоянии его обучить за пару недель. Собственно, ровно по этому у нас в компании, на начальные позиции, предпочитают брать вообще не имеющих никакой подготовки, чем обремененных знаниями о такой «практике».
В то же время сейчас бывает так, что мне, как практикующему разработчику с довольно серьезным опытом и не плохой квалификацией, тем не менее, не хватает теоретических знаний, которые мне могли бы дать в ВУЗе — приходится наверстывать. С другой стороны, не смотря на то, что моя специальность вообще теоретическая физика, и, казалось бы, теоретические знания о фуллереновых пленках и уравнении описывающим изменение состояния задаваемого волновой функцией в гамильтоновых квантовых системах, на практике мне не нужны, наверстывание это больших проблем не составляет, так как в ВУЗе мне преподавали не «практику», а учили обращаться с теорией. Как говорил нам один из преподавателей — «мы учим вас видеть за формулой процесс». Ваш же подход заставляет просто заучивать формулы, причем зачастую неверные.
Кроме того, я не понимаю этого противопоставления «теории» и «практики». CS одна из тех редких областей, где от теории до практики вообще полшага, все на расстоянии нескольких строк кода, как не понимая этого вообще можно преподавать? Доходчиво объяснить не только основные постулаты ООП, но и откуда у них растут ноги, займет не на много больше времени, чем рассказы о машинках. Собственно, непосредственно против машинок я ничего не имею, плохо то, что они являются основой на которой все строится, а не метафорой призванной лишь проиллюстрировать один из аспектов.
То, что студенты учиться не хотят — это не проблема. Проблема в том, что даже если и хотят, то иллюстрациями на машинках знания по ООП до них не донесешь. По моему мнению, преподавание в ВУЗе должно вестись на совершенно другом уровне. Может быть мне повезло и в свое время я еще застал то, как это должно быть, на излете правда, но то как дают это сейчас вызывает только уныние.
Я понимаю, если бы это был факультатив для старшеклассников, но для вуза это вообще не серьезно.
И полиморфизм, и инкапсуляция отлично живут и без ООП и классов, и давать эти определения на основе ООП-шных классов — это все равно, что, ну не знаю, производные без пределов рассказывать, это как заклинание зазубрить. Это для вуза? При этом сухие формальные определения, в данном случае, гораздо понятнее, чем наглядные метафоры вокруг автомобиля.
Полиморфная переменная, это переменная, которая может принимать значения разных типов. Все, дальше весь полиморфизм строится на этом определении:
Полиморфная функция, это функция у которой хотя бы один аргумент является полиморфной переменной.
Выделяют два вида полиморфных функций:
— ad hoc, функция ведет себя по разному для разных типов аргументов, например, функция Draw — рисует по разному фигуры разных типов.
— параметрический, функция ведет себя одинаково для аргументов разных типов, например, функция Add — одинаково кладет в контейнер элементы разных типов.
И это все не имеет никакого отношения к классам и ООП.
Если язык не оборудован поддержкой полиморфизма, то такой полиморфизм называется искуственным, пример — Си-шная функция printf — информация о типах аргументов пропихивается отдельным параметром. Если же язык обородован такой поддержкой, то полиморфизм считается естественным, пример — неявный аргумент this в том же C++.
Вот здесь уже можно начинать рассказывать про ООП, и есть повод объяснить, что наследование в статически типизированных ООП языках появилось именно для поддержки полиморфизма и не забыть упомянуть про наследование контрактов и реализаций.
С инкапсуляцией та же история…
А так можно вырастить только специалистов по «Си с классами», а не людей понимающих что такое ООП и чего от него ждать.
Только вот на практике, очевидцы утверждают, что работать в них не очень комфортно…
— подсвечивает как ошибку Conditional comments, я эту багу в трекере еще полгода назад заводил. Да и вообще пытается парсить комментарии и естественно что-то там находит не то.
— некоторые теги парсит некорректно, например <img align=«absmiddle»… подсвечивает как ошибку.
Причем пока что от билда к билду все хуже. На одном и том же проекте находятся все больше и больше ошибок, которые на самом деле не ошибки.
Может вообще html-ные ошибки как варнинги трактовать?
Ситуация такова, что действительно эффективно работать в студии, можно только при наличии решарпера и ряда подобных инструментов. И это нормально, это правильно.
Проблема в том, что даже идеально написанный тул, типа решарпера, ужасно сложно интегрировать в студию, чтобы он еще при этом и эффективно работал… Кто не верит, может попробовать поставить CodeRush — на тех проектах, где решарпер еще ведет себя довольно приемлимо (пара десятков мегабайт исходников), CR перестает подавать признаки жизни, но речь не о том.
Речь о том, что в этой ситуации в MS принимается решение реализовать в студии то, что уже есть в R#. Этим занимается две команды на редкость талантливых людей, реально серьезных товарищей, без дураков. Одна команда делает рефакторинги, вторая compiler as service.
Что мы ждем от compiler as service? Лично мне эта штука интересна в качестве инструмента для метапрограммирования, для того чтобы вклинится в пайплайн компилятора и поменять на лету AST. Но эту фичу не дадут, а все примеры использования ориентированы на то, как полазить по исходному коду и поделать рефакторинг. Кто-то собирается делать собственные рефакторинги для студии? Если кто и собирается, то у того же R# есть уже готовая инфраструктура, включая механизм плагинов, а без инфраструктуры это вообще мало кому интересно.
И так, что мы имеем.
MS в IDE занимается тем, что лечит симптомы вместо болезни. Примерно к 12-й версии VS мы получим в студии функционал, который уже сейчас есть в тулах типа решарпера. И на это уйдут ресурсы в количестве двух команд по пару десятков человек в каждой в течении 3-4 лет. Причем, повторюсь, не абы кого, а реально крутых товарищей, я знаю, я проверял. И это вместо того, чтобы отправить этих товарищий на вылизывание API и SDK студии таким образом, чтобы плагины типа решарпера не тормозили и не состояли процентов на пятьдесят из обхода косяков студии. Или такой факт, вы знаете, например, что одна из основных причин бедности C# 4 на фичи заключается в том, что у команды студии не хватило ресурсов эти фичи поддержать у себя? И в такой ситуации большое количество ресурсов бросается на реализацию того, что и так уже есть.
Да, я понимаю, это очень популярное решение — все хотят решарпер нахаляву… Но это решение очень не дальновидное. Это еще больше отодвинет появление нормальной студии. Разработчики из MS огребут ровно те же самые проблемы, что сейчас ребята из JB и их решение не будет сильно быстрее или качественнее, скорее наоборот… Кроме того, это подкосит рынок плагинов — кто захочит писать хороший плагин к студии, если через некоторое время придет MS и напишет точно такой же плагин, но другой?
Прошу прощения за поток сознания, я просто под впечатлением, наболело…
P. S.
Я не имею никакого отношения к JetBrains вообще и к решарперу в частности… :)
Ну и плюс, кривой студийный API — без слез не взглянешь… Ну это все разговоры в пользу бедных.
На данный момент важно одно — те бенефиты которые я получаю от использования R# настолько превышают дискомфорт от чуть более чем обычно тормозящей студии, что я полюбому голосую за решарпер.
По признанию самого Фаулера, область применения Rich Dmain Model — очень узка, по моим наблюдениям, ее не видно и в микроскоп, но в последнее время складывается впечатление, что как только девелопер открывает книжку про DDD, мозг у него отключается. Народ начинает писать строго следуя тому, что завещал великий (Фаулер/ Эванс/Нильсен — нужное подчеркнуть), а потом мужественно борется с последствиями и на выходе получаются такие вот фреймворки по снижению негативного влияния других фреймворков.
Поэтому, прежде чем влезать в DDD надо задать себе вопрос «а зачем?», «какую проблему я решаю, применяя здесь DDD, Rich Domain и прочие околоархитектурные изыски?». Такой вопрос в принципе неплохо бы себе по чаще задавать…
Есть еще более правильный путь — понять, что стоит за DDD, и при разработке пользоваться базовыми принципами. И если следуя этоим базовым принципам, таки получилось что-то похожее на DDD, значит в этом проекте действительно должно быть DDD, но вот если DDD не срастается — значит не судьба. В этом случае, необходимость в подобных автомаперах сильно уменьшится, а код будет проще, понятнее и его будет легче сопровождать и расширять, проверено на людях.