Dostęp do metod klasy w pętli

Witam,

Mam sobie klase, zawierajaca pola (properties):

class Test
{
 private string firstField;
 private string secondField;

 //..........

 public string First
  get {return firstField;}
  set {firstField = value;}
   
 
 public string Second
  get {return secondField;}
  set {secondField = value;}
   
  //.........
}

Nastepnie w obiektach tej klasy sprawdzam poprawnosc owych pól (może ich być dużo więcej niż 2). Oczywiscie mogę to robić pojedynczo, ale to jest nie bardzo wygodne.

Czy jest jakiś elegancki sposób na to, by mieć dostęp do tych pól w pętli?
Oczywiście wiem, że mogę sobie zaimplementować jakiś iterator, albo chociażby operator [] przyjmujący np. numer pola, ale może są jakieś wbudowane mechamizmy, z których mogę skorzystać?

[edit]
Znalazlem - PropertyInfo z System.Reflection :>

Nie wiem czy akurat spasuje, ale alternatywą może być użycie StringDictionary

Hm, ale niby jak uzyc tu StringDictionary?

Przy użyciu PropertyInfo powstala dosc karkolomna, ale dzialajaca konstrukcja, dla powyzszego przykladu:

foreach (System.Reflection.PropertyInfo p in
                     test.GetType().GetProperties())
  {

     switch (p.Name)
     {
          case "First":
            { if (((string)p.GetValue(test, null))==null)
                      {
                         /*Cos tam*/
                      
                      }
                 break;
              }   
       }
  


   }

A to nie lepiej sprawdzac poprawnosc w get i set? Skoro i tak uzywasz switcha to masz rozne rodzaje testow.

No można też, tylko że chcę mieć całe sprawdzanie składni realizowane w jednej metodzie - w razie późniejszych zmian nie trzeba będzie tego szukać w różnych set-ach w różnych klasach

A druga rzecz, że testy często się powtarzają, więc mogę dać np:

case "pierwsza":
case "druga":
case "trzecia":
{
 //cos tam
}

A przy sprawdzaniu w set kod by się powtarzał.

Stworz jedna metode z parametrem i wywoluj w set ;)

Hmm

Ale co taka metoda musialaby przyjmowac jako argument? Prawdopodobnie nazwę pola i jego wartosc... czyli w zasadzie to samo co zawiera juz PropertyInfo

Cialo metody bedzie takie samo jak jest, tyle ze bez uzywania PropertyInfo. Switch by zostal, foreach by byl niepotrzebny.

Za to do kazdego set-a bede musial dopisywac wywolanie metody sprawdzajacej. A co w przypadku, gdy dla różnych obiektów klasy potrzebne będa różne testy? :>

To zrob osobne metody do roznych testow. Co za roznica czy uzyjesz switcha z dwoma case'ami czy dwoch metod o nazwach wiecej mowiacych? Tyle samo kodu. IMO z metodami lepiej, bo kod jest jasniejszy i bardziej zrozumialy. Tamta metode i tak musisz gdzies wywolac, wiec tez bez roznicy. Moim zdaniem Twoje podejscie to armata na muche.

Hm sprawa jest troche zagmatwana bo:

Dane przychodza przez webserwis. Czyli - ktos z zewnatrz wywoluje metode mojego webserwisu. Jako argument owej metody podaje wlasnie obiekt klasy z rozwazanymi polami.

Więc w implementacji metody mojego webserwisu (czyli po otrzymaniu danych) wywoluje metode CheckSyntax, ktora sprawdza, czy wszystkie pola zostaly podane prawidłowo.
Jeżeli tak, to przetwarzamy te dane , jeżeli nie to wysyłamy (również zserializowaną) odpowiedź, że komunikat nie został zrozumiany, a odpowiedź zawiera m.in opisowy komunikat błędu (w tym przypadku informację o tym, które pole było błędne).

Umieszczając sprawdzanie składni w definicji serializowanej klasy (tutaj argumentu webserwisu) nie mam za bardzo pomysłu jak zrealizować powyższe (czy w ogóle się da?). Sprawdzać poprawność muszę dopiero PO utworzeniu obiektu klasy, a nie jeszcze na etapie jego tworzenia...

Poza tym, sprawdzenie składni to tylko pierwszy etap, więc logika narzuca się sama - najpierw poprawność otrzymanych danych (jeżeli źle to won), potem coś z tymi danymi robimy, jeżeli się nie uda to won itd.... a wszystko to jest realizowane po kolei poprzez wywoływanie kolejnych funkcji w implementacji metody webserwisu.

To troche co innego. Ale w takim wypadku ja zrobilbym cos w stylu (statycznej) metody Parse.

A dlaczego tak? Ja mam prywatna metode w klasie implementującej interfejs (tzn w interfejsie nie ma ma nawet deklaracji, tam sa tylko metody i pola webserwisu), calosc jest w klasie wyprowadzonej z interfejsu - metoda przetwarzajaca otrzymane dane też.

Po co tu metoda statyczna?