Ведь можно сделать просто:
class DB {
// все методы работы с БД
}
class Logger extends DB {
// все методы логирования в БД и файлы
}
class Valirator extends Logger {
// все методы проверки форм
}
class User extends Valirator {
// все методы работы с юзером
}
И всё, я победитель по жизни, у меня в User досупны все методы всех родителей, хочу в базу пишу, логирую, проверяю. Но что-то посказывает что это неправильно.
Плохого в это то, что нарушается принцип единственной ответственности. Например тут "у меня в User досупны все методы всех родителей". Зачем вашему User уметь, да и вообще знать, про какое-то там логирование?
Наследоваться имеет смысл если и родитель и потомок действительно являются "родственниками".
Т.е. например "Авторизованный пользователь" вполне логично отнаследовать от "Пользователь", а вот наследовать "Пользователя" от "Базы данных" - это какой-то оксюморон.
Вот так норм:
AuthorizedUser extends User
PrivilegedUser extends AuthorizedUser
А вот так нет
Table extends User
User extends Autobus
Autobus extends Database
UPD
С точки зрения объектного подхода к проектированию, User у вас - это отражение актора "Пользователь", который в принципе не должен знать о том, как устроена логика вашего приложения. Validator, Logger и Database- это, по хорошему, интерфейсы, а не объекты, с которыми, опять же по хорошему, User взаимодействовать не должен.
Рассмотрим use case - пользователь заходит в систему и по этому факту происходит его проверка и логирование.
Validator введенные данные.Validator проверяет корректность и передает объекту класса, реализующего интерфейс Logger, данные для логированияLogger, наследующий от DatabaseSource или FileSource (соответственно DbLogger или FileLogger) совершает логированиеUser, PriveledgedUser, ReadOnlyUser, etc... Либо ошибка авторизации (Exception например)Сборка персонального компьютера от Artline: умный выбор для современных пользователей