interfejs do aplikacji konsolowej C#

Witam
Napisałem aplikacje konsolową wykonującą obliczenia w C# i chce teraz do niej zrobić interfejs.
Wybieram w projekcie w VS2010 project/add/Windows Forms.

Pytanie:
Dopiero co uczę się c# i zaczynam czytać o przykładowych aplikacjach okienkowych, ale mam parę pytań.

W mojej aplikacji są 3 klasy:

1. tworzy macierze i ma metody wyświetlające je itp.
2. zawiera metody void statyczne do obliczeń na macierzach
3. zawiera kilka metod zwracających typ liczbowy, np. metoda zwracająca liczbę bezwzględną.
4. klasa main() z instrukcjami tworzącymi obiekty i liczącymi kolejne metody.

cały program jest w pliku program.cs po dodaniu formatki mam plik Form1.Designer.cs
1)w którym pliku powinienem umieść powyższe klasy
2)czy jest jakiś kreator w VS2010 aby szybko utworzyć interfejs do aplikacji konsolowej?
3)czy jak zrobię interfejs to instrukcje z main() pozostaną takie same? tj.:

Macierz trn = new Macierz(w1,k); //tworzenie macierzy 

bo niby gdzie zadeklarować tworzenie obiektu jak nie w main?

Żeś wymyślił... To nie jest tak, że tworzysz aplikacje konsolową, a do niej okienkowe GUI. Masz to lub to. Przecież zarówno wyświetlanie jak i komunikacja z użytkownikiem diametralnie różnią się w obu przypadkach.

Klasy służące do obliczeń (pozycje 2 i 3 na Twojej liście), nie potrzebujące żadnego interfejsu użytkownika powinieneś umieścić w oddzielnej bibliotece DLL. Dzięki temu będziesz mógł je wykorzystać w różnych innych aplikacjach, czy to konsolowych czy tez WinForms.

Będę się czepiał

wierzbiks napisał(a)

3. zawiera kilka metod zwracających typ liczbowy, np. metoda zwracająca liczbę bezwzględną.

czyli napisałeś Math.Abs http://msdn.microsoft.com/en-us/library/a4ke8e73.aspx ? Po co? po co wymyśliłeś koło?

wierzbiks napisał(a)

2. zawiera metody void statyczne do obliczeń na macierzach

czyli o obiektowości za dużo nie przeczytałeś. Takie metody w większości powinny być wykonywane w kontekście konkretnej macierzy, więc powinny być zaimplementowane w klasie macierz.

wierzbiks napisał(a)

1. tworzy macierze i ma metody wyświetlające je itp.

jak już somekind wspomniał logika wyświetlania na konsoli i forms jest zupełnie inna, więc powinieneś to wydzielić do innych klas, najlepiej implementujących jakiś interfejs, np. IDispalyMatrix { void DispalyMatrix(Matrix m); } (ewentualnie jeszcze jakieś dodatkowe pola czy parametry, ale to już raczej w klasach abstrakcyjnych/bazowych dla konsoli/forms powinny być np. dla forms z referencją do jakiejś kontrolki, na której można namalować macierz).

W forms macierz być może chcesz tworzyć po podaniu jej rozmiaru, czyli po kliknięciu przycisku zatwierdzającego wprowadzenie wielkości, w obsłudze Click powinno być tworzenie macierzy. Dopiero jak masz macierz możesz udostępnić wykonywanie operacji na niej. I znowu na pewne zdarzenia na gui (kliki przycisków etc.) reagujesz wywołaniem odpowiednich metod operujących na macierzy.

massther napisał(a)

Będę się czepiał

wierzbiks napisał(a)

2. zawiera metody void statyczne do obliczeń na macierzach

czyli o obiektowości za dużo nie przeczytałeś. Takie metody w większości powinny być wykonywane w kontekście konkretnej macierzy, więc powinny być zaimplementowane w klasie macierz.

ale tworze 3 macierze w klasie macierz, a z klasy funkcje wybieram metodę statyczna która do pracy potrzebuje trzech wcześniej stworzonych macierzy, dlatego te metody umieściłem w osobnej klasie.

co do tworzenia klas abstrakcyjnych lub interfejsów, to nadal mam pytanie w którym pliku umieszczać wymienione wcześniej clasy bo chyba raczej nie będę zabierał się za tworzenie tych kontrolek dll skoro te 2 klasy są potrzebne mi tylko do jednej aplikacji?

Stworzenie osobnej dll bibliotecznej, czyli z klasami do "obliczeń", nie mającymi nic wspólnego z wyświetlaniem nauczy cię poprawnie separować logikę przetwarzania/obliczeń/biznesową od wyświetlania, więc jako trening możesz to potraktować.
Możesz też mieć to w projekcie gui, ale jako osobną klasę(-y). Praktyką jest że każdą klasę ma się w oddzielnym pliku.
Teraz rozumiem ten punkt 2 i twoje wytłumaczenie brzmi rozsądnie.
Jeśli klasy są w tym samym namespace to mimo że są w oddzielnych plikach będziesz je "widział". Jeśli są w innych namespace, to musisz użyć pełnej nazwy z namespace np. System.IO.File, albo dodać using na początku pliku z odpowienim name space, np. using System.IO; a później w kodzie używasz od razu klasy File.
O to chodziło?