Powinienem zapewniają metody dostępowe / Getter ustawiaczy dla public / protected komponentów na formularzu?

głosy
4

Jeśli mam .Net formularz z komponentu / obiektu, takich jak pole tekstowe, że muszę przejść od rodzica lub innej formy I oczywiście trzeba „upgrade” modyfikator do tego składnika do wewnętrznej lub zmiennej szczeblu publicznym.

Teraz, gdybym zapewniając zmienną publiczną int lub łańcuch typu itp w moim klasy formularza nie będę dwa razy pomyśleć o użyciu pobierające i (być może) ustawiaczy obejść ten problem, nawet jeśli nie robić niczego innego niż zapewniają bezpośredni Dostęp do zmiennej.

Jednak projektant VS nie wydaje się wdrożenie takich pobierające / ustawiające na tych obiektów publicznych, które są składnikami w postaci (a zatem nie jest zgodny z dobrą praktyką programowania).

Więc pytanie jest; W tym celu na „słuszne” mam owinąć takich elementów VS projektanta lub obiektów w Getter i / lub setera?

Utwórz 08/08/2008 o 15:35
źródło użytkownik
W innych językach...                            


4 odpowiedzi

głosy
1

I zawsze to zrobić, a jeśli jesteś w następstwie projektu MVP tworząc getter / ustawiające dla Państwa zdanie składników byłoby wymaganie projektowe.

Nie rozumiem co masz na myśli przez „nie jest zgodne z zasadami dobrej praktyki programowania”. Microsoft narusza wiele dobrych praktyk programowania, aby łatwiej tworzyć rzeczy na Visual Studio (ze względu na szybki rozwój aplikacji) i nie widzę brak pobierające / ustawiające dla kontroli jako dowód naruszają jakiekolwiek takie najlepszych praktyk.

Odpowiedział 08/08/2008 o 15:41
źródło użytkownik

głosy
2

Powodem niewdrożenie pobierające i ustawiające dla komponentów na formularzu moim zdaniem jest przyczyną, że nie będzie „wątku bezpieczny” Net obiekty są przypuszczać, aby być modyfikowane tylko przez wątek formularza, który je stworzył, jeżeli umieścimy na getter i ustawiające jesteś potencjalnie otwierając go dla każdego wątku. Zamiast Twój przypuszczać, aby wdrożyć system delegata gdzie zmiany tych obiektów są przekazywane do wątku, który je stworzył i prowadził tam.

Odpowiedział 08/08/2008 o 15:42
źródło użytkownik

głosy
4

Jednak projektant VS nie wydaje się wdrożenie takich pobierające / ustawiające na tych obiektów publicznych, które są składnikami w postaci (a zatem nie są zgodne z zasadami dobrej praktyki programowania).

Jeśli masz na myśli kontrole jesteś przeciągając i upuszczając na formularzu, są one oznaczone jako prywatne członków instancji i są dodawane do kolekcji Controls formularza. Dlaczego mieliby być inaczej? Postać może mieć czterdziestu lub pięćdziesięciu kontroli, byłoby nieco niepotrzebne i nieporęczny, aby zapewnić getter / setter dla każdej kontroli na formularzu. Projektant pozostawia ją do siebie, aby zapewnić dostęp do określonych delegowanego kontroli za pośrednictwem publicznych getter / ustawiaczy.

Projektant robi słusznie tutaj.

Odpowiedział 08/08/2008 o 15:50
źródło użytkownik

głosy
2

Jest to klasyczny przykład enkapsulacji w projektowania obiektowego.

Postać jest obiektem, którego zadaniem jest przedstawienie interfejs dla użytkownika i zaakceptować wejście. Interfejs pomiędzy wynikowy i innych obszarów kodu powinny być interfejs danych zorientowanych nie interfejs, który ujawnia wewnętrzne szczegóły wykonania formularza. Wewnętrzne mechanizmy postaci (tj kontrole) powinno pozostać niewidoczne jakiegokolwiek kodu pracochłonne.

Dojrzała rozwiązanie prawdopodobnie wiązałoby się następujące punkty konstrukcyjne:

  • publiczne metody lub właściwości są zachowanie (pokazanie, ukrycie, stanowisko) lub (zbiór danych, uzyskanie danych, aktualizacji danych) danych zorientowanych.
  • Wszystkie ładowarki wydarzenie realizowane przez forma są zapakowane w odpowiednim kodem Przekazanie gwint do egzekwowania przepisów wątku wykonanie formularza.
  • Kontroluje się będzie danych związane z podstawową strukturą danych (w razie potrzeby) w celu zmniejszenia kodu.

I to nie wspominając nawet o rzeczy jak meta-rozwojowych testów jednostkowych.

Odpowiedział 08/08/2008 o 16:51
źródło użytkownik

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more