powered by simpleCommunicator - 2.0.36     © 2025 Programmizd 02
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / IDisposable и структуры
25 сообщений из 109, страница 3 из 5
IDisposable и структуры
    #40026181
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
hVostt
Где плохо?

В том же твоем любимом Stream

Но, конечно, ты сейчас скажешь, что это просто из-за того, что его рукожопы делали


Ну так наследование здесь при чём? Оно как раз позволяет работать максимально рукожопому контракту.
Т.е. благодаря наследованию эта хреновина едет :)

Может есть какой-то из собственной практики пример?
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026183
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Нет, если ты так искренне считаешь, значит наследование не понимаешь в принципе.

Значит я в хорошей компании
https://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков Саттер и Александреску в своём руководстве по использованию C++ для выражения этого принципа также используют фразу «подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый класс». По мнению данных авторов, публичное наследование в C++ можно употреблять только тогда, когда оно удовлетворяет принципу Лисков. Приватное наследование, по их же мнению, дозволено использовать для доступа к protected части базы и перекрытия виртуальных методов. В любом же ином случае, то есть для всего лишь повторного использования кода из базы, наследование применять нельзя.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026187
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Ну так наследование здесь при чём?

При том, что если бы вместо одного здоровенного базового класса его API грамотно раскидали бы по интерфейсам, то его реализации не напоминали бы хоспинс для калек - у одного нога не гнется, у другого рука не разгибается, а третий глухослепой
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026194
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
Значит я в хорошей компании
https://ru.wikipedia.org/wiki/Принцип_подстановки_Барбары_Лисков Саттер и Александреску в своём руководстве по использованию C++ для выражения этого принципа также используют фразу «подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый класс». По мнению данных авторов, публичное наследование в C++ можно употреблять только тогда, когда оно удовлетворяет принципу Лисков. Приватное наследование, по их же мнению, дозволено использовать для доступа к protected части базы и перекрытия виртуальных методов. В любом же ином случае, то есть для всего лишь повторного использования кода из базы, наследование применять нельзя.


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

Откуда ноги растут у выражения "предпочтите агрегацию наследованию"? Как раз из-за вброса в массы неправильных трактовок.

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


fkthat
При том, что если бы вместо одного здоровенного базового класса его API грамотно раскидали бы по интерфейсам, то его реализации не напоминали бы хоспинс для калек - у одного нога не гнется, у другого рука не разгибается, а третий глухослепой


Нет, так это не работает. Ты можешь выразить интерфейсом минимальный контракт и реализовать несколько.

Но ожидать конкретный набор интерфейсов -- не можешь.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026198
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Если у тебя +100500 сущностей и у всех есть поле Id, то разумно сделать базовый класс и не дублировать одно и то же.

1) Дублирование одного поля заменяем дублированием объявления наследования. Еще и с тем геммором, что если я вижу в каком-то незнакомом классе свойство, то я вижу свойство, а если я вижу какой-то неизветсный мне базовый класс, то мне еще придется полезть и посмотреть, что это за херь такая.

2) Я неожиданно обнаруживаю, что в каком-то единственном классе мне надо поменять поведение свойства Id (допустим, не дать туда писать числа которые не делятся на десять). Попадос.

3) Я очень даже всеми тремя руками за то, чтобы использовать наследование в моделях данных ORM, но я все время вижу, как творческие творцы творят полдюжины совершенно несвязанных полностью разных сущностей для какой-нибудь, допустим, полудюжины разных типов контрагентов, но зато пихают в модель всевозможную базовую херь наподобии EntityWitrhId, EntityCanBeDeleted, и EntityWithCreationDate. Оно и понятно, как я уже и говорил. Чтобы понять что есть общего, а что есть разного, допустим, у контрагента-юрлица и контрагента-физлица это нужны уже какие-то зачатки мышления и анализа, а чтобы написать какой-нибудь EntityWithIdCreationDateAndCanBeFukkingDeleted который в три строки кода, для этого достаточно прочитать книгу "Освой EntityFramework за четыре туалета по-большому".

hVostt
Но большиство расширений для того же string -- полезны.
Кроме существующих линкьюшных расширений (которые и не расширения самого string вовсе) ничего полезного в голову вообще не приходит. Все эти расширения string, что я видел были полной херотой. Например, самодельный вариант поиска подстроки, который который отличался от встроенного только тем, что вместо возврата -1 при неудаче кидал какой-то самодельный exception.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026204
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
hVostt
Если у тебя +100500 сущностей и у всех есть поле Id, то разумно сделать базовый класс и не дублировать одно и то же.

1) Дублирование одного поля заменяем дублированием объявления наследования. Еще и с тем геммором, что если я вижу в каком-то незнакомом классе свойство, то я вижу свойство, а если я вижу какой-то неизветсный мне базовый класс, то мне еще придется полезть и посмотреть, что это за херь такая.


Дело не только в этом. Теперь можно принимать базовый тип сущности и работать с идентификатором. Много чего можно делать.

fkthat
2) Я неожиданно обнаруживаю, что в каком-то единственном классе мне надо поменять поведение свойства Id (допустим, не дать туда писать числа которые не делятся на десять). Попадос.


К наследованию это не имеет отношения. Это может случиться где угодно. Например, ты возвращал IEnumerable из функции. И вдруг в одном случае тебе понадобилось получать число :)

fkthat
3) Я очень даже всеми тремя руками за то, чтобы использовать наследование в моделях данных ORM, но я все время вижу, как творческие творцы творят полдюжины совершенно несвязанных полностью разных сущностей для какой-нибудь, допустим, полудюжины разных типов контрагентов, но зато пихают в модель всевозможную базовую херь наподобии EntityWitrhId, EntityCanBeDeleted, и EntityWithCreationDate. Оно и понятно, как я уже и говорил. Чтобы понять что есть общего, а что есть разного, допустим, у контрагента-юрлица и контрагента-физлица это нужны уже какие-то зачатки мышления и анализа, а чтобы написать какой-нибудь EntityWithIdCreationDateAndCanBeFukkingDeleted который в три строки кода, для этого достаточно прочитать книгу "Освой EntityFramework за четыре туалета по-большому".


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

Ни Барбара Лисков, ни Эрик Липман, ни Рихтер, никто :)

Если я правильно понял, ведь твой посыл именно в этом. Не красиво, не очень, грязно. Ну всё так. Ты причины не там ищешь просто :)


fkthat
hVostt
Но большиство расширений для того же string -- полезны.
Кроме существующих линкьюшных расширений (которые и не расширения самого string вовсе) ничего полезного в голову вообще не приходит. Все эти расширения string, что я видел были полной херотой. Например, самодельный вариант поиска подстроки, который который отличался от встроенного только тем, что вместо возврата -1 при неудаче кидал какой-то самодельный exception.


Ну почему же.

Сравни:

string.IsNullOrEmpty(myString) vs myString.IsEmty()

проблема в том, что они не стандартизованы, называются и работают по-разному в проектах.
это фигово. но в целом, в рамках большого проекта они так или иначе создаются, потому что люди хотят облегчить себе жизнь.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026205
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat,

Насчёт дублирования кода. Не только сам код, но и весь обвес:

1. Комментарии, документация
2. Тесты
3. Расширения

и т.д.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026206
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Но ожидать конкретный набор интерфейсов -- не можешь.

В совершенно произвольном случае, когда незнамо откуда прилетело незнамо что, да это невозможно. Но, я могу запросить нужный интерфейс приведением от одного интерфейса к другому, проверить на null и если ок, то уже делать с ним то что надо. Аналогия с COM - когда тебе нужен какой-то API компонента ты явно запрашиваешь именно этот API. А не получаешь один гигантский API, где стопятьсяот методов из которых только три работают, а сточетырестадевяностосемь возвращают "NotSupported".
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026212
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
myString.IsEmty()

Я напишу просто в коде myString == "" и над моим кодом никто не будет дрочить себе мозг. А про myString.IsEmty() я уже сразу мозг вздрочнул, например, тем, что если myString это null, то кинет ли он ексепшен или вернет false, или его вовсе кто-то написал просто не зная, что есть готовый IsNullOrEmpty и он вернет мне true.

Кстати, в шарп-9 новая бомба-фича :))
Код: c#
1.
2.
var s = "foo";
var isNullOrEmptyOrFooBar = s is null or "" or "foo" or "bar";
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026218
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Или можно даже так:
Код: c#
1.
2.
var x = 57;
var isDigitOr42 = x is (> -1 and < 10) or 42;
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026301
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
Я напишу просто в коде myString == "" и над моим кодом никто не будет дрочить себе мозг.


(myString ?? "") == "" или (myString ?? "").Length == 0

Но да, с этим согласен, такой код хоть и страшненький, но лучше читается, чем чужие неведомые расширения.

Однако в рамках большого проекта и команды, никакой трагедии в расширениях нет. Всё с этим ок, не нужно драматизировать :)

fkthat
Кстати, в шарп-9 новая бомба-фича :))
Код: c#
1.
2.
var s = "foo";
var isNullOrEmptyOrFooBar = s is null or "" or "foo" or "bar";



Да как сказать... в свиче да, как рядовое использование пока не видится особого профита.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026417
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
такой код хоть и страшненький

Я же показал, как написать красиво
Код: c#
1.
2.
3.
4.
if(myString is null or "")
{
    ...
}

Это такой новый синтаксис в 9 - годится для любого выражения, не только для matching pattern.

hVostt
в свиче да
Свич занесен в энциклопедию говнокода
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026423
Фотография Shocker.Pro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
Код: c#
1.
var isNullOrEmptyOrFooBar = s is null or "" or "foo" or "bar";

это прям VB какой-то
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026434
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
Я же показал, как написать красиво
Код: c#
1.
2.
3.
4.
if(myString is null or "")
{
    ...
}


Это такой новый синтаксис в 9 - годится для любого выражения, не только для matching pattern.


Что ж тут красивого-то? )

and/or -- в сишном синтаксисе, это ж как в футбоке с Биланом зайти в байкерсий бар

А проверь теперь, что строка не содержит только пустые символы ещё.


fkthat
hVostt
в свиче да
Свич занесен в энциклопедию говнокода


Ну это у нас уже тут был срач по поводу визитора :)
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026435
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shocker.Pro
fkthat
Код: c#
1.
var isNullOrEmptyOrFooBar = s is null or "" or "foo" or "bar";


это прям VB какой-то


Во-во ))
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026470
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Ну это у нас уже тут был срач по поводу визитора :)

"Визитор" и "комманд" для дотнет это два говнопаттерна, потому что с ними ты начинаешь нагружать объект чужими обязаностями. Но во времена це с крестами это было меньшее зло, т.к. не было ни вменяемого RTTI, ни безопасного приведения типов, поэтому и приходилось применять идиому "двойной передачи" (double dispatch) на которой визитор/комманд по сути основаны.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026472
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shocker.Pro
это прям VB какой-то

Но, авторВо-первых, это красиво.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026584
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
hVostt
Ну это у нас уже тут был срач по поводу визитора :)

"Визитор" и "комманд" для дотнет это два говнопаттерна, потому что с ними ты начинаешь нагружать объект чужими обязаностями. Но во времена це с крестами это было меньшее зло, т.к. не было ни вменяемого RTTI, ни безопасного приведения типов, поэтому и приходилось применять идиому "двойной передачи" (double dispatch) на которой визитор/комманд по сути основаны.


При чём тут двойная передача? Ты указал на проблему switch-а, визитор её решает.
Хотя функциональщики тебя не поддержат.

Т.е. ты в какой-то непонятной позиции )))
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026620
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Ты указал на проблему switch-а, визитор её решает.

Он её решает ущербным способом.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026623
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
При чём тут двойная передача?

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
Handler handler = new();
Command cmd1 = new FooCommand();
Command cmd2 = new BarCommand();
handler.HandleCommand(cmd1);
handler.HandleCommand(cmd2);

internal abstract class Command
{
    public abstract void Execute(Handler handler);
}

internal class FooCommand : Command
{
    public override void Execute(Handler handler) =>
        handler.HandleCommand(this);
}

internal class BarCommand : Command
{
    public override void Execute(Handler handler) =>
        handler.HandleCommand(this);
}

internal class Handler
{
    public void HandleCommand(Command command) =>
        command.Execute(this);

    public void HandleCommand(FooCommand command) =>
        Console.WriteLine("Handle Foo command.");

    public void HandleCommand(BarCommand command) =>
        Console.WriteLine("Handle Bar command.");
}


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

Кривость в том, что при этом получается, что у меня не кот пьет из миски, а, наоборот, миска поит кота.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026631
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
hVostt
Ты указал на проблему switch-а, визитор её решает.

Он её решает ущербным способом.


Так в чём ущербность-то? Не совсем понятно.

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


Это давно известный боян из плюсов, описанный ещё АА.


fkthat
Кривость в том, что при этом получается, что у меня не кот пьет из миски, а, наоборот, миска поит кота.


Нифига подобного.

Ты можешь визитор заменить свитчем. Но поимеешь тех самых проблем, о которых упоминал.

Или у тебя есть идеи по-лучше свича, но не-визитор? Поделись.
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026635
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Поделись.

Ты угораешь или всерьез не можешь свич без свича сделать?

Простейший вариант за пару минут на коленке:
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
ICommandHandlerFactory factory = new CommandHandlerFactory()
    .AddHandler<FooCommand, FooCommandHandler>();

Command cmd = new FooCommand();
var handler = factory.GetCommandHandler(cmd.GetType());
handler.HandleCommand(cmd);

internal interface ICommandHandlerFactory
{
    ICommandHandler GetCommandHandler(Type commandType);
}

internal interface ICommandHandler
{
    void HandleCommand(Command command);
}

internal abstract class Command
{
}

internal class FooCommand : Command
{
}

internal class FooCommandHandler : ICommandHandler
{
    public void HandleCommand(Command command) =>
        HandleCommand(command as FooCommand ??
            throw new ArgumentException("Invalid command type", nameof(command)));

    private void HandleCommand(FooCommand command) =>
        Console.Write("Handle FooCommand");
}

internal class CommandHandlerFactory : ICommandHandlerFactory
{
    private readonly Dictionary<Type, Func<ICommandHandler>> _factories = new();

    public ICommandHandler GetCommandHandler(Type commandType)
    {
        return _factories.TryGetValue(commandType, out var f) ?
            f() : throw new ArgumentException("Invalid type", nameof(commandType));
    }

    public CommandHandlerFactory AddHandler<TCommand, THandler>()
        where THandler : ICommandHandler, new()
    {
        _factories.Add(typeof(TCommand), () => new THandler());
        return this;
    }
}

...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026641
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Так в чём ущербность-то? Не совсем понятно.
Написал же ниже - миска поит кота.

hVostt
Это давно известный боян из плюсов, описанный ещё АА.
Понятно, что я его не сам изобрел - если бы я его изобрел, то, возможно, и работал бы с АА, а не с мудятлами, которые object.IsNull() создают
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026652
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
fkthat
Ты угораешь или всерьез не можешь свич без свича сделать?

Простейший вариант за пару минут на коленке:


Ты сварганил "на коленке" медиатор. Это другой паттерн и решает другие задачи.

Если провести параллель, то своей сути это тот же свитч и те же проблемы.

Можно добавить команду и забыть создать/зарегистрировать хендлер — получишь ошибку в рантайме.
Заменить пакет хендлеров, чтобы в разных случаев разные применять — нифига не выйдет.

В визитёре этих проблем нет.


fkthat
hVostt
Так в чём ущербность-то? Не совсем понятно.
Написал же ниже - миска поит кота.


Нет, ты по сути говоришь "квадратное лучше круглого". Разные вещи сравниваешь.
Ты реши задачи свитч/визитёр, на не предлагай решение для совершенно других задач.

fkthat
Понятно, что я его не сам изобрел - если бы я его изобрел, то, возможно, и работал бы с АА, а не с мудятлами, которые object.IsNull() создают


Хм, а сможешь ответить на вопрос, когда расширение IsNull() действительно может принести пользу?
Я -- могу :)
...
Рейтинг: 0 / 0
IDisposable и структуры
    #40026716
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt
Ты сварганил "на коленке" медиатор.
Медиатор совсем для другого, несмотря на схожесть.авторПосредник (англ. Mediator) — поведенческий шаблон проектирования, обеспечивающий взаимодействие множества объектов, формируя при этом слабую связанность и избавляя объекты от необходимости явно ссылаться друг на друга.
hVostt
это тот же свитч
Скопируй это к себе в редактор ПХП и сделай Ctrl-F по слову switch
hVostt
Можно добавить команду и забыть создать/зарегистрировать хендлер — получишь ошибку в рантайме.
Добавить команду и забыть создать ветку в switch (или забыть сделать метод для обработки) - будет то же самое. Если не хуже.
hVostt
Ты реши задачи свитч/визитёр, на не предлагай решение для совершенно других задач.
Проехали. Забей.
hVostt
когда расширение IsNull() действительно может принести пользу?
Забей. Проехали.
...
Рейтинг: 0 / 0
25 сообщений из 109, страница 3 из 5
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / IDisposable и структуры
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]