ddd329

Если можно, то отвечу чего точно не стоит смотреть/читать, так это то, когда начинают говорить что-то наподобие такого:

Ну вот представьте что у вас есть кошечка и собачка. Кошечка мяукает, а собачка лает, т.е. они все умеют говорить, но каждый по-своему. Кошечка и собачка это животное, значит выделим базовый класс Animal...

Да и вообще, когда говорят, что ООП моделирует реальный мир... Бегите сразу от таких преподователей...

Смотря какой класс.
Если это сущность предметной области, то нет, не стоит.
Если это сервисы, то да, стоит.

Вот самый подходящий паттерн Цепочка обязанностей

Могу дать такие советы, как вижу это я.

Разделить приложение на три уровня:
1) Presentation - уровень представления, при помощи которого пользователь взаимодействует с приложением;
2) Business Logic - слой бизнес-логики;
3) Persistence - слой где хранятся данные, но обычно это реляционная БД.

Если это настольное приложение, то слой Presentation разбей на три компонента согласно паттерну MVP (Model-View-Presenter), если это классическое веб-приложение, то паттерну MVC (Model-View-Controller).

Слой бизнес-логики реализуй согласно паттерну Transaction Script, ну либо паттерну Модель предметной области, где для начала будет анемичная модель (anemic model), которая полностью совпадает со схемой БД, а логику храни в сервисах. Далее когда наберешься скиллов, то можешь пробовать из анемичной модели предметной области сделать богатую (rich model), для этого можешь обратить внимание на методологию DDD (Domain-Driven-Design).

Ну и слой хранения, тут пока тупо через средства ORM...

Ну примерно так, ничего нового и волшебного тут нету.