В поисках совершенных абстракций

[atomicxp]

На другом сайте размышляли об этом. В итоге пришли к выводам, что процедурное программирование использует функции возвращающие или не возвращающие значения, но и значение и аргументы являются данными.

В функциональном программировании, причём это всё применительно к C++ говорю, используются указатели на функции. То есть вместо данных передаются функции.

Далее идёт обобщённое программирование (template), где как аргументы уже передаются типы. И под конец ООП - объектно-ориентированное программирование цель которого комбинировать данные и методы в виде единой сущности - объектов.

Лично я описал это так:
1. процедурное - данные как аргументы
2. функциональное - функции как аргументы
3. обобщённое - типы как аргументы
4. объектно-ориентированное - создание типов

Всё это можно использовать в разнообразных сочетаниях. К сожалению стандартные и расширенные библиотеки C++ пошли по пути обобщённого функционального и естественно процедурного программирования. ООП в них по сути отсутствует, а вместо классов для совместимости с Си задействованы структуры.

Речь в данном случае идёт не просто о решении какой-либо задачи, а решения этой задачи другим способом и применяя другие парадигмы (ментальные модели) программирования.

[pu4koff]

В С++ ООП вообще слабенькое. Давно хочу язык D посмотреть, но всё руки никак не дойдут, там вроде ООП посерьезнее сделали

[atomicxp]

Если рассматривать native С++, то ООП там совсем не слабенькое, но это касается языка. Ни Java, ни C# не превосходят этот язык, насчёт D не знаю, но судя по описаниям не думаю, что его стоит изучать ради написания реальных проектов.

Хотя кто знает, во всяком случае поддержка ООП в C++ одна из самых мощнейших среди языков программирования, а вот библиотеки используют эти особенности крайне мало или вообще не используют. Потому собственно говоря и родилась эта тема.

[pu4koff]

Сообщение от atomicxp

Если рассматривать native С++, то ООП там совсем не слабенькое, но это касается языка. Ни Java, ни C# не превосходят этот язык, насчёт D не знаю, но судя по описаниям не думаю, что его стоит изучать ради написания реальных проектов.

Хотя кто знает, во всяком случае поддержка ООП в C++ одна из самых мощнейших среди языков программирования, а вот библиотеки используют эти особенности крайне мало или вообще не используют. Потому собственно говоря и родилась эта тема.

Что есть native С++? Который Visual C++ и gcc компилят - это этот самый С++?)
Если да, то:
1) нет поддержки интерфейсов и в итоге приходится создавать некрасивые астрактные классы с пустыми виртуальными деструкторами
2) typedef - вводит в заблуждение (не ООП конечно, но в построениях абстракций может навредить)
Допустим есть какой-то: typedef a b;
и пытаемся перегрузить функцию для 2-х типов параметров:

void foo(a);
void foo(b);

И будет то, что фактически тип b - это то же самое, что тип a и никак не различаются.
Придется "пустых" наследников видимо создавать в случае чего и зачем этот typedef нужен непонятно
3) RTTI неудобен. Попробуйте сделать коллекцию, у которой ключ - это тип, а значение - какое-то значение - не суть важно. Чтобы работать потом с ней можно было бы так:

TypeCollection < int > c;
c.AddItem< bool >(10);
c.AddItem< int >(50);
int a = c.GetItem< bool >(); // a = 10

Я это делал через одно место (в качестве ключа map'а выступало "рабочее" имя класса получаемое из структуры type_info ), но может у меня руки не из того места просто растут

Ну это из того, с чем я столкнулся на практике

ЗЫ. Извиняюсь за оффтоп

[atomicxp]

1. Какие классы напишешь, такими они и будут. Напишешь красиво, будет красиво, ну а в противном случае и так понятно.
2. Не используй typedef если он тебе не нужен. Как я понимаю наиболее удобное его применение в моментальной замене на нужный тип, когда в процессе происходят замены, в частности в кроссплатформенном программировании. Иными словами если одно имя типа заменяется на другой, то использование первого нецелесообразно в коде.
3. А по поводу третьего ничего сказать не могу, выглядит странно. Для начала нужно сообразить для чего нужен тип вместо ключа.

[pu4koff]

Сообщение от atomicxp

1. Какие классы напишешь, такими они и будут. Напишешь красиво, будет красиво, ну а в противном случае и так понятно.

Так оно полюбому будет некрасиво

class IMy
{
public:
  virtual ~IMy() {}; // брррр
public:
  virtual void foo() = 0;
  virtual void boo(int, float, bool) = 0;
}

Можно конечно на struct сделать, но там тока public уберётся, да и нелогично как по мне
Слишком много лишней информации, отвлекающей от самого интерфейса (все эти virtual, = 0,...).
Кроме того, допустим, есть два интерфейса, у которых есть метод с одинаковым именем. Пытаемся реализовать оба интерфейса в одном классе (типа множественное наследование применяем). В итоге получится фигня, т.к. нельзя указать для какого именно интерфейса реализация метода идёт.

Сообщение от atomicxp

3. А по поводу третьего ничего сказать не могу, выглядит странно. Для начала нужно сообразить для чего нужен тип вместо ключа.

В базе данных хранится информация о группах и студентах. Соответственно для студента и для группы соответствующие преобразователи для работы с базой. Хочется сделать коллекцию для хранения этих преобразователей с указанием типа объектов. Как-то так:

// Установка соответствия преобразователя - типу объектов
DataSource.SetMapper<Student>(StudentMapper);
DataSource.SetMapper<Group>(GroupMapper);
...
// Потом как-то так будет выглядеть запись объектов в БД:
DataSource.GetMapper<Student>().Save(stud1);
DataSource.GetMapper<Student>().Save(stud2);
DataSource.GetMapper<Group>().Save(group1);
...

[atomicxp]

У тебя тут упрощённый пример с IMy оринтированный на полиморфизм самих виртуальных чисто абстрактных методов. В наследовании можно ещё кое-что дописать. В целом же если не вдаваться в детали, а в C++ их не мало, так как это язык с избыточным программированием, то на любую проблему есть вполне простое решение.

На запись объектов в базу и из базы тоже есть, но там всё специфично и зависит от проекта. По мне так результаты зависят исключительно от программистов, и то что C++ не стесняет в выборе средств, а значит и в выборе неудачных стратегий развития программы, не является его недостатком.

[pu4koff]

Сообщение от atomicxp

У тебя тут упрощённый пример с IMy оринтированный на полиморфизм самих виртуальных чисто абстрактных методов. В наследовании можно ещё кое-что дописать. В целом же если не вдаваться в детали, а в C++ их не мало, так как это язык с избыточным программированием, то на любую проблему есть вполне простое решение.

Ну так дело в том, что я хочу сделать именно интерфейс и какие-то мощи мне здесь вовсе не нужны, но С++ интерфеи не поддерживает, а потому приходится выкручиваться так.
На C# легко это дело пишется:

interface IMy
{
  void foo();
  void boo(int, float, bool);
}

Преимущества:
1) Не надо указывать модификаторы доступа (public, private,..) т.к. интерфейс и отвечает только за public
2) Никаких виртуалов и нулей. Коротко и ясно

Надо будет как-нибудь протестить еще на таком примерчике:

interface A
{
  ...
}

interface B: A
{
 ...
}

interface C: B, A
{
 ...
}

В С++ скорее всего в С будет два экземпляра А (один для В и второй от "прямого" наследования). Потому, вероятно, и такое надо отслеживать и применять виртуальное наследование, а то как-то нехорошо будет.

Сообщение от atomicxp

На запись объектов в базу и из базы тоже есть, но там всё специфично и зависит от проекта. По мне так результаты зависят исключительно от программистов, и то что C++ не стесняет в выборе средств, а значит и в выборе неудачных стратегий развития программы, не является его недостатком.

Да тут не суть важно. База - не база... Хорошо. Другой пример: хочется мне завести коллекцию, в которой написать размеры каждого типа. Что bool - 1, int - 4, ... Коллекция тип-значение по-моему тут как нельзя лучше подойдёт? Вы можете её красиво сделать на С++? Я - нет.
Ну лично меня С++ временами стесняет и иногда заставляет совершать лишние телодвижения

[atomicxp]

В C# можно указать из какого интерфейса используется метод. Указание квалификаторов доступа можно опустить для открытых интерфейсов, но ведь бывают разные варианты использования, так что это не преимущество, совсем нет.

К тому же как писать и наследовать интерфейсы посвящены целые главые в некоторых книгах. В целом у них своя ниша использования. Что же касается абстрактных классов, то в C# они тоже странно срабатывают, а интерфейсы везде не поставишь. Да и вообще, интерфейсы ограничены в применении.

Но если говорить глобально, то я не могу сказать, что C# лучше C++ в этом плане или наоборот. Для меня и то и другое одинаково. Я пытаюсь мыслить вне языков, хотя в поисках абстракций использую ООП, но опять же тоже вне языков. Важны сами идеи сочетания разных данных, функций, типов и прочего.

[pu4koff]

Сообщение от atomicxp

В C# можно указать из какого интерфейса используется метод. Указание квалификаторов доступа можно опустить для открытых интерфейсов, но ведь бывают разные варианты использования, так что это не преимущество, совсем нет.

Вы вероятно не совсем понимаете что такое интерфейс. Назначение у них другое, не как у абстрактных классов.
Допустим, есть клавиатура. Интерфейс для пользователя - это кнопочки клавиатуры и что там внутри и как устроено - не важно. Пользователь с клавиатурой общается через этот интерфейс и больше ему ничего не нужно.
Для компа же интерфейс для той же клавиатуры - это уже собственно механизм, по которому с драйвером общение происходит. Тут уже до кнопочек и рычажков никакого дела, а главное уже как внутри это всё устроено.
Абстрактный класс клавиатуры уже будет возможно реализовывать частично оба этих интерфейсы и что-то еще содержать.
При реализации интерфейса, класс как бы говорит: "я могу вот это".
При наследовании от другого класса скорее: "я являюсь вот этим".
Таким образом, в интерфейсе, кроме модификатора public, по определению не может быть никакого другого. Для разных вариантов использования требуются разные интерфейсы, а иначе это уже будут не интерфейсы, а что-то другое.

Сообщение от atomicxp

К тому же как писать и наследовать интерфейсы посвящены целые главые в некоторых книгах. В целом у них своя ниша использования. Что же касается абстрактных классов, то в C# они тоже странно срабатывают, а интерфейсы везде не поставишь. Да и вообще, интерфейсы ограничены в применении.

Например, что странного в поведении абстрактных классов? Я на C# мало программил просто и может что-то пропустил.
Ничего интерфейсы не ограничены, а как Вы сами сказали: "у них своя ниша использования". К сожалению, в плюсах этой ниши получается что нет.

Сообщение от atomicxp

Но если говорить глобально, то я не могу сказать, что C# лучше C++ в этом плане или наоборот.

Да и я не за шарп или плюсы. Мне вообще ни один язык не нравится целиком и полностью. Везьде свои проблемы

Сообщение от atomicxp

Я пытаюсь мыслить вне языков, хотя в поисках абстракций использую ООП, но опять же тоже вне языков. Важны сами идеи сочетания разных данных, функций, типов и прочего.

Аналогично. Только неприятно, когда в итоге упираешься в невозможность нормальной реализации идеи из-за особенностей языка.