Единственное внятное видео по C#. Впервые с ходу понял всё без вчитывания в теорию на metanit-е (кстати там вообще всё плохо с интерфейсами, на мой взгляд). Были бы все уроки в таком же стиле.

См. урок 7, "Пример создания приложения".

+Алексей Луняев, очень долго объяснять. Если вкраце - то ваш код более модульный, более поддерживаемый. Рекомендую почитать литературу по набору принципов SOLID. А также введение к книге Dependency injection in .NET - там хорошо объясняется, что такое слабая связность кода и почему это есть благо.

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

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

Зависит от того, в какой предметной области происходит работа. Например, если мы имеем дело с десктоп-приложением, значит, надо обязательно знать библиотеку System.Windows.Form и класс Control. Что касается общих вещей, то никогда не лишнем будет знание множеств (см. урок 9, "Множества"). И т. д. Ориентирование в дотнете всё равно приходит с практикой.

genady pisarev Если еще не разобрался сам, то подмогну, авось еще кому поможет. >но вот статические и обстрактные методы классы ,и,т,д . я не пойму для чего вся эта волокита Статический класс в принципе не особо нужен, но допустим, глядя на класс 2DUtility я примерно пойму по названию для чего он нужен, и соответсвенно уменьшу названия части используемых функций - т.е. это синтаксический сахар по сути. Абстрактный класс - наследние от С++. Дело в том что С# в первой редакции разрабатывался через одно место, и там повсюду компромиссы. Так что эта "волокита" - следствие старых ошибок и концепций. >сетер и гетер . для чего они нужны? Это на самом деле пострясающая и исключительно нужная вещь. С их помощью ты можешь сохранять инвариант класса ))) То бишь - отсекать недопустимые действия, вызывать нужные, и т.д., в общем это крайне необходимая вещь. Есть даже такой "паттерн" - property - и используется он практически повсеместно. К примеру - в игре у тебя у перса здоровье опустилось меньше 0, и ты - вместо того чтобы отслеживать это во многих местах внутри игры, вешаешь делегат, который дергается когда здоровье становится равным/меньше нулю, и в сеттере проводишь все проверки, включая дергание делегата и т.п. В-общем используется в каждом практически проекте, большем пары десятков строк. >string myString{set;get}; У меня в той же vs по умолчанию так и подставляется. Лень стирать )

Можно и string. В данном случае это совершенно непринципиально. На самом деле этот пример целиком взят из Рихтера )

+Юрий Пискунов Пожалуйста, укажите тайминг, невозможно помнить наизусть все уроки ) Что касается вопроса - конечно же, если реализация ICOmparable есть в родительском классе, то наследник так же будет ее поддерживать.

+Программирование - это просто Конечно. Извиняюсь. 19:08

+Юрий Пискунов Честно говоря, уже не помню, почему я так сказал ) В любом случае, смотрите мой предыдущий ответ - он корректен.

+Программирование - это просто И ещё одно. А если ситуация, когда нужна последовательная сортировка элементов массива по разным полям. Сначала по возрасту, потом по оценкам...

+Юрий Пискунов тогда в случае равенства возрастов не надо возвращать 0 в методе CompareTo, а переходить к анализу следующего поля.

в книге по которой учу - к примеру все фигуры идут от базового класса Shapes все сотрудники продажи Employee ну все правильно у каждой так сказать категории свой базовый абстрактный класс откуда и идут имена формы возраст бонусы и так далее просто потом например если собаку надо засунуть в дом это как бэ соединяется другим методом

на сколько я понимаю на схеме Speed и Producktion наверно делегаты те это отдельные файлы с методом и с помощью делегирования в Animal BaseShip и BaseHouse созданы их объекты которые уже распространяются на дочерние если бы я делал то лучше в каждом базовом определил бы отдельно хотя если еще куча базовых классов то можно и отдельно но на сколько я понимаю это уже свой стиль

SpeedObject и ProductionObject, в контексте урока, - интерфейсы. Оказывается, как я уже выяснил, в интерфейсах можно описывать не только методы, но и свойства. Следовательно, описать свойство Name нужно в SpeedObject и ProductionObject. В реализациях этих интерфейсов Animal, BaseShip и BaseHouse мы обязаны будем определить свойство Name, а уже во всех потомках использовать это свойство. Спасибо, что помогли разобраться.

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

@@BastionKadabr а VS это должна отображать ? . . . если да - то я буду искать причину . . .

Как правило, каждый класс, который реализует интерфейс, осуществляет собственную реализацию этого интерфейса, поэтому дублирования кода не происходит. Если же в коде выявляются какие-то общие участки, их можно вынести во внешний статический класс (получится так называемый хелпер). Тему хелперов и методов расширения мы будем рассматривать в 10 или 11 уроке.

Defazze Спасибо за ответ и за Вашы труды! Жду новых уроков.

Модификаторы доступа тут не при чем. Суть явной реализации интерфейса - методы, реализованные явно, могут быть вызваны только у экземпляра, тип которого является этим интерфейсом. А вот если тип экземпляра реализует интерфейс, то методы, реализованные явно, вызваны быть не могут. Пример: тип Array (любой массив) реализует интерфейс IList. В интерфейсе IList есть метод Add. Однако если мы создадим массив, метода Add в экземпляре мы не увидим. Потому что он реализован явно. Тем не менее мы можем вызвать метод Add, если приведем наш массив к IList. Правда, тут же напоремся на исключение )

habrahabr.ru/post/30444/ - ответ на главные вопросы по этой теме. там в комментах есть бородатый пример с квадратом и прямоугольником. Есть такие принципы ООПроектирования - S.O.L.I.D. В частности L - принцип подстановки Лисков - дает понимание когда нужно наследовать(расширять) классы, и углубляясь в тему, можно понять когда реализовывать интерфейсы, при якобы нужном наследовании. В некоторых языках(не C#) синтаксис говорит сам за себя: class Child extends(РАСШИРЯЕТ) ParentClass, но - class Child implements(РЕАЛИЗУЕТ) IComparable. Т.о. нужно всего лишь для начала запомнить - расширяет класс, но реализует интерфейс. :)

Для перегруженных методов - не входит. Для интерфейсов и делегатов - входит. msdn.microsoft.com/ru-ru/library/ms173114.aspx

Извините - не дочитал :)

ukposts.info/have/v-deo/nqViZ5pojW1krGg.html тут объясняться более точно смысл интерфейса, я тоже думал что можно просто создавать abstract

Нет