Organizacja kodu w Solucji

Cześć,

Mam pytanie wz z organizacją kodu w solucji

Utworzyłem sobie solucję i projekt WinForms
Na formatkę wrzuciłem: comboBoxa i przycisk
i teraz w zależności od wartości combo jak klikam w przycisk ma mi się wywołać odpowiednia metoda.
i mam taki kod

public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            comboBox1.Items.Add("Pozycja_1");
            comboBox1.Items.Add("Pozycja_2");
        }

        private void button1_Click(object sender, EventArgs e)
        {
            if (comboBox1.Text == "Pozycja_1")
            {
                Metoda_dla_pozycaji_1();
            }
            else
            {
                Metoda_dla_pozycaji_2();
            }
        }
    }

teraz chciałem tworzyć każdą z metod: Metoda_dla_pozycaji_1(), Metoda_dla_pozycaji_2 itd.
w osobnym pliku ponieważ z biegiem czasu będzie ich przyrastać i chciałbym w szybszy sposób zarządzać kodem.

Próbowałem tworzyć osobne klasy i wrzucać tam te metody czyli np. klasa-> Metoda_dla_pozycaji_1 i tam wrzucić tą metodę ( Metoda_dla_pozycaji_1() ) ale wtedy nie umiem z niej skorzystać w programie głównym.
Próbowałem też drugi projekt w solucji o typie ClassLibrary i próbowałem tam wrzucać te metody ale też nie wychodziło.

Mielibyście jakąś poradę? Jak zbudować strukturę o którą mi chodzi?

Możesz mieć kod jednej klasy w różnych plikach a nawet różnych projektach.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/partial-classes-and-methods

Dzięki za linka ale chodziło mi o coś bardziej na kształt C++ Buildera
Tam wystarczyło że dodałem sobie do projektu (Unit1 już był) nowy unit np. Unit2
Do tego unita wrzucałem metodę bez żadnego namespace'a i bez żadnej klasy.
Wiązałem ze sobą dwa unity poprzez #include "Unit?.h" itd
i z poziomu Unit1 mogłem się odwołać do metody z Unita2 i wszystko działało pięknie.
Tego mi brakuje w C# a może coś takiego mogę zrobić, tylko nie wiem jak :)

KiK napisał(a):

Dzięki za linka ale chodziło mi o coś bardziej na kształt C++ Buildera

Jeszcze nie przewinąłem wątku, i nie widziałem tego postu, ale to pomyślałem: jakie brzydnie nazwy Form1 itd pewnie borlandowiec

Jak myślisz Builderem, to nie wyjdziesz z pewnego rodzaju getta. Pewnie jakby ten przykład urósł, się dowiemy, że dane są rozszyte na klasach GUI, w ogóle brak klas innych niż GUI.

Na związek string - kod jest wiele prawidłowych wzorców obiektowych, pierwszy co mi strzelił do łba, to Map (w C# Dictionary) Strategii

spodziewałem się jakiejś praktycznej porady a tym czasem jak zwykle inne różne poboczne wątki.
Jeszcze napiszcie żebym sobie w google poszukał :)

KiK napisał(a):

spodziewałem się jakiejś praktycznej porady a tym czasem jak zwykle inne różne poboczne wątki.

Jeszcze napiszcie żebym sobie w google poszukał :)

jeśli sam napisałeś "jedna klasa Form1 ma przyrastać", to dla mnie już wskazuje, że czujesz tę patologię.

Ten problem jest zawsze występujący przy stylu "borlandowym", czyli szyciu kodu na wigetach GUI. Byłem kiedyś w projekcie, gdzie klasy borlandowe osiągały limity 64k kodu czy 64k linii, czyli koniec, to się już nie chciało edytować / kompilować.

Lekarstwo jest zawsze to samo: oddzielnie kodu "biznesowego" do innych klas, na GUI to TYLKO odpalanie go. Również wydzielenie danych poza GUI (np do poczytania MVC)

Twoje lekarstwo to puder na francuską chorobę.

PS. z całości programowania obiektowego (sugeruję doczytać), dam tylko jedną wzmiankę: klasa to nie jest zbiornik na wszystko, co udało się nakodzić (Form1).
Natomiast klasa ma zakres odpowiedzialności, ma rolę, która da się w prostym słowie określić, jest zbiornikiem danych (jakim), klasą GUI (tylko i wyłącznie), narzędziem do zapisu/odczytu na pliki itd : XxxxxxManager, YyyyyStorage, Invoice, Payment.
Więc dobrze (wąsko) określony zakres odpowiedzialności, i NAZWA klasy, która będzie kierowała naszym myśleniem

Nie wiem czym są unity w Borlandzie, ale w C# kod musi być w klasach, a dalej są dwie opcje:

1. Wywołujemy metodę bez tworzenia obiektu danej klasy, np: MojaKlasa.JakaśMetoda(), wówczas taka metoda musi być statyczna (czyli mieć modyfikator static).
2. Wywołujemy metodę na rzecz instancji obiektu, czyli mójObiektMojejKlasy.JakaśMetoda(), wówczas taka metoda nie jest statyczna, za to potrzebujemy w naszym formie mieć pole z tym obiektem, i oczywiście musimy ten obiekt utworzyć przed użyciem.

Natomiast rozsądnym sposobem separacji kodu GUI od kodu aplikacji są wzorce projektowe warstwy prezentacji, czyli np. słynny MVC albo jego bardziej pasująca do WinForms odmiana jaką jest MVP.

poklikałem, poklikałem i coś tam powychodziło dzięki @somekind

SOLID, a zwłaszcza pierwsza literka - S od Single Responsibility Purpose. Przyda się też wzorzec projektowy MVC lub MVP oraz być może MVVM. Przemyślenie architekturę dzieląc ją na warstwy: repository, services, controllers, views i modele spinające komunikację.