Продолжая тему - http://programmingmindstream.blogspot.ru/2014/03/blog-post_12.html
Итак..
Просто список:
1. C++ (множественное наследование).
2. Python (множественное наследование и Duck-typing).
3. Objective-C (Duck-typing и "селекторы" и "перехват селекторов").
4. Objective-C++ (см. выше ну и как надмножество над C++).
5. Smalltalk ("сообщения", а не методы и возможность обработки "необъявленных явно сообщений").
6. Delphi ("криво", через "хак" и include - http://18delphi.blogspot.ru/2013/03/blog-post_29.html (ну иок ещё)).
7. "Птичий язык" от Макса (http://18delphi.blogspot.ru/2013/10/blog-post_4433.html) (множественное наследование и Duck-typing).
8. Java (рефлексия и возможность управления байт-кодом (если я не ошибаюсь)). (http://ru.wikipedia.org/wiki/%D0%90%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
9. FORTH (да и любые другие Конкатенативные языки - http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D0%BA%D0%B0%D1%82%D0%B5%D0%BD%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F). А также LISP и Scheme ("Конктенативные языки можно рассматривать как семейство языков, вроде Лисп-языков. Так между всеми диалектами Лиспа (включая Scheme), есть сильное «семейное сходство». Однако есть большая разница в дизайне, реализации и назначении этих языков. Языки программируемых микрокалькуляторов и многие из версий Форта предназначены для встраивания в небольшие микропроцессорные системы; PostScript также является встраиваемым языком, только микропроцессорные системы, интерпретирующие его называютсяпринтерами. Однако другие конкатенативные языки, такие как Joy или Cat разработаны как языки программирования общего назначения или в исследовательских целях." там же)
И ещё...
В СЕТИ - была ХОРОШАЯ статья - "почему отдельностоящие методы ЛУЧШЕ методов классов".
Я никак не могу найти ссылку на неё. (Если найдёте - ПРИСЫЛАЙТЕ - с меня пиво или коньяк, ну или что вы там хотите.. в разумных пределах...).
Так вот.
В статье ПОКАЗЫВАЛОСЬ - почему "отдельностоящие методы" ЛУЧШЕ методов классов. И как это ПОНИЖАЕТ "связность" и УЛУЧШАЕТ архитектуру. Тут не премину вспомнить IStream (О УЖАС) (http://msdn.microsoft.com/en-us/library/windows/desktop/aa380034(v=vs.85).aspx) и IDataObject (О УЖАС УЖАС) (http://msdn.microsoft.com/en-us/library/windows/desktop/ms688421(v=vs.85).aspx).
Это вещь "ортогональная" примесям, но "на ту же тему"...
Про IDataObject хочу сказать - GetData и GetDataHere. Одно выводится ЧЕРЕЗ другое. И должно было быть сделано "хелперами" или "отдельностоящими методами". Но! MS предпочёл ОБЯЗАТЬ ВСЕХ реализовывать ОБА метода.. Причём каждый из них является "спорным" сам по-себе. Чего только "развесистость" FORMATETC (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682177(v=vs.85).aspx) и STGMEDIUM (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683812(v=vs.85).aspx) стоят.
Это - УЖАС, а не "интерфейс".
Я его РЕАЛИЗОВАЛ и НЕ РАЗ и НЕ ДВА. И в итоге сделал "базовый класс". От которого наследуются все остальные. И наследники СИЛЬНО ПРОЩЕ исходного интерфейса. Они переопределяют один/два метода.
Я об этом позже напишу.. Если хватит сил.
Пока вот вам ссылки:
1. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3DataObject.pas
2. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3BitmapDataObject.pas
3. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3DataObjectEnum.pas
4. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3InterfacedDataObject.imp.pas
5. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3StorableDataObject.pas
6. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3TreeDataObject.imp.pas
Итак..
Просто список:
1. C++ (множественное наследование).
2. Python (множественное наследование и Duck-typing).
3. Objective-C (Duck-typing и "селекторы" и "перехват селекторов").
4. Objective-C++ (см. выше ну и как надмножество над C++).
5. Smalltalk ("сообщения", а не методы и возможность обработки "необъявленных явно сообщений").
6. Delphi ("криво", через "хак" и include - http://18delphi.blogspot.ru/2013/03/blog-post_29.html (ну иок ещё)).
7. "Птичий язык" от Макса (http://18delphi.blogspot.ru/2013/10/blog-post_4433.html) (множественное наследование и Duck-typing).
8. Java (рефлексия и возможность управления байт-кодом (если я не ошибаюсь)). (http://ru.wikipedia.org/wiki/%D0%90%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
9. FORTH (да и любые другие Конкатенативные языки - http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D0%BA%D0%B0%D1%82%D0%B5%D0%BD%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F). А также LISP и Scheme ("Конктенативные языки можно рассматривать как семейство языков, вроде Лисп-языков. Так между всеми диалектами Лиспа (включая Scheme), есть сильное «семейное сходство». Однако есть большая разница в дизайне, реализации и назначении этих языков. Языки программируемых микрокалькуляторов и многие из версий Форта предназначены для встраивания в небольшие микропроцессорные системы; PostScript также является встраиваемым языком, только микропроцессорные системы, интерпретирующие его называютсяпринтерами. Однако другие конкатенативные языки, такие как Joy или Cat разработаны как языки программирования общего назначения или в исследовательских целях." там же)
И ещё...
В СЕТИ - была ХОРОШАЯ статья - "почему отдельностоящие методы ЛУЧШЕ методов классов".
Я никак не могу найти ссылку на неё. (Если найдёте - ПРИСЫЛАЙТЕ - с меня пиво или коньяк, ну или что вы там хотите.. в разумных пределах...).
Так вот.
В статье ПОКАЗЫВАЛОСЬ - почему "отдельностоящие методы" ЛУЧШЕ методов классов. И как это ПОНИЖАЕТ "связность" и УЛУЧШАЕТ архитектуру. Тут не премину вспомнить IStream (О УЖАС) (http://msdn.microsoft.com/en-us/library/windows/desktop/aa380034(v=vs.85).aspx) и IDataObject (О УЖАС УЖАС) (http://msdn.microsoft.com/en-us/library/windows/desktop/ms688421(v=vs.85).aspx).
Это вещь "ортогональная" примесям, но "на ту же тему"...
Про IDataObject хочу сказать - GetData и GetDataHere. Одно выводится ЧЕРЕЗ другое. И должно было быть сделано "хелперами" или "отдельностоящими методами". Но! MS предпочёл ОБЯЗАТЬ ВСЕХ реализовывать ОБА метода.. Причём каждый из них является "спорным" сам по-себе. Чего только "развесистость" FORMATETC (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682177(v=vs.85).aspx) и STGMEDIUM (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683812(v=vs.85).aspx) стоят.
Это - УЖАС, а не "интерфейс".
Я его РЕАЛИЗОВАЛ и НЕ РАЗ и НЕ ДВА. И в итоге сделал "базовый класс". От которого наследуются все остальные. И наследники СИЛЬНО ПРОЩЕ исходного интерфейса. Они переопределяют один/два метода.
Я об этом позже напишу.. Если хватит сил.
Пока вот вам ссылки:
1. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3DataObject.pas
2. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3BitmapDataObject.pas
3. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3DataObjectEnum.pas
4. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3InterfacedDataObject.imp.pas
5. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3StorableDataObject.pas
6. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3TreeDataObject.imp.pas
Комментариев нет:
Отправить комментарий