Б1-55-83 (mavcan) wrote in code_wtf,
Б1-55-83
mavcan
code_wtf

Больше кода для бога кода!

    public class MyIdGuidPair
    {
        private Guid _id;
        public Guid Id
        {
            get { return _id; }
            set { _id = value; }
        }
        private DateTimeOffset _datetimevalue;
        public DateTimeOffset DatetimeValue
        {
            get { return _datetimevalue; }
            set { _datetimevalue = value; }
        }
        public void SetId(Guid id)
                { _id = id; }
        public Guid GetId()
                { return _id; }

        public void SetDatetimeValue(DateTimeOffset value)
        { _datetimevalue = value; }
        public DateTimeOffset GetDatetimeValue()
        { return _datetimevalue; }
    }


C#, форматирование автора.
Не связано с каким-либо легаси.
  • Post a new comment

    Error

    Comments allowed for members only

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 14 comments
Скорее всего IDE наавтогеренило, ибо совершенно непонятно зачем нужен мутатор если в C# есть проперти (причем автор про него знает!).
Но IDE это навернка VS, а она бы так не сделала (если конечно автор внучную не вызвал такие сниппеты), так что ничего не понятно.
--------
Да и вообще: Tuple же есть)

Может, автору построчно платят?
Среда - VS, да. Не знаю, могли ли какие-то сниппеты такого натворить.
Построчно - 100% не платили :)
вполне допускаю, что вначале были Get\Set методы, а потом , по какой-либо причине, понадобились проперти. А те не вычистил. Или они много, где использовались.
Или же, наоборот, были проперти, а потом, ему надо в какой-то метод передать указатель на функцию Get\Set.
Т.к. отсутствуют примеры использования, то сложно сказать.
Приведите пожалуйста пример в котором нужны Get/Set функции в C#.
по привычке?
Или, как я указал выше, какой-нибудь метод принимает делегат как параметр (если это вам более понятнее, чем вышеупомянутый указатель на функцию).
>>по привычке?
Весьма странная привычка для C#. Тем паче что сниппет #prop так не делает, а код похож на генеренный.

Про указатель я понял, но это тоже довольно необычный для C# подход, да и разве нельзя делегатом обернуть лямбду которая просто дёрнет проперти? Зачем загаживать интерфейс? Да и вообще, как я писал выше, такой класс впринципе не нужен: это же просто Tuple!
Да любая бизнес логика перед присвоением. Скажем, время только с четными секундами и нечетными минутами, а guid должен иметь второй и четвертый int64 делящийся нацело на 17.
По коду: надо вызвать в property getter/setter соответствующие функции во избежание для, и все будет логично. Код предполагает дальнейшее развитие, а пока это затычки.
По поводу того, что getter/setter public... Ну, скажем, это функции интерфейса IMyIdGuidPair. Но тогда, возможно, есть смысл отказаться от пропертей. А еще есть сериализаторы, причем как XML, так и JSON, и бывает надо, чтоб они работали по разному...
У меня лично были варианты, когда класс был создан с properties, потом были добавлены приватные getter/setter, а потом возникла необходимость построения интерфейса. Я не утверждаю, что автор обо всем этом думал, но об этом наверняка думали создатели снипперов.
>> Да любая бизнес логика перед присвоением.
Всмысле для реализации контракта? А разве нельзя проверять его в пропертях?

>>Ну, скажем, это функции интерфейса IMyIdGuidPair.
В интерфейс можно и проперти вынести. Ведь проперти это просто сахар! Они же реально в set_, get_ превращаются.


>> А еще есть сериализаторы, причем как XML, так и JSON, и бывает надо, чтоб они работали по разному
Добиваться этого посредством проперти и сеттера как-то странно)
Использование - прозаичное; никаких передач методов.
Более того, я имею доступ к version control: сначала было написано правильно (в две строчки), потом - убито совсем, потом - единовременно закоммичен этот монстр.
Есть еще вариант что автор краем уха слышал что нужно использовать аксессоры/мутаторы (например, от знакомого джависта) и будучи джуниором "применил на практике":)
ну архаично, конечно... и кода многовато... но не самое плохое, что может случится...
Согласен. Но мозг закипает в попытках найти тайный смысл сего излияния... особенно когда его нет (
Неплохо. Для полноты картины не хватает еще интерфейса, который этот класс бы реализовал.
Ггг... точно! :)