Re[16]: бессмысленные интерфейсы
От: Ночной Смотрящий Россия  
Дата: 20.02.22 11:19
Оценка:
Здравствуйте, netch80, Вы писали:

N>А переключатель контекста асинков разве ещё не способен потянуть за собой нужные параметры?


В случае дотнета способен и делает это.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[17]: бессмысленные интерфейсы
От: Ночной Смотрящий Россия  
Дата: 20.02.22 11:19
Оценка:
Здравствуйте, ·, Вы писали:

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


Практика показывает, что твои думы это что то вроде ветряных мельниц.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[18]: бессмысленные интерфейсы
От: · Великобритания  
Дата: 20.02.22 18:06
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>Практика показывает, что твои думы это что то вроде ветряных мельниц.
Практика показывает, что это тупо грабли
https://stackoverflow.com/questions/56101141/asp-net-core-mvc-set-thread-culture-does-not-have-effect
https://stackoverflow.com/questions/468791/is-there-a-way-of-setting-culture-for-a-whole-application-all-current-threads-a
https://stackoverflow.com/questions/20872028/thread-currentthread-currentculture-not-working-in-a-thread-inside-a-threadpool

Вроде что-то улучшили в 4.6. Но всё равно явно корявая архитектура. _Переменные_ не стоит делать глобальными. Thread local нужен совсем для другого. Ну может кеш какой-нибудь или типа того, но нельзя там хранить изменяемое состояние.

А ещё этот идиотизм с двумя переменными Thread.CurrentUICulture и Thread.CurrentCulture. И всё это понапихали в thread.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 20.02.2022 18:08 · . Предыдущая версия . Еще …
Отредактировано 20.02.2022 18:07 · . Предыдущая версия .
Re: бессмысленные интерфейсы
От: rosencrantz США  
Дата: 20.02.22 18:16
Оценка:
Здравствуйте, Codealot, Вы писали:

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

C>В этом есть какой-то тайный смысл, или они просто идиоты?

Просто идиоты конечно. Если спросить, скажут: ну чтоб гибкость, низкая связанность, на будущее
Re[2]: бессмысленные интерфейсы
От: bnk СССР http://unmanagedvisio.com/
Дата: 20.02.22 21:53
Оценка:
Здравствуйте, rosencrantz, Вы писали:

C>>В этом есть какой-то тайный смысл, или они просто идиоты?


R>Просто идиоты конечно. Если спросить, скажут: ну чтоб гибкость, низкая связанность, на будущее


Не идиоты, а просто осторожные люди. Не у всех же есть смелость сказать что король голый. Некоторым надо кормить пятерых детей
Вот как научили их так молиться, они так и будут. Интерфейсы, фабрики, все дела.
Отредактировано 20.02.2022 21:59 bnk . Предыдущая версия . Еще …
Отредактировано 20.02.2022 21:56 bnk . Предыдущая версия .
Re[7]: бессмысленные интерфейсы
От: B0FEE664  
Дата: 21.02.22 12:20
Оценка:
Здравствуйте, AlexGin, Вы писали:

AG>Прекрасно!

AG>У нас уже (с Вашей подачи) — две равнозначные сущности.
AG>Там, напомним, где в принципе достаточно одной (плюс вспомогательная: интерфейс).

Хотите одну? Вот вам одна сущность:
class node
{
  std::vector<std::shared_ptr<node>> childs;
};


AG>Я вот посмотрел и подумал — есть Node, есть SubNode.

AG>Есть Forward Declaration, которое так и не решило проблему перекрёстных ссылок.
Что такое "проблема перекрёстных ссылок"?

AG>Зачем так сложно?

Не знаю. Чем простой вариант устраивает?

AG>Почему так не-KISS-ло всё накручено?

Ну вы же сами хотели ограничить связность.

AG>Неудивительно, что это всё даже не компилируется

Вы это пытались компилировать? Зачем?

  Скрытый текст
#include <iostream>
#include <vector>
#include <memory>
#include <string>

class Node;

class SubNode // Интерфейс узла:
{
public:
    inline std::string                 GetNameOfNode() const     ;
    inline const std::vector<SubNode>& GetVectOfChilds() const   ;
    inline void                        AddNode(SubNode node)     ;
public:
    std::shared_ptr<Node> m_node;
};


class Node
{
public:
    Node(const std::string& sNameOfNode); // C-tor
   ~Node(); // D-tor
    std::string GetNameOfNode() const;
    const std::vector<SubNode>& GetVectOfChilds() const;
    void AddNode(SubNode p);
private:
    std::vector<SubNode> m_SubNodes;
};




    inline std::string                 SubNode::GetNameOfNode() const     {  return m_node->GetNameOfNode();  }
    inline const std::vector<SubNode>& SubNode::GetVectOfChilds() const   {  return m_node->GetVectOfChilds();  }
    inline void                        SubNode::AddNode(SubNode node)     {  return m_node->AddNode(node);    }        


int main() {
    std::cout << "ok\n";
    // your code goes here
    return 0;
}


AG>>>так и для тестирования основы нашего проекта.
BFE>>Про связь с тестированием я не понял.
AG>Вот насчёт тестов:
AG>https://chromium.googlesource.com/external/github.com/google/googletest/+/refs/tags/release-1.8.0/googlemock/docs/ForDummies.md
AG>https://chromium.googlesource.com/external/github.com/google/googletest/+/refs/tags/release-1.8.0/googlemock/docs/FrequentlyAskedQuestions.md#how-am-i-supposed-to-make-sense-of-these-horrible-template-errors

И где конкретно у них написано, что продакшен код надо замедлять, чтобы проще было писать тесты?
И каждый день — без права на ошибку...
Re[8]: бессмысленные интерфейсы
От: AlexGin Беларусь  
Дата: 21.02.22 19:36
Оценка:
Здравствуйте, B0FEE664, Вы писали:

BFE>Что такое "проблема перекрёстных ссылок"?

BFE>class Node
BFE>{
BFE>public:
BFE>    Node(const std::string& sNameOfNode); // C-tor
BFE>   ~Node(); // D-tor
BFE>    std::string GetNameOfNode() const;
BFE>    const std::vector<SubNode>& GetVectOfChilds() const;
BFE>    void AddNode(SubNode p);
BFE>private:
BFE>    std::vector<SubNode> m_SubNodes; // Здесь ссылаемся на объект типа SubNode
BFE>};

BFE>class SubNode // Интерфейс узла:
BFE>{
BFE>public:
BFE>    std::string                 GetNameOfNode() const     {  return m_node->GetNameOfNode();  }
BFE>    const std::vector<SubNode>& GetVectOfChilds() const   {  return m_node->GetNameOfNode();  }
BFE>    void                        AddNode(SubNode node)     {  return m_node->AddNode(node);    }        
BFE>public:
BFE>    std::shared_ptr<Node> m_node; // Здесь ссылаемся на объект типа Node
BFE>};
BFE>

Вот отсюда и _проблема_перекрёстных_ссылок_

AG>так и для тестирования основы нашего проекта.

BFE>Про связь с тестированием я не понял.
AG>Вот насчёт тестов:
AG>https://chromium.googlesource.com/external/github.com/google/googletest/+/refs/tags/release-1.8.0/googlemock/docs/ForDummies.md
AG>https://chromium.googlesource.com/external/github.com/google/googletest/+/refs/tags/release-1.8.0/googlemock/docs/FrequentlyAskedQuestions.md#how-am-i-supposed-to-make-sense-of-these-horrible-template-errors

BFE>И где конкретно у них написано, что продакшен код надо замедлять, чтобы проще было писать тесты?


Кто и где предлагал замедлять продакшн код? Что есть фактор замедления?

P.S. Если ты предполагаешь, что вызов через таблицу виртуальных функций (vtable) вносит замедление,
то для аппаратуры последних 15 лет это уже не актуально.
Отредактировано 21.02.2022 21:09 AlexGin . Предыдущая версия . Еще …
Отредактировано 21.02.2022 19:48 AlexGin . Предыдущая версия .
Отредактировано 21.02.2022 19:43 AlexGin . Предыдущая версия .
Отредактировано 21.02.2022 19:37 AlexGin . Предыдущая версия .
Re[2]: бессмысленные интерфейсы
От: maxkar  
Дата: 21.02.22 22:16
Оценка: +1 -1
Здравствуйте, Aquilaware, Вы писали:

A>Так иногда делают чтобы отделить интерфейс от реализации. Представьте, что есть очень жирный и большой класс, и это несмотря на то, что у него всего лишь два публичных метода. А теперь задача — найти среди этих тысяч строк реализации одгого класса чего же от него могут хотеть те, кто его используют.

A>Это становится похоже на поиск иголок в стоге сена — и по времени и по ментальным трудозатратам. Вот тогда иногда и делают отдельный интерфейс, который строго завляет — нужно только 2 таких вот метода.

Угу. А через несколько лет захочется добавить классу публичный метод. И вот тут становится интересно. Что, если это разработчики-затейники сделали еще 5 реализаций этого интерфейса? Во всех них придется реализовывать это метод. Ровно ту же самую проблему решает абстрактный класс с конструктором пакетной видимости (не protected и не public). В результате на грабли интерфейса наступить просто не получится. Да и метод можно будет при необходимости легко добавить.

Там же (в Practical API Design: Confessions of a Java Framework Architect) вообще рекомендуется использовать классы (абстрактные и нет) для функциональности, предоставляемой (provided) библиотекой. А интерфейсы — для функциональности, требуемой (required) библиотекой. Как обычно, исключения — всякие коллекции и прочее "API общего пользования".
Re[3]: бессмысленные интерфейсы
От: baxton_ulf США  
Дата: 21.02.22 23:17
Оценка: +1
Здравствуйте, maxkar, Вы писали:


M>Угу. А через несколько лет захочется добавить классу публичный метод. И вот тут становится интересно. Что, если это разработчики-затейники сделали еще 5 реализаций этого интерфейса? Во всех них придется реализовывать это метод. Ровно ту же самую проблему решает абстрактный класс с конструктором пакетной видимости (не protected и не public). В результате на грабли интерфейса наступить просто не получится. Да и метод можно будет при необходимости легко добавить.


чего? ты понимаешь, что интерфейс это контракт? его не меняют (очень редко и то если изменение аддитивно и не ломает обратную совместимость). если надо добавить метод, то создают новый интерфейс. интерфейс позволяет отвязаться от реализации — это никакой абстрактный класс не решит. а абстрактные классы позволяют избежать дублирования кода в реализациях.
и да не все классы должны иметь выделенный интерфейс,
и да надо хорошо думать прежде чем создавать интерфейс.
Re[9]: бессмысленные интерфейсы
От: B0FEE664  
Дата: 23.02.22 15:37
Оценка:
Здравствуйте, AlexGin, Вы писали:

BFE>>Что такое "проблема перекрёстных ссылок"?

AG>
BFE>>class Node
BFE>>{
BFE>>public:
BFE>>    Node(const std::string& sNameOfNode); // C-tor
BFE>>   ~Node(); // D-tor
BFE>>    std::string GetNameOfNode() const;
BFE>>    const std::vector<SubNode>& GetVectOfChilds() const;
BFE>>    void AddNode(SubNode p);
BFE>>private:
BFE>>    std::vector<SubNode> m_SubNodes; // Здесь ссылаемся на объект типа SubNode
BFE>>};

BFE>>class SubNode // Интерфейс узла:
BFE>>{
BFE>>public:
BFE>>    std::string                 GetNameOfNode() const     {  return m_node->GetNameOfNode();  }
BFE>>    const std::vector<SubNode>& GetVectOfChilds() const   {  return m_node->GetNameOfNode();  }
BFE>>    void                        AddNode(SubNode node)     {  return m_node->AddNode(node);    }        
BFE>>public:
BFE>>    std::shared_ptr<Node> m_node; // Здесь ссылаемся на объект типа Node
BFE>>};
BFE>>
AG>

AG>Вот отсюда и _проблема_перекрёстных_ссылок_
Нет тут никакой проблемы. Просто следует отделять декларации от имплементации, как это сделано постом выше.

AG>>так и для тестирования основы нашего проекта.

BFE>>Про связь с тестированием я не понял.
AG>>Вот насчёт тестов:
AG>>https://chromium.googlesource.com/external/github.com/google/googletest/+/refs/tags/release-1.8.0/googlemock/docs/ForDummies.md
AG>>https://chromium.googlesource.com/external/github.com/google/googletest/+/refs/tags/release-1.8.0/googlemock/docs/FrequentlyAskedQuestions.md#how-am-i-supposed-to-make-sense-of-these-horrible-template-errors

BFE>>И где конкретно у них написано, что продакшен код надо замедлять, чтобы проще было писать тесты?

AG>Кто и где предлагал замедлять продакшн код? Что есть фактор замедления?
AG>

Если приходится изменять код, чтобы подстроится под тесты, значит с тестами что-то не так.

AG>P.S. Если ты предполагаешь, что вызов через таблицу виртуальных функций (vtable) вносит замедление,

AG>то для аппаратуры последних 15 лет это уже не актуально.
Это память не актуальна, а вот скорость... Всё так же тормозят приложения и системы.
И каждый день — без права на ошибку...
Re[10]: бессмысленные интерфейсы
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.22 12:16
Оценка: +1
Здравствуйте, B0FEE664, Вы писали:

BFE>Если приходится изменять код, чтобы подстроится под тесты, значит с тестами что-то не так.


Нисколько. Тестопригодность всегда закладывается в код. Вот если этого нет, то в приложении проблема и не одна.
Re[13]: бессмысленные интерфейсы
От: Codealot Земля  
Дата: 09.03.22 15:26
Оценка:
Здравствуйте, elmal, Вы писали:

E>Некоторых фичей сейчас реально не хватает.


Каких?
Ад пуст, все бесы здесь.
Re[14]: бессмысленные интерфейсы
От: elmal  
Дата: 09.03.22 15:46
Оценка: 2 (2)
Здравствуйте, Codealot, Вы писали:

C>Каких?

Intersection types, например, да и Union Types бы не помешали, с возможностями по ним матчиться и с автоматической проверкой вариантов на полноту при компиляции и даже раньше. list comprehension тоже не хватает, я конечно умею это все делать через стримы и map, но это получается через задницу и не красиво. Полноценные tuples с удобной деструктуризацией и тому подобное. В среде разработки не хватает возможности получить список всех ошибок и проблем всего проекта отдельной вкладке problems (сейчас есть такое только по одному текущему файлу, а я привык что такое возможно по всему проекту). Не хватает возможности перехода по val или var на соответствующий тип при нажатии ctrl и мышкой на нем в IDEA (в свое время я был инициатором этого feature request). Это навскидку, я уж забыл чего мне не хватает .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.