Projektowanie orientowo obiektowe

Hej ;)
Piszę sobie pewną aplikację wykorzystując w tym celu Windows Formsy. Aby było w miarę to wszystko okej chciałem stworzyć uniwersalną klasę, która działa zarówno pod konsolą jak i okienkami i tutaj jest moje pierwsze pytanie - robi się tak? Czy raczej tworząc okienkowy program tworzymy klasę, która działa tylko pod okienkiem, czyli w tym przypadku wyświetlamy w klasie komunikaty za pomocą:

 MessageBox.Show();

?

Rozwiązałem to jednak bardziej po swojemu:

  public string HelpMessage { get; set; }

        public string Help(string help)
        {
            HelpMessage = help;

            return HelpMessage;
        }

I teraz, który sposób jest lepszy? Pierwszy czy drugi? Moim zdaniem drugi bo działa też pod konsolą...
Teraz przechodzę do głownego pliku programu, gdzie jest implementacja wszystkich zdarzeń obsługiwanych przez kontrolki i gdzie według Was powinienem stworzyć obiekt tej głowej klasy z ktorej korzystam?
W miejscu w ktorym bede go uzywal czy globalnie bo nie jestem do konca pewien w ilu metodach bedzie on uzywany?

Wiem to takie lajkowe pytanie dlatego prosiłbym Was o pomoc a nie zmieszanie z błotem na wstępie.
Druga rzecz: polecicie mi jakieś materiały traktujące o projektowaniu obiektowych programów?

MVC napisał(a):

Hej ;)
Piszę sobie pewną aplikację wykorzystując w tym celu Windows Formsy. Aby było w miarę to wszystko okej chciałem stworzyć uniwersalną klasę, która działa zarówno pod konsolą jak i okienkami i tutaj jest moje pierwsze pytanie - robi się tak?

A jaki to ma sens? Jeden program nie może być jednocześnie okienkowy i konsolowy.

 MessageBox.Show();

?

Rozwiązałem to jednak bardziej po swojemu:

  public string HelpMessage { get; set; }

        public string Help(string help)
        {
            HelpMessage = help;

            return HelpMessage;
        }

Nie bardzo rozumiem, jak drugi kod może zastąpić pierwszy. No i kompletnie nie rozumiem po co ta klasa, skoro ona nic ni nie robi.

Teraz przechodzę do głownego pliku programu, gdzie jest implementacja wszystkich zdarzeń obsługiwanych przez kontrolki i gdzie według Was powinienem stworzyć obiekt tej głowej klasy z ktorej korzystam?
W miejscu w ktorym bede go uzywal czy globalnie bo nie jestem do konca pewien w ilu metodach bedzie on uzywany?

Ale jaki obiekt, jakiej klasy, i od kiedy programy mają swoje główne pliki?

Druga rzecz: polecicie mi jakieś materiały traktujące o projektowaniu obiektowych programów?

http://helion.pl/ksiazki/wzorce-projektowe-rusz-glowa-elisabeth-freeman-eric-freeman-bert-bates-kathy-sierra,wzorrg.htm
http://helion.pl/ksiazki/analiza-i-projektowanie-obiektowe-rusz-glowa-brett-d-mclaughlin-gary-pollice-david-west,anprob.htm

Czy raczej tworząc okienkowy program tworzymy klasę, która działa tylko pod okienkiem, czyli w tym przypadku wyświetlamy w klasie komunikaty za pomocą:
Jaką klasę? Co robiącą?
Każda klasa, która bezpośrednio nie odwołuje się do interfejsu użytkownika (czyli do okna ani do konsoli) będzie działać i w oknie i w konsoli (a tak na prawdę to w niczym, bo jest jej wszystko jedno).

Każdy nietrywialny program powinien być podzielony na część interfejsu użytkownika, i część tzw. „biznesową”, robiącą co tam program ma robić.
Część biznesowa nie dotyka interfejsu, może być więc bez zmian przeniesiona do innego programu (np. z okienkowego do konsolowego).

Część interfejsu powinna być osobno napisana pod konsolę i osobno dla okien. Nie ma sensu tego łączyć.

Ale nadal nie rozumiem co chcesz zrobić. Twoje HelpMessage nic nie robi i można je wywalić.

somekind napisał(a)

Jeden program nie może być jednocześnie okienkowy i konsolowy.
Może, nie ma problemu otworzyć formę spod konsoli, choć trochę trzeba się namęczyć żeby prawidłowo otworzyć konsolę z okna.
Widziałem takie programy, niby-okienkowe ale które na konsolę sypały jakieś logi.
To jeżeli mówimy o Windowsie, bo w Linuksie jest z tym trochę inaczej.

somekind napisał(a):

A jaki to ma sens? Jeden program nie może być jednocześnie okienkowy i konsolowy.

Może. Zarówno ma poziomie logicznym jak i binarnym. Na logicznym wręcz musi jeżeli takie są przed nim wymagania stawiane.

Jeżeli to ma być jakaś aplikacja narzędziowa to zrób tak:

• wydziel liba w którym zawrzesz część wspólną, czyli to co program de facto robi pod pościelą
• napisz jeden program z GUI co wykorzystuje tego liba
• napisz drugi konsolowy i też w nim wykorzystaj tego liba

Na siłę możesz to też upchać do jednej binarki. Ale powyższy podział powinien tak czy owak obowiązywać na poziomie namespaców/pakietów.

PS. Nie próbuj wyłaniać części wspólnej GUI i interfejsu tekstowego. To dwie różne bestie i tak czy owak Ci się nie uda. Jedynie możesz klucze językowe wywalić do wspólnego pliku.