Найдено результатов: 2

Дженерики в c# и доступ к статическим членам Т

Мой вопрос касается c# и как получить доступ к статическим мемберам ... Ну, я действительно не знаю, как это объяснить (что в некотором роде плохо для вопроса, не так ли?) Я просто дам вам пример кода:

Class test<T>{
     int method1(Obj Parameter1){
         //in here I want to do something which I would explain as
         T.TryParse(Parameter1);

         //my problem is that it does not work ... I get an error.
         //just to explain: if I declare test<int> (with type Integer)
         //I want my sample code to call int.TryParse(). If it were String
         //it should have been String.TryParse()
     }
}

Так что спасибо вам, ребята, за ваши ответы (кстати, вопрос в том, как бы я решил эту проблему без получения ошибки). Это, наверное, довольно простой вопрос для вас!

Спасибо, Никлас


Edit: спасибо всем за ваши ответы!

Хотя я думаю, что фраза try - catch является самой элегантной, я знаю по своему опыту работы с vb, что это действительно может быть облом. Я использовал его один раз, и мне потребовалось около 30 минут, чтобы запустить программу, которая позже заняла всего 2 минуты для вычисления только потому, что я избегал try - catch.

Вот почему я выбрал утверждение swich в качестве лучшего ответа. Это делает код более сложным, но с другой стороны, я думаю, что он будет относительно быстрым и относительно легким для чтения. (Хотя я все еще думаю, что должен быть более элегантный способ ... может быть, на следующем языке, который я изучаю: P )


Хотя, если у вас есть какое-то другое предложение, я все еще жду (и готов принять участие)

c#   generics   static   methods   data-access    

508   12   02:35, 8th August, 2020


Разделить класс доступа к данным на читателя и писателя или объединить их?

Это может быть на стороне "discussy", но я действительно хотел бы услышать Ваше мнение об этом.

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

Итак, я недавно начал разделять доступ к данным на FooWriter и FooReader, что приводит к более приятным именам и дает некоторую дополнительную гибкость, но в то же время мне нравится держать его вместе, если классы не большие.

Является ли разделение читателя / писателя лучшим дизайном, или я должен их объединить? Если я должен объединить их, Какого черта я должен назвать класс?

Спасибо /Erik

architecture   oop   data-access    

422   5   18:38, 4th August, 2020