Здравствуйте, 0x7be, Вы писали:
0>Боюсь, мы говорим совершенно о разных вещах.
Ну почему же, мы с тобой отвечаем на один и тот же вопрос: в чем главная проблема ООП, в ООП или в людях. Отвечаем по разному, да, но это не означает, что говорим мы о разных вещах.
Здравствуйте, igna, Вы писали:
I>Какую такую мощность дало языку использование слова const в двух целях, как read-only и как собственно constant?
Это как раз кривизна.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, 0x7be, Вы писали:
0>>Здравствуйте, Mystic, Вы писали:
M>>>Конкретнее, в догматиках. 0>>Не только. Восторженные юноши, окрыленные передовыми идеями, тоже вносят свою лепту
M>Юноши — догматики
юношей вон из разработки ПО
(индустрия страдает)
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, 0x7be, Вы писали:
0>>Я думаю, что главная проблема ООП совсем не в ООП, а в людях, которые некогда превратили его в религию. S>А я думаю, что главная проблема ООП — в мифологии... S>абсурд каким-то непонятным мне образом проникает в популярную литературу. S>Например, очень много "учебников ООП" .... S>Неопытные разработчики принимают этот бред за чистую монету, откуда происходит...
Да, ООП здесь можно заменить на что угодно.
Незрелая область деятельности, авторы "учебников" выдают субъективное мнение за истину, хотя и пишут не о сути мироздания, а об интсрументах и способах решения задач, преподносят своё понимание хорошего и плохого.
S>Редкий частный случай, когда имеет смысл наследовать реализацию, а не интерфейс, выдаётся за основное применение.
Не согласен. Наследование реализации способно во многих случаях сократить кол-во кода, дублирование, а следовательно и сложность. Пример: представим класс A, для которого планируется сделать торчу наследников
abstract class A
{
protected abstract bool MyMethod1();
public int PublicMethod1 ()
{
//...
if (MyMethod1())..
//....
}
}
А вот хороший интерфейс дорогого стоит. Чтобы создать пачку годных интерфейсов нужно нехилые скилы иметь.
(Сам неоднократно писал throw new NotSupportedException())
S>В итоге мы имеем разрыв между тем, чему учат в учебниках и тем, что стоит применять на практике. Отсюда и весь этот горький катаклизм, который мы наблюдаем.
А наблюдаем мы на практике то, что было когда-то в учебнике
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, igna, Вы писали:
I>Трудности появляются сразу, на самых простых задачах; так из-за отсутствия мультиметодов попытка определения любой операции требующей полиморфизма более чем по одному параметру превращаются в вырезание гландов автогеном через понятно что.
К слову, мультиметоды в C# можно эмулировать с помощью dynamic-а. Правда такие методы будут вызваться раз в 10-20 медленнее обычных.
Здравствуйте, hardcase, Вы писали:
H>К слову, мультиметоды в C# можно эмулировать с помощью dynamic-а. Правда такие методы будут вызваться раз в 10-20 медленнее обычных.
Унаследовано-то все-равно все от Object со всеми вытекающими Equals. Образно говоря, бочка говна останется бочкой говна даже если в нее положить пару ложек меда.
Ф>abstract class A
Ф>{
Ф>protected abstract bool MyMethod1();
Ф>public int PublicMethod1 ()
Ф> {
Ф> //...
Ф> if (MyMethod1())..
Ф> //....
Ф> }
Ф>}
Так это же главный объектно-ориентированный антипаттерн!
Вместо того, чтобы параметризировать функцию PublicMethod1 параметром функционального типа MyMethod1 (хотя бы по аналогии со стандартным qsort древнего языка C), устраивается этот выворот кишок.
Здравствуйте, x-code, Вы писали:
XC>Но нет. Вместо этого все упорно продолжают колоться и жрать кактусы. И еще придумывать свои языки (Java, C#). Патентовать их и судиться друг с другом.
Я вот хочу придумать качественный стандарт на стэк язык/промежуточный бинарный код/виртуальная машина для этого бинарного кода/ОС где всё на этом бинарном коде.
Только скажем синтаксис у меня более многословный выходит, а хочешь лаконичности — будет C++|C# а в этом (особенно в связи с C#) случае возможны патентные тролленги.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, x-code, Вы писали:
S>C++ кривой в следствие своей мощности. Хотите грамотно спроектированный, избавленный от всех недостатков С++ и с множеством новых полезных и грамотно спроектированных фич — C# и java к Вашим услугам, хотите нативный, похожий на С++ и относительно простой — шаг назад к Си. S>Причем здесь жадность? S>Поймите, люди работающие в крупных ИТ компаниях не дураки, они прекрасно понимают что C++ 2 закончиться все тем же C++ 1. Здесь как обычно все сводится к компромиссам.
Дураков везде хватает. Вот я имхо убийство Silverlight — дурость несусветная со стороны Microsoft, я считаю.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Философ, Вы писали:
I>Так это же главный объектно-ориентированный антипаттерн!
I>Вместо того, чтобы параметризировать функцию PublicMethod1 параметром функционального типа MyMethod1 (хотя бы по аналогии со стандартным qsort древнего языка C), устраивается этот выворот кишок.
?? не понял
1) чем не нравится
2) как и чем параметризировать
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>?? не понял Ф>>1) чем не нравится Ф>>2) как и чем параметризировать
I>Ты qsort из стандартной библиотеки C знаешь?
Здесь никакой ООПы к счастью нет. Но здесь есть как бы намек, как можно реализовать то, для чего ты использовал наследование реализации. И тогда все будет на своих местах, а не вывернуто наизнанку.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Философ, Вы писали:
I>Здесь никакой ООПы к счастью нет. Но здесь есть как бы намек, как можно реализовать то, для чего ты использовал наследование реализации. И тогда все будет на своих местах, а не вывернуто наизнанку.
ответа не увидел
Ф>1) чем не нравится
с каких пор это стало антипаттерном?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>с каких пор это стало антипаттерном?
Не стало, а всегда было. Твой MyMethod1 надо сделать интерфейсом и добавить параметр типа этого интерфейса методу PublicMethod1. И все, никакого наследования реализации как не бывало. Проще — значит лучше, а все что не по делу усложняет программу является антипаттерном.