Здравствуйте, ·, Вы писали:
·>Может и протягивает там где протягивается... Но думаю это легко может поломаться, если использовать какую-нибудь необычную передачу данных между тредами. В любом случае, по-моему это будет очень весело разбираться если что-то где-то не так протащится. Вместо одной глобальной переменной, у нас теперь неожиданно целая их коллекция.
Практика показывает, что твои думы это что то вроде ветряных мельниц.
Вроде что-то улучшили в 4.6. Но всё равно явно корявая архитектура. _Переменные_ не стоит делать глобальными. Thread local нужен совсем для другого. Ну может кеш какой-нибудь или типа того, но нельзя там хранить изменяемое состояние.
А ещё этот идиотизм с двумя переменными Thread.CurrentUICulture и Thread.CurrentCulture. И всё это понапихали в thread.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Codealot, Вы писали:
C>Некоторые люди делают для каждого класса по интерфейсу и фабрике чтобы создавать объекты, причем каждый интерфейс реализован ровно в одном классе. C>В этом есть какой-то тайный смысл, или они просто идиоты?
Просто идиоты конечно. Если спросить, скажут: ну чтоб гибкость, низкая связанность, на будущее
Здравствуйте, rosencrantz, Вы писали:
C>>В этом есть какой-то тайный смысл, или они просто идиоты?
R>Просто идиоты конечно. Если спросить, скажут: ну чтоб гибкость, низкая связанность, на будущее
Не идиоты, а просто осторожные люди. Не у всех же есть смелость сказать что король голый. Некоторым надо кормить пятерых детей
Вот как научили их так молиться, они так и будут. Интерфейсы, фабрики, все дела.
Здравствуйте, AlexGin, Вы писали: AG>Прекрасно! AG>У нас уже (с Вашей подачи) — две равнозначные сущности. AG>Там, напомним, где в принципе достаточно одной (плюс вспомогательная: интерфейс).
Хотите одну? Вот вам одна сущность:
class node
{
std::vector<std::shared_ptr<node>> childs;
};
AG>Я вот посмотрел и подумал — есть Node, есть SubNode. AG>Есть Forward Declaration, которое так и не решило проблему перекрёстных ссылок.
Что такое "проблема перекрёстных ссылок"? AG>Зачем так сложно?
Не знаю. Чем простой вариант устраивает? AG>Почему так не-KISS-ло всё накручено?
Ну вы же сами хотели ограничить связность. AG>Неудивительно, что это всё даже не компилируется
Вы это пытались компилировать? Зачем?
Кто и где предлагал замедлять продакшн код? Что есть фактор замедления?
P.S. Если ты предполагаешь, что вызов через таблицу виртуальных функций (vtable) вносит замедление,
то для аппаратуры последних 15 лет это уже не актуально.
Здравствуйте, Aquilaware, Вы писали:
A>Так иногда делают чтобы отделить интерфейс от реализации. Представьте, что есть очень жирный и большой класс, и это несмотря на то, что у него всего лишь два публичных метода. А теперь задача — найти среди этих тысяч строк реализации одгого класса чего же от него могут хотеть те, кто его используют. A>Это становится похоже на поиск иголок в стоге сена — и по времени и по ментальным трудозатратам. Вот тогда иногда и делают отдельный интерфейс, который строго завляет — нужно только 2 таких вот метода.
Угу. А через несколько лет захочется добавить классу публичный метод. И вот тут становится интересно. Что, если это разработчики-затейники сделали еще 5 реализаций этого интерфейса? Во всех них придется реализовывать это метод. Ровно ту же самую проблему решает абстрактный класс с конструктором пакетной видимости (не protected и не public). В результате на грабли интерфейса наступить просто не получится. Да и метод можно будет при необходимости легко добавить.
Там же (в Practical API Design: Confessions of a Java Framework Architect) вообще рекомендуется использовать классы (абстрактные и нет) для функциональности, предоставляемой (provided) библиотекой. А интерфейсы — для функциональности, требуемой (required) библиотекой. Как обычно, исключения — всякие коллекции и прочее "API общего пользования".
M>Угу. А через несколько лет захочется добавить классу публичный метод. И вот тут становится интересно. Что, если это разработчики-затейники сделали еще 5 реализаций этого интерфейса? Во всех них придется реализовывать это метод. Ровно ту же самую проблему решает абстрактный класс с конструктором пакетной видимости (не protected и не public). В результате на грабли интерфейса наступить просто не получится. Да и метод можно будет при необходимости легко добавить.
чего? ты понимаешь, что интерфейс это контракт? его не меняют (очень редко и то если изменение аддитивно и не ломает обратную совместимость). если надо добавить метод, то создают новый интерфейс. интерфейс позволяет отвязаться от реализации — это никакой абстрактный класс не решит. а абстрактные классы позволяют избежать дублирования кода в реализациях.
и да не все классы должны иметь выделенный интерфейс,
и да надо хорошо думать прежде чем создавать интерфейс.
Если приходится изменять код, чтобы подстроится под тесты, значит с тестами что-то не так.
AG>P.S. Если ты предполагаешь, что вызов через таблицу виртуальных функций (vtable) вносит замедление, AG>то для аппаратуры последних 15 лет это уже не актуально.
Это память не актуальна, а вот скорость... Всё так же тормозят приложения и системы.
Здравствуйте, Codealot, Вы писали:
C>Каких?
Intersection types, например, да и Union Types бы не помешали, с возможностями по ним матчиться и с автоматической проверкой вариантов на полноту при компиляции и даже раньше. list comprehension тоже не хватает, я конечно умею это все делать через стримы и map, но это получается через задницу и не красиво. Полноценные tuples с удобной деструктуризацией и тому подобное. В среде разработки не хватает возможности получить список всех ошибок и проблем всего проекта отдельной вкладке problems (сейчас есть такое только по одному текущему файлу, а я привык что такое возможно по всему проекту). Не хватает возможности перехода по val или var на соответствующий тип при нажатии ctrl и мышкой на нем в IDEA (в свое время я был инициатором этого feature request). Это навскидку, я уж забыл чего мне не хватает .