Сообщение Re[14]: .net core и async lock от 08.04.2021 11:04
Изменено 08.04.2021 11:05 vdimas
Re[14]: .net core и async lock
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Кошмар. ))
V>>С каких пор непрозрачные типы стали "кишками"?
НС>Ответить на вопрос можешь? При чем тут OCP, если ты предлагаешь приватное поле сделать публичным?
OCP-принцип вляется комбинацией критериев Low Coupling/High Cohesion и Protected Variantions.
В том дизайне приватное поле только одно, всё вместе выглядит как фасад над объектом, который уже обладает нужной функциональностью.
Причём, объект "инфраструктурный", т.е. не тянет за собой лишние зависимости, т.к. эти зависимости уже есть "изкаробки".
Плюс объект вряд ли будет выставляться в публичном АПИ использующего его кода, т.е., согласно твоей терминологии, оно и так всё вместе — "кишки".
В таких ситуациях в некоторых ООП-языках уместно защищённое наследование и расширение функциональности, но в полном компромиссов дотнете есть так же инструмент методов-расширений, пригодный для реализации принципов OCP. Плюс к этому "обертки" в дотнете не бесплатны, порождают +1 косвенность на каждом уровне.
V>>И как ты умудрился скипнуть упоминание концептов
НС>Это не имеет отношения к обсуждаемому вопросу, очередное проявление твоей привычки растекаться мысью по древу. У меня не так много времени чтобы писать на твои винегретные простыни подробные ответы.
Я на это уже отвечал — если зашла речь о возможных различных реализациях, то эти реализации могут понадобиться независимо, а не во взаимно-исключительном виде, как ты рассуждал о "подменить реализацию". Ну и, над неким множеством близких по функциональности объектов допустимо рассуждать о "концептах".
V>>Остальное ("попробуй доказать", "кишки" и т.д.) выглядит как виденная уже не раз специфическая реакция даже на малейшую критику.
НС>А твой ответ выглядит как слив и неспособность аргументировать безаппеляционные заявления, да еще и с хамским переходом на личности.
По дизайну был, скорее, вопрос.
Зато насчёт тяжеловесности реализации SemaphoreSlim — тут да, утверждение. Но я его раскрыл, т.е. на безапелляционность утверждение не тянет — несогласные могут аргументировать.
И не вы же SemaphoreSlim разрабатывали, т.е. так близко принимать было не обязательно. ))
Просто опять нарвался на специфическую ответную "аргументацию".
ОК, забей.
На досуге нарисую легковесную реализацию и выложу сюда, т.к. судя по активности коллег оно может быть народу полезно.
Заодно покажет, как тяжеловесные Task-и можно подменять обычными колбэками (делегатами), которые и так уже подаются state-машинкой в awaiter, т.е. доп. накладных расходов можно избежать практически полностью.
V>>Кошмар. ))
V>>С каких пор непрозрачные типы стали "кишками"?
НС>Ответить на вопрос можешь? При чем тут OCP, если ты предлагаешь приватное поле сделать публичным?
OCP-принцип вляется комбинацией критериев Low Coupling/High Cohesion и Protected Variantions.
В том дизайне приватное поле только одно, всё вместе выглядит как фасад над объектом, который уже обладает нужной функциональностью.
Причём, объект "инфраструктурный", т.е. не тянет за собой лишние зависимости, т.к. эти зависимости уже есть "изкаробки".
Плюс объект вряд ли будет выставляться в публичном АПИ использующего его кода, т.е., согласно твоей терминологии, оно и так всё вместе — "кишки".
В таких ситуациях в некоторых ООП-языках уместно защищённое наследование и расширение функциональности, но в полном компромиссов дотнете есть так же инструмент методов-расширений, пригодный для реализации принципов OCP. Плюс к этому "обертки" в дотнете не бесплатны, порождают +1 косвенность на каждом уровне.
V>>И как ты умудрился скипнуть упоминание концептов
НС>Это не имеет отношения к обсуждаемому вопросу, очередное проявление твоей привычки растекаться мысью по древу. У меня не так много времени чтобы писать на твои винегретные простыни подробные ответы.
Я на это уже отвечал — если зашла речь о возможных различных реализациях, то эти реализации могут понадобиться независимо, а не во взаимно-исключительном виде, как ты рассуждал о "подменить реализацию". Ну и, над неким множеством близких по функциональности объектов допустимо рассуждать о "концептах".
V>>Остальное ("попробуй доказать", "кишки" и т.д.) выглядит как виденная уже не раз специфическая реакция даже на малейшую критику.
НС>А твой ответ выглядит как слив и неспособность аргументировать безаппеляционные заявления, да еще и с хамским переходом на личности.
По дизайну был, скорее, вопрос.
Зато насчёт тяжеловесности реализации SemaphoreSlim — тут да, утверждение. Но я его раскрыл, т.е. на безапелляционность утверждение не тянет — несогласные могут аргументировать.
И не вы же SemaphoreSlim разрабатывали, т.е. так близко принимать было не обязательно. ))
Просто опять нарвался на специфическую ответную "аргументацию".
ОК, забей.
На досуге нарисую легковесную реализацию и выложу сюда, т.к. судя по активности коллег оно может быть народу полезно.
Заодно покажет, как тяжеловесные Task-и можно подменять обычными колбэками (делегатами), которые и так уже подаются state-машинкой в awaiter, т.е. доп. накладных расходов можно избежать практически полностью.
Re[14]: .net core и async lock
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Кошмар. ))
V>>С каких пор непрозрачные типы стали "кишками"?
НС>Ответить на вопрос можешь? При чем тут OCP, если ты предлагаешь приватное поле сделать публичным?
OCP-принцип вляется комбинацией критериев Low Coupling/High Cohesion и Protected Variantions.
В том дизайне приватное поле только одно, всё вместе выглядит как фасад над объектом, который уже обладает нужной функциональностью.
Причём, объект "инфраструктурный", т.е. не тянет за собой лишние зависимости, т.к. эти зависимости уже есть "изкаробки".
Плюс объект вряд ли будет выставляться в публичном АПИ использующего его кода, т.е., согласно твоей терминологии, оно и так всё вместе — "кишки".
В таких ситуациях в некоторых ООП-языках уместно защищённое наследование и расширение функциональности, но в полном компромиссов дотнете есть так же инструмент методов-расширений, пригодный для реализации принципов OCP. Плюс к этому "обертки" в дотнете не бесплатны, порождают +1 косвенность на каждом уровне, т.е. еще один аргумент в пользу методов-расширений.
V>>И как ты умудрился скипнуть упоминание концептов
НС>Это не имеет отношения к обсуждаемому вопросу, очередное проявление твоей привычки растекаться мысью по древу. У меня не так много времени чтобы писать на твои винегретные простыни подробные ответы.
Я на это уже отвечал — если зашла речь о возможных различных реализациях, то эти реализации могут понадобиться независимо, а не во взаимно-исключительном виде, как ты рассуждал о "подменить реализацию". Ну и, над неким множеством близких по функциональности объектов допустимо рассуждать о "концептах".
V>>Остальное ("попробуй доказать", "кишки" и т.д.) выглядит как виденная уже не раз специфическая реакция даже на малейшую критику.
НС>А твой ответ выглядит как слив и неспособность аргументировать безаппеляционные заявления, да еще и с хамским переходом на личности.
По дизайну был, скорее, вопрос.
Зато насчёт тяжеловесности реализации SemaphoreSlim — тут да, утверждение. Но я его раскрыл, т.е. на безапелляционность утверждение не тянет — несогласные могут аргументировать.
И не вы же SemaphoreSlim разрабатывали, т.е. так близко принимать было не обязательно. ))
Просто опять нарвался на специфическую ответную "аргументацию".
ОК, забей.
На досуге нарисую легковесную реализацию и выложу сюда, т.к. судя по активности коллег оно может быть народу полезно.
Заодно покажет, как тяжеловесные Task-и можно подменять обычными колбэками (делегатами), которые и так уже подаются state-машинкой в awaiter, т.е. доп. накладных расходов можно избежать практически полностью.
V>>Кошмар. ))
V>>С каких пор непрозрачные типы стали "кишками"?
НС>Ответить на вопрос можешь? При чем тут OCP, если ты предлагаешь приватное поле сделать публичным?
OCP-принцип вляется комбинацией критериев Low Coupling/High Cohesion и Protected Variantions.
В том дизайне приватное поле только одно, всё вместе выглядит как фасад над объектом, который уже обладает нужной функциональностью.
Причём, объект "инфраструктурный", т.е. не тянет за собой лишние зависимости, т.к. эти зависимости уже есть "изкаробки".
Плюс объект вряд ли будет выставляться в публичном АПИ использующего его кода, т.е., согласно твоей терминологии, оно и так всё вместе — "кишки".
В таких ситуациях в некоторых ООП-языках уместно защищённое наследование и расширение функциональности, но в полном компромиссов дотнете есть так же инструмент методов-расширений, пригодный для реализации принципов OCP. Плюс к этому "обертки" в дотнете не бесплатны, порождают +1 косвенность на каждом уровне, т.е. еще один аргумент в пользу методов-расширений.
V>>И как ты умудрился скипнуть упоминание концептов
НС>Это не имеет отношения к обсуждаемому вопросу, очередное проявление твоей привычки растекаться мысью по древу. У меня не так много времени чтобы писать на твои винегретные простыни подробные ответы.
Я на это уже отвечал — если зашла речь о возможных различных реализациях, то эти реализации могут понадобиться независимо, а не во взаимно-исключительном виде, как ты рассуждал о "подменить реализацию". Ну и, над неким множеством близких по функциональности объектов допустимо рассуждать о "концептах".
V>>Остальное ("попробуй доказать", "кишки" и т.д.) выглядит как виденная уже не раз специфическая реакция даже на малейшую критику.
НС>А твой ответ выглядит как слив и неспособность аргументировать безаппеляционные заявления, да еще и с хамским переходом на личности.
По дизайну был, скорее, вопрос.
Зато насчёт тяжеловесности реализации SemaphoreSlim — тут да, утверждение. Но я его раскрыл, т.е. на безапелляционность утверждение не тянет — несогласные могут аргументировать.
И не вы же SemaphoreSlim разрабатывали, т.е. так близко принимать было не обязательно. ))
Просто опять нарвался на специфическую ответную "аргументацию".
ОК, забей.
На досуге нарисую легковесную реализацию и выложу сюда, т.к. судя по активности коллег оно может быть народу полезно.
Заодно покажет, как тяжеловесные Task-и можно подменять обычными колбэками (делегатами), которые и так уже подаются state-машинкой в awaiter, т.е. доп. накладных расходов можно избежать практически полностью.