Есть ли простые примеры применения ООП?

Question

[nickXoo]

Здравствуйте.
Где можно найти примеры использования всех принципов ООП в реальной программе, чтобы новичку было понятно. Погуглил. Да, понятно, что есть класс собака, обладающий характеристиками и функциями, на основе которого создаются объекты Бобик, Шарик и Тузик, которые могут иметь еще и дополнительные характеристики. Но не удалось найти именно практический пример.
Может, у кого-то есть свои наработки или ссылки? Буду благодарен.

Comments

[Adamos]

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

Answer 1

[GavriKos]

Любые исходники какого нить UI. Там обычно какой нить IDrawable, от которого реализуют уже Button, от которого ToggleButton и т.д. Можете например иерархию классов для андроидного UI посмотреть.

Answer 2

[Дмитрий Александров]

"Паттерны проектирования" O'Reilly. Шедевральные примеры, написано простым языком, кучи примером и отличные объяснения что\зачем\почему.

Comments

[Владимир Якушев]

Самый лучший вариант. ООП в отрыве от шаблонов - пустая трата времени. А вот вместе с ними мозги начинают правильно работать.

Answer 3

[Dimonchik]

Scrapy
Django

Answer 4

[index0h]

Простейший пример: логгер. Все, что он делает - передает дату и сообщение в N мест: консоль, файл, очередь, udp,...

Его можно реализовать по тупому: написать N похожих логгеров для каждого транспорта. Вам придется вручную следить, что бы интерфейс каждого был идентичным. Для многих языков поменять один логгер на другой будет не просто.

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

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