Модификатор abstract

На собеседовании сидишь?

как и везде в ООП - абстрактные классы не имеют реализации, требуют ее от потомков. Виртуальные же методы не требуют реализации от потомков.

Встречный вопрос:
C# в linux. На кой черт он нужен? Приведите пример где он объективно необходим для реализации.

C# в linux. На кой черт он нужен?

Удобен.

Это я знаю. Но не смог придумать задачи, где это было бы необходимо.

Удобен.

Сомнительно.

Это я знаю. Но не смог придумать задачи, где это было бы необходимо.

Классика: абстрактный класс «фигура» и реализации - круг, квадрат, треугольник.
Ближе к реальности: абстрактный класс источник данных и реализации: локальный файл, http, ftp, db...

http://en.wikibooks.org/wiki/C_Sharp_Programming/Abstract_classes - ну вот, например, шейпы, ректанглы...

Сомнительно.

Помимо, вариантов не много: питон и ява. Питон --слишком оригинальный, подойдет тем, кто любитель острых ощущений и экспериментов, меня же сильно огорчает невозможность писать в строчку, выходить за пределы тогда, когда Я, Я(!) хочу/нужно/красивее. Ява ладно, пойдет.

питон и ява.

Perl.

А вообще - пиши на с/с++. Будь мужчиной!

пиши на с/с++. Будь мужчиной!

Пиши на плюсах, будь мужчиной, создавая себе сложности в мультиплатформенности и героически их решай, ага :)

создавая себе сложности в мультиплатформенности и героически их решай, ага :)

Именно!

C# На кой черт он нужен?

fixed

Паттерн абстрактная фабрика

Помимо, вариантов не много: питон и ява. Питон --... меня же сильно огорчает невозможность писать в строчку, выходить за пределы тогда, когда Я, Я(!) хочу/нужно/красивее. Ява ладно, пойдет.

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

Приведите пример где он объективно необходим для реализации.

когда мы говорим об ООП, слово «необходим» - неуместно.

Ну давай какую-нибудь предметную область придумай и опиши её иерархией классов, найдешь может куда абстрактный класс впихнуть.

Вот смотри, пусть нам надо описать аутентификацию пользователей:

1) нужен максимальной абстрактный бэкенд аутентификации, максимально абстрактные параметры аутентификации, пусть будут интерфейсами.

2) Теперь у нас есть огромное количество бэкендов, которые проверяют имя пользователя и пароль пользователя. Вот пусть будут абстрактными классами.

3) А уж конкретные реализации с шифрованием, работой с сетью, базой и прочими безобразиями(ну LDAP там, DB, WebDav,Unix-user) и проч. будут конкретными классами.