Автовывод типов методов в С++

А с моей точки зрения лишняя функциональность в классе: эмуляция неймспейса.

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

Например если надо счётчик для нескольких классов сделать, будешь им общего предка добавлять? Или если действительно надо считать именно объекты текущего класса. Через функцию в неймспейсе делается тривиально.

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

Если нет конфликтов имён, первая команда using namespace. Вообще-то классы по неймспейсам рекомендуется распихивать чтобы случайно с именем из другого файла не пересечься.

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

И позволяет писать в стиле

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

Логичнее для фабрики сделать дружественную функцию вместо статической.

для меня самое логичное, когда фабричный метод определен внутри класса. а дружественная функция - это просто левая функция, которая может быть где угодно,и которой может не быть вообще, что имеет доступ к непубличным членам класса. Это тоже костыль по сути. Дружественная функция, это не что иное как член класса(статический или нет), просто выдернутый наружу вопреки канонам инкапсуляции, в данном случае. Ну так не выдергивайте ее, и оставьте внутри.

Опять же она к классу не привязана никак. то есть если запись A::create() - достаточно внятно говорит о каком-то создании экземпляра А, то create_A() - это непонятно что, а нормально еще воспринимается create_instance_A()… но это уже какое-то литературное творчество. рефакторинг имени класса A->B, автоматически сделает невалидными вызовы c префиксом данного класса и это хорошо. а create_instance_A() так и останется незамеченным.

Статические методы имеют смысл, если они всё-таки используются как методы. Типа

Наконец-то! «Статические методы имеют смысл». они не просто имеют смысл, они просто НЕОБХОДИМЫ, чтобы себя хорошо чувствовать в ооп, и не костыльничать там всяко.

о неймспейсе говорить вообще не стоит. это особенность плюсов, - костыль для эмуляции модулей

Если не привязываться к плюсам, то всюду есть какие-либо реализации модулей: пакеты, модули, юниты, …

«несколько классов», если у них нет общего предка, по понятийной модели ООП не должны иметь общих свойств

Внезапно. Чайник и собака должны иметь общего предка, так как оба могут стоять на земле? Список и массив должны иметь общего предка, так как оба предоставляют итераторы?

это порочные люди придумали, что к статической функции класса можно обратиться через его экземпляр

Вообще-то идея, что к методу можно обратится через экземпляр первична. Статические методы появились как методы, работающие только со статическими полями (по аналогии с константными методами). А статические поля в CLOS, который был раньше C++ доступны только через экземпляр.

для меня самое логичное, когда фабричный метод определен внутри класса. а дружественная функция - это просто левая функция

С этим спорить уже не буду. Тут уже чистая вкусовщина про «класс=модуль» против «модуль для имён, класс для данных и действий». Но класс=модуль заставляет связанные классы, не являющиеся потомками друг друга делать вложенными или давать им суррогатного общего предка (классы типа HasIterator, HasShallowCopy, HasDeepCopy, Printable, Readable, …).