Ведь можно сделать просто:
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 например)https://pastebincom/yEk6d7JU вот тут код, и такие ошибки if (Hacks