Klasy lepiej trzymać w osobnych plikach, wyodrębniłem class Object do Object.cs.
Nazwa Object jest trochę zbyt ogólna, warto zmienić ją na coś informującego. Dam na razie Option.
picture zmienię na pictureFilePath, a number na id

Random rand = new Random();
int move = rand.Next(mode);
Option returned = new Option();
for (int i = 0; i < mode; i++)
{
    if (move == objects[i].ID)
        returned = new Option(objects[i]);
}

Obiekty do tej tablicy:

Option[] objects =
{
    paper, rock, scissors, lizard, spock
};

wrzuciłaś po kolei, zgodnie z ich numerami id (czy tam wcześniej number), więc nie ma potrzeby przeszukiwać tej całej tablicy w poszukiwaniu obiektu o danym id (number). Wystarczy:

Random rand = new Random();
int move = rand.Next(mode);
return objects[move];

Kolejne metody resultPaper, resultRock, etc. możemy spróbować znacznie uprościć, zmieniając klasę Option. zróbmy to w następujący sposób - miejmy dwie, a nie jedną zmienną przechowującą ścieżkę obrazka. Jedną nazwiemy winPicturePath, drugą losePicturePath (to file w sumie trochę zbędne). Dorzućmy je do konstruktora:

public Option(string name, string winPicturePath, string losePicturePath)

ID na moment się pozbywam, podejrzewam, że nie będziemy go potrzebowali.

Zróbmy jeszcze jeden improvement - niech klasa Option przechowuje już właściwy obrazek typu Image, a nie tylko ścieżkę do pliku. Image znajduje się w System.Drawing, więc trzeba dopisać usinga na początku pliku. Teraz mamy:

public Option(string name, string winPicturePath, string losePicturePath)
{
    this.name = name;
    winPicture  = Image.FromFile(winPicturePath);
    losePicture = Image.FromFile(losePicturePath);
}

Konstruktor kopiujący to teraz trochę inna sprawa - na obiektach Image trzeba użyć metody Clone, żeby stworzyć ich kopię.

public Option(Option optionToCopy)
{
    this.name = optionToCopy.name;
    this.winPicture  = (Image)optionToCopy.winPicture.Clone();
    this.losePicture = (Image)optionToCopy.losePicture.Clone();
}

W każdym razie nie będziemy go prawdopodobnie potrzebować.

Generalnie dążę do tego, żeby odciążyć klasę Program od wykonywania jakichkolwiek zadań. Lepiej przenieść wszystko do Form1, dlatego stworzenie obiektów klasy Option przenieśmy do Form1.

public static Option paper = new Option("paper", "paperwin.png", "paperlose.png");
public static Option rock = new Option("rock", "rockwin.png", "rocklose.png");
public static Option scissors = new Option("scissors", "sci

Wpisywanie tego jest trochę uciążliwe. Trzymamy się stałego szablonu, wystarczy dodać win albo lose, żeby dostać odpowiedni obrazek. Zróbmy metodę, która po prostu załaduje dla nas obiekt.

private Option LoadOption(string name)
{
    return new Option(name, name + "win.png", name + "lose.png");
}

Nie jest to metoda statyczna, więc załadujmy te obiekty w konstruktorze. Również tych zmiennych wewnątrz klasy nie musimy oznaczać jako statyczne, bo Form1 nie jest statyczne i operujemy na konkretnej instancji tej klasy zatem:

public Option paper;
public Option rock;
public Option scissors;
public Option lizard;
public Option spock;

A w konstruktorze:

public Form1()
{
    InitializeComponent();

    paper    = LoadOption("paper");
    rock     = LoadOption("rock");
    scissors = LoadOption("scissors");
    lizard   = LoadOption("lizard");
    spock    = LoadOption("spock");
}

Huh, dobra, ale naszym celem było uproszczenie metod z rodziny "resultX". To nie będzie takie proste z racji, że do zmiennych Form1.IserChoice i Form1.ComputerChoice przypisujemy ścieżki plików. Zróbmy to zupełnie inaczej. Stwórzmy klasę Decider, która będzie wiedziała, który wybór jest zwycięski i nas o tym poinformuje. Decider nie będzie musiał wiedzieć ani o nazwie pliku, ani o zmiennych Form1. W ten sposób rozdzielimy logikę do zupełnie odrębnej klasy.

(...)

Po niekrótkim namyśle doszedłem do wniosku, że możemy to zrobić na inny sposób. każdy obiekt klasy Option będzie wiedział, jaki inny obiekt tej klasy może pokonać. Zewnętrzny Decider nie jest zły, może nawet lepszy, bo mamy informację o wszystkich zwycięskich i przegranych parach zgromadzoną w jednym miejscu. Jesli będzie istniała potrzeba zmiany jakichś zasad gry, będziemy mogli zmodyfikować tylko tą klasę (patrz: Single Rensposibility Principle).

Tak więc, żeby zachować rzeczy w miarę prostymi, załóżmy pomysł pierwszy. Teraz każda opcją otrzymuję listę innych opcji, które może pokonać:

List<Option> optionsICanBeat; // w class Option

Dodatkowo zaimplementujmy dwie pomocne metody. Pierwsza z nich będzie pozwalała nam powiedzieć danej opcji, jakie inne opcje może pokonać:

public void TellMeWhoICanBeat(params Option[] options)
{
    foreach (var option in options)
    {
        optionsICanBeat.Add(option);
    }
}

(Mały tip: List to w istocie tablica, która sama się rozszerza. Ponieważ mamy maksymalnie 5 opcji, a każda z nich może pokonać 2 inne, zróbmy, żeby nasza lista miała na początku rozmiar 2. W konstruktorze dodamy kawałek:

optionsICanBeat = new List<Option>(2);

Oczywiście, tak czy siak musimy utworzyć obiekt listy, inaczej zostanie tam null).

Druga metoda będzie informowała, czy dana opcja jest w stanie pokonać inną:

public bool CanIBeat(Option option)
{
    return optionsICanBeat.Contains(option);
}

Simple. Teraz trzeba ustalić, kto komu może skopać tyłek. Zrobimy to w konstruktorze Form1:

public Form1()
{
    (...)

    InitializeRules();
}

private void InitializeRules()
{
    paper.TellMeWhoICanBeat(rock, spock);
    rock.TellMeWhoICanBeat(scissors, lizard);
    scissors.TellMeWhoICanBeat(paper, lizard);
    lizard.TellMeWhoICanBeat(paper, spock);
    spock.TellMeWhoICanBeat(scissors, spock);
}

Fajnie, teraz określenie tego, kto jest zwycięzcą sprowadza się do czegoś pokroju rock.CanIBeat(paper).

Pozostaje problem - wraz z określonymi parami wiążą się określone komunikaty ("because spock vaporizes rock") i tak dalej. Będziemy musieli to uwzględnić przy "mówieniu" obiektowi, kogo może pokonać. Zrobimy to prosto - powiemy mu także, dlaczego!

Zacznijmy od zmiany sposobu przechowywania opcji, które możemy pokonywać. Stwórzmy następującą strukturę:

public class Option
{
    struct BeatableOption
    {
        public BeatableOption(Option option, string why)
        {
            this.Option = option;
            this.Why = why;
        }

        public Option Option;
        public string Why;
    }

    (...)
}

Dalej, zmodyfikujmy nasz kontener:

List<BeatableOption> optionsICanBeat;

I zmienimy naszą metodę:

public void TellMeWhoICanBeat(Option option, string why)
{
    optionsICanBeat.Add(new BeatableOption(option, why));
}

(Nie możemy teraz skorzystać z dobrodziejstwa paramsa, bo potrzebujemy drugiego argument - stringa why. Oczywiście, moglibyśmy zrobić params BeatableOption[] options, ale ustalmy, że BeatableOption jest prywatną strukturą - nikt z zewnątrz nie musi widzieć, w jaki sposób nasz obiekt wie, kogo może pokonać).

W związku z tym, zmieńmy naszą metodę InitializeRules:

private void InitializeRules()
{
    paper.TellMeWhoICanBeat(rock, "because paper covers rock");
    paper.TellMeWhoICanBeat(spock, "because paper disproves spock");
    rock.TellMeWhoICanBeat(scissors, "because rock crushes scissors");
    rock.TellMeWhoICanBeat(lizard, "beacuse rock crushes lizard");
    scissors.TellMeWhoICanBeat(paper, "because scissors cut paper");
    scissors.TellMeWhoICanBeat(lizard, "because scissors decapitates lizard");
    lizard.TellMeWhoICanBeat(paper, "because lizard eats paper");
    lizard.TellMeWhoICanBeat(spock, "because lizard poisons spock");
    spock.TellMeWhoICanBeat(rock, "because spock vaporizes rock");
    spock.TellMeWhoICanBeat(scissors, "because spock smashes scissors");
}

Zajebiście. Pójdźmy o krok dalej. Zamiast metody WhoCanIBeat wywoływanej na obiekcie stwórzmy metodę statyczną Option.WhoWins. Chcielibyśmy zwracać dwie wartości - kto wygrał i dlaczego. Możemy zwrócić tylko jedną, dlatego będziemy musieli to trochę oszukać:

public static Option WhoWins(Option option1, Option option2, ref string why)
{
    int numOfBeatableOptionsFor1 = option1.optionsICanBeat.Count;
    int numOfBeatableOptionsFor2 = option2.optionsICanBeat.Count;

    int maxIterValue = Math.Max(numOfBeatableOptionsFor1,
                                numOfBeatableOptionsFor2);

    for (int i = 0; i < maxIterValue; i++)
    {
        if (i < numOfBeatableOptionsFor1 && option1.optionsICanBeat[i].Option == option2)
        {
            // Option 1 beats option 2
            why = option1.optionsICanBeat[i].Why;
            return option1;
        }

        if (i < numOfBeatableOptionsFor2 && option2.optionsICanBeat[i].Option == option1)
        {
            // Option 2 beats option 1
            why = option2.optionsICanBeat[i].Why;
            return option2;
        }
    }

    // No one wins
    why = "";
    return null;
}

No dobra, to wygląda ciekawiej. W istocie ta metoda jest bardziej ogólna niż powinna być dla naszej małej aplikacji, ale zobaczmy. Na samym początku określamy, która lista posiada więcej elementów po to, aby móc je przeiterować w jednej pętli - samą pętle wykonujemy zatem tyle razy, ile jest potrzebne dla dłuższej listy. W pętli sprawdzamy, czy i-ta opcja w listach dla opcji 1 i 2 jest opcją, którą mogą one opokonać. Jeśli tak, to znaczy, że znaleźliśmy zwycięzcę, którego możemy zwrócić wraz z podanym powodem.

Istotne są tu dwie techniczne rzeczy. Pierwsze, każdy if posiada dodatkowy warunek sprawdzajacy, czy i jest mniejsze od długości danej listy, inaczej moglibyśmy wyjść poza zakres, zwłaszcza że pętla wykonuje się tyle razy, ile trwa najdłuższa lista, zapominając o krótszej. Druga sprawa - powód w zmiennej string (why) przekazujemy przez referencję. Dzięki temu możemy przed wywołaniem stworzyć zmienną:

string why;

a następnie przekazać ją do metody i uzyskać wynik. To prawie tak jakbyśmy zwracali dwie wartości!

A więc metoda WhoWins działa niemal jak metody resultX, więc możemy się ich pozbyć. Kluczowe jest tu jednak słowo "niemal". resultPaper nie tylko odpowiadało za określenie, kto wygrał, ale także ustawienie odpowiedniej grafiki, a w zasadzie podanie ścieżki do tej grafiki. Jedna zmiana pociągnęła wiele innych. Spróbujmy zatem wrócić do korzeni i zmieńmy nieco kod zajmujący się przyciskami:

private void PaperButton_Click(object sender, EventArgs e)
{
    ProcessMove(paper, 3);
}

Wykonamy to analogicznie dla wszystkich przycisków. Metoda ProcessMove przyjmuje dwa argumenty - opcję wybraną przez użytkownika i liczbę dostępnych opcji (3 albo 5). Jej zadaniem jest wylosowanie ruchu komputera i przedstawienie wyniku na ekran.

Zaraz, za losowanie ruchu komputera odpowiadała metoda ComputerMove w klasie Program. Ponieważ wszystko odbywa się w klasie Form1 przenieśmy ją i tam. Użyjmy jej teraz, aby otrzymać rdzeń naszej aplikacji, który przetwarza ruch gracza:

private void ProcessMove(Option userOption, int numOfOptions)
{
    Option computerOption = ComputerMove(numOfOptions);

    if (userOption == computerOption)
    {
        Result1.Text = "DRAW";
        Info1.Text = "";

        YouPicture1.Image = userOption.WinPicture;
        ComputerPicture1.Image = computerOption.LosePicture;
        return;
    }

    string why = "";
    Option winner = Option.WhoWins(userOption, computerOption, ref why);

    if (winner == userOption)
    {
        Result1.Text = "You won";
        Info1.Text = why;

        YouPicture1.Image = userOption.WinPicture;
        ComputerPicture1.Image = computerOption.LosePicture;
    }
    else
    {
        Result1.Text = "You lost";
        Info1.Text = why;

        YouPicture1.Image = userOption.LosePicture;
        ComputerPicture1.Image = computerOption.WinPicture;
    }
}

Myślę, że dobrnęliśmy do końca. Powyższą metodę można jeszcze zesplitowac na parę innych ale sama w sobie jest, myślę, całkiem czytelna. Co zatem dostaliśmy?

- nieco czytelniejszy kod - wywołania takie jak:
paper = LoadOption("paper");
paper.TellMeWhoICanBeat(rock, "because paper covers rock");
Option.WhoWins(userOption, computerOption, ref why);
wydają mi się bardziej czytelniejsze i zrozumiałe.
- ważne - porozdzielaliśmy odpowiedzialności na poszczególne klasy/metody. Wcześniej metody w większości miały kilka zadań, przez co miałem miałem trudności z dotarciem, co zmienia co. Teraz wydaje mi się to jaśniejsze.
- jeszcze ważniejsze - uniknęliśmy nadmiarowego i powtarzającego się kodu. Potężne switche zredukowaliśmy do jednej metody (WhoWins).

No, to tyle. Przepraszam, jeśli przekurwilem, powiedz mi na przyszłość, bo wiem, że jestem świrem, ale czasem zapominam, że inni nie. :P