Добрый день, Leonidv!
>> Из вашего поста множественное наследование - я считаю, вполне можно без
>> этого обходится и опыт java как раз показывает, что весьма успешно.
Да, его можно заменить делегированием. Но всё же иногда бывает, когда
надо именно наследовать (т.е. класс именно "есть", а не "использует").
> Именованные конструкторы заменяются статичными методами или Builder'ами.
Опять же- заменяется. Но удобнее- именованные.
>> автоматическое деланье методов невиртуальными
> Это же можно сделать только runtime? При компиляции в общем случае не
> получится.
eiffel язык с линкером- там можно. В яве- да, не получится. Работаешь, а
тут загрузился класс, где этот метод перекрыт :)
> Вы сослались на ЯП, но не привели ссылок на свежие источники, которые
> подтверждают что все что вы говорите значительно лучше того, что есть в
> Java.
Я храню мнения в голове, а ссылки туда не помещаются :)
Плюс собственный опыт говорит, что да, именно так лучше.
Что-то приятно, что-то делает код более понятным, что-то просто
незаменимо (контракты - AOP тут не помогает).
> Все последние книги, которые я читал по проектированию вполне себе
> обходятся без множественного наследования и именованных конструкторов.
> Начиная с GoF и дальше. Принцип KISS тоже никто не отменял.
Просто у них выбора нет.
Я тоже не использую именованные конструкторы- нету их. Получается куча
статических методов, дублирования кода и лишнее поле для ошибок (при
наследовании статические поля способны творить волшебные ошибки).
> Еще хотел спросить:
>> Что должна быть возможность описать тип "этот класс".
> Что здесь имеется ввиду? Не сталкивался с таким понятием.
1.
2.
3.
4.
5.
6.
7.
8.
class C1{
public C1 add(String v) {...}
}
class C2 {
public do() { ... }
... add НЕ перекрыт
}
[/src]C2 c2 = new C2();
c2.add("xxx").do(...); <-- вот тут будет ошибка компиляции.
[src]
Редко нужно, но штука полезная. При глубокой иерархии наследования
помогло бы.
--
Алексей
JID:
alxt@ya.ru
Posted via ActualForum NNTP Server 1.4
