Книга по ООП для новичка, C#?

Question

[NBN]

Посоветуйте какую-нибудь хорошую книгу для новичка по ООП (C#), в которой всё было бы объяснено понятным языком с реальными примерами. Заранее спасибо!

Comments

[AtomKrieg]

в гугл не заглядывали?

[Сергей Протько]

Ринат Велиахмедов: а вы сможете после этой статьи сказать, чем ООП отличается от процедурного программирования, и вобще зачем оно надо?

Answer 1

[Oxoron]

Были уже подобные вопросы.
Тут мои ответы.
Рекомендую поглядеть на roadmap. По ней можно подбирать литературу после изучения C#.

Answer 2

[Tsiren Naimanov]

Джефри Рихтер
Эндрю Троелсен
их книги БИС

Comments

[Алексей Павлов]

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

[Сергей Протько]

что у Джефри Рихтер из книг чисто по ООП а не по .NET? Эндрю туда же.

[Tsiren Naimanov]

Алексей Павлов: я думаю что в этих книгах, предназначенных не для новичков, если выбрать ООП, конкретные темы, почитать и вдуматься в них, то это им поможет, если опустить IL / JIT и т д , если выжать из всей книги именно то что нужно, опираясь на главы, то и новичку это даст знания, а так жее ооп описаны на MSDN

[Tsiren Naimanov]

Сергей Протько: ООП, всегда и в любой книге будут описаны, но много уделять этому, не будут, да и не нужно, так как всё это понимается на уровне кода и практики

[Алексей Павлов]

Tsiren Naimanov: тем новички и отличаются от продвинутых, что они не умеют выделять важное и неважное. Поэтому, я считаю, что новичку неполезно читать эти книги. Тем более, что есть книги именно для новичков, начиная от Фленова.

[Tsiren Naimanov]

Алексей Павлов: новичкам, так лучше уж вообще просто тупо гуглить :3 ибо в гугле всё можно найти

[Алексей Павлов]

Tsiren Naimanov: но вопрос же от новичка, а не от профи. Поэтому я так и писал выше. А в гуглах слишком много фигни, поэтому люди и спрашивают совета, что лучше почитать.
Я сам преподаватель, учу студентов как раз C# (в основном), и я знаю, как новичку важно найти хорошую книгу.

[Сергей Протько]

Tsiren Naimanov: читая книги по .NET читатель не сможет разобраться что такое инкапсуляция. Даже если вскользь упомянут зачем это надо, фокус внимания читателя будет смещен на посторонние вещи.

Опять же, я могу судить по людям с которыми мне доводилось общаться, которые по причине того что читали только статьи/книги под какие-то фреймворки где что-то всего-лишь упоминалось вскользь (потому что автор книги предполагал что читатель уже ознакомлен с этими понятиями) лишены понимания того, почему все организовано так а не иначе. Допустим мой любимый пример когда люди не понимают в чем разница между инверсией зависимости и внедрением зависимостей. У людей эти понятия перемешаны.

По поводу "гуглить" - таки да, гуглить полезно. Но что гуглить - вот вопрос. Так же можно опять же случайно сместит фокус внимания на посторонние вещи (у меня так было с BDD помниться, потому что когда я о нем узнал из нагугленной статьи автор оной сместил мое внимание к вопросу регрессионного тестирования и рефакторинга, и суть я упустил)

С другой стороны существует масса достойной классики, есть принципы SOLID (которым по сути уже лет 40 и они не теряют актуальности, а все остальные вещи вытекают из них), GRASP паттерны, GoF паттерны... А тут предлагают почитать книжки по .NET, типа "нафиг тебе фундаментальные знания, лучше учи конкретный стэк технлогий"

[Oxoron]

Сергей Протько: Вы исходите из того, что человеку нужно ООП. Но, как показывает практика, если знаешь язык и фреймворки не зная - можешь работать. Если же знаешь ООП, не зная языка и фреймворков... согласитесь, сложно такое представить. Так что языка и фремворков большинству достаточно. Хотя Рихтер для начала тяжеловат, как и, возможно, Троелсен.

Теперь по пунктам
"не сможет разобраться что такое инкапсуляция": вначале обучения человеку знать не нужно, что такое инкапсуляция. Он практически не сталкивается с заданиями, где она нужна. В итоге, знания остаются чисто теоретическими, быстро забываются. Базовых знаний про модификаторы доступа вполне достаточно на первое время.

"люди не понимают в чем разница между инверсией зависимости и внедрением зависимостей": строго говоря, это далеко не преступление. Вполне могу допустить, что человек не особо вдумывался в смысл терминов, однако при необходимости заменял аргумент класса в конструкторе\методе на аргумент интерфейса, или выкидывал поля из класса, передавая данные при необходимости аргументами. Сам так делал. :)

Гуглить - это значит смотреть разные источники. В любом случае, при отсутствии опыта всегда есть возможность, что углубишься в регрессионное тестирование и рефакторинг. Возможно, для понимания ключевых вещей нужен релевантный опыт, который набивается на рефакторинге и "регрессе".

SOLID, TDD, GRASP, GoF - это хорошо, но, повторюсь, новичку важнее язык. Без него до SOLID не дорасти, с ним то не у каждого получается. Как пример, банду четырех в свое время толком не одолел. Вот эта статья дала гораздо больше. Сейчас читаю

[Oxoron]

Оп-па, ограничение на длину комента.
Короче, каждому джедаю свой меч, каждому времени свои правила. Новички пусть учат язык\фреймворки, после года-двух работы паттерны, SOLID и прочие GRASP.

[Сергей Протько]

Oxoron: потом приходится поддерживать код таких вот чуваков и просто плачешь...

Вы же понимаете что потом реальных проект такому знатоку языка и фреймворков не даш, он сможет решать только типовые проблемы, даш что-то с чем человек не сталкивался или задачу посложнее и все, пиши пропало.

TDD например новичкам как раз полезно, а опытным чувакам пользы уже меньше относительно.

[Oxoron]

Сергей Протько: г@#$окода бояться - программистом не быть. Где были старшие товарищи чуваков, почему они выпустили это код? Старшие товарищи виноваты больше. Банальное больше знаний - больше ответственность. Возможно - менеджмент.

Да, работать с легаси и просто воняющим кодом никто не любит, но он есть. И долгое время будет. Потому что практики развиваются, традиции меняются. Потому что есть новички, потому что менеджменту надо прям щас.

В конце концов, работа с легаси - одна из граней профессионализма. Недаром в Art Of Unit Testing есть главы, посвященные устаревшему коду.

Что касается до "дать проект" - тут все зависит от срочности\бюджета\выгоды\доступности других профессионалов. Иногда подходящих людей просто нет.

"даш что-то с чем человек не сталкивался": строго говоря, знание ООП здесь тоже может не помочь. Возможно, знаток GoF напишет свой велосипед вместо использования существующей фичи, о которой знает знаток фреймворка. (В велосипеде будет на баг больше, производительность на 10% ниже).

Новички пусть учат язык\фреймворки, после года-двух работы паттерны, SOLID и прочие GRASP. А те, кто выучил, пусть наставляют новичков на путь истинный.

[Сергей Протько]

Oxoron: да я как бы знаю "опытных" людей с 8+ годами стажа которые все так же пописывают говнокодец потому что придерживались этой идеи что знать надо язык и фреймворки. Потому что их не отучили в детстве так сказать.

Что до легаси - легаси это когда коду пара лет, а говнокод это говнокод.

Мой поинт в том что фреймворк, как и язык программирования, это только инструмент. Инструменты надо знать что бы ими пользоваться. А если у тебя есть еще и фундаментальные знания какие-то то изучать эти инструменты становится намного проще.

Говнокод это нормально. Без него никуда. Просто без основ ООП, а точнее понимания принципов и т.д. у разработчика не удастся вымыть руки после написания оного и весь проект измажет. Everybody poops by usually doing it in one place, или "говнокод это хорошо когда он закрыт красивым интерфейсом".

Причем самое обидное что принципы эти можно изучить за пару недель... но я встречал людей которые за 10+ лет все еще не поняли что такое принцип единой ответственности и зачем оно надо.

[Oxoron]

Сергей Протько: принципы ООП, паттерны - это только методики. Делай так-то, чтобы получилось (не получилось) то-то. Методики это надо изучать, чтобы ими пользоваться. А если у тебя есть знания языка, фреймворка, и опыт работы - изучать эти методики становятся проще.

Язык без ООП выучить можно. ООП без языка и опыта - крайне сложно.
Кодить без языка нельзя. Кодить без знания ООП - можно.
Поэтому сначала нужно учить язык.
Язык - базовая вещь. Поэтому новичкам нужно учить его.

ООП надо для управления сложностью. Без ООП можно писать малые проекты. С трудом - средние. Большие - никак. Качественный код без ООП не написать. Поэтому если нужно писать качественный код или средние\большие проекты - нужно учить ООП. Но учить после языка.

Под ООП выше понимайте техники, паттерны, принципы, ФП (да простят меня функциональщики) - любые методики для обуздания сложности.

Мысль про "не отучили в детстве" здравая. Люто, бешено плюсую. Разве что, расширяя метафору, учить надо, когда из утробы вылез и разговаривать научился. На языке.

Поэтому сначала Петцольд, Шилдт, хотя бы половину. Потом рефакторинг (Фаулера). ООП (хотя книг по ООП не знаю). Art of Unit Testing. Немного GitHub, push\pull\add\remove. А дальше поочередно фреймворк-Макконнелл-фреймворк-IoC-фреймворк-BDD ну и так далее. К тому времени и без наших советов обойдутся. :)

[Oxoron]

Сергей Протько: Да, есть карта тут. Достаточно здравая, литературу по ней можно подбирать.

[Сергей Протько]

Oxoron: я ничего не говорил про паттерны, я считаю что новичкам их учить опасно ибо они будут пихать их куда не попадя. Они сами собой будут выходить если постич базовые принципы.

И да, SOLID - это не методика, это принципы, следуя которым мы снижаем связанность и увеличиваем поддерживаемость. Знания фреймворка не помогут сделать проект поддерживаемым. Понимание принципов же - помогут.

Принципы SOLID появились в том или ином виде 40 лет назад, когда небыло еще ООП. Инверсию зависимостей придумали еще в 60-ых. Инкапсуляция, наследование, полиморфизм - все это можно делать и без ООП.

Знать что такое инкапсуляция без осознания того, зачем оно надо - это пустое. Почему люди решили изолировать ввод/вывод от обработки данных, почему ввели систему абстракций аля .NET, почему это важно и когда можно на это забить. Все это можно вполне себе совмещать с изучением фреймворков, но внимание должно быть сконцентрировано на важных вещах.

И да, мой поинт в том что бы человек не бездумно кодил а понимал что он делает и зачем. ООП или нет - не столь важно. Пусть человек узнает про TDD, про рефакторинг и т.д. Пусть использует тесты для обучения (реально помогает). Ну и т.д.

Если же человек сразу начнет кодить то обратит внимание он на фундаментальные знания только после того как зафакапит парочку проектов.

[Oxoron]

Сергей Протько: Факап проектов - не проблема новичка. Как минимум, не фатальная. Если новичок попал в нормальную команду - там его деструкцию заодно и ограничат, так что факапа не будет.

Насчет SOLID, IoC, ООП, ФП - я обобщал все это. Сильно обобщив - это инструменты борьбы со сложностью. Ментальные инструменты, практики, принципы, термин в нашем случае не важен.
Главное: что язык - необходим для разработки вообще, борьба со сложностью необходима при разработке больших проектов\в большой команде, там без нее почти никак.

Но это лирика. У нас два фундаментальных расхождения.
Первое. Человек должен понимать, что делает и зачем. Даже не обращая внимания на вопрос зачем, стандартное обучение: наблюдение, повторение, осознание, расширение. Посмотрел, о, EF7 появилось. Решил пощупать, поставил по шаблонам и инструкциям со stackoverflow, собрал грабли, почитал код\теорию, осознал принципы проблемы, накатил патч. Для наблюдения и повторения понимание не нужно. Делай, что сказали, и мотай на ус.

Второе. Можно совмещать кодинг и фундаменталку. Можно, но не всегда эффективно. Трата ресурсов на переключение контекста. Да, базовые вещи фундаменталки можно посматривать, но не более. Со временем, с опытом - там по всякому бывает.

Я согласен, хорошему программисту фундаменталка нужна. Но она первое время будет мешать новичку, при изучении на сколько-нибудь серьезном уровне.