Czy powinniśmy unikać niestandardowych obiektów jako parametrów?

Załóżmy, że mam niestandardowy obiekt, Student :

public class Student{
    public int _id;
    public String name;
    public int age;
    public float score;
}

Oraz klasa Window , która służy do wyświetlania informacji o Uczniu :

public class Window{
    public void showInfo(Student student);
}

Wygląda całkiem normalnie, ale stwierdziłem, że Window nie jest dość łatwy do przetestowania indywidualnie, ponieważ do wywołania funkcji potrzebny jest prawdziwy obiekt Studenta . Próbuję więc zmodyfikować showInfo, aby nie akceptował bezpośrednio obiektu Studenta :

public void showInfo(int _id, String name, int age, float score);

aby łatwiej było testować Window indywidualnie:

showInfo(123, "abc", 45, 6.7);

Ale odkryłem, że zmodyfikowana wersja ma inne problemy:

1. Zmodyfikuj ucznia (np .: dodaj nowe właściwości) wymaga zmodyfikowania podpisu metody showInfo

2. Gdyby Student miał wiele właściwości, sygnatura metody Studenta byłaby bardzo długa.

Tak więc, używając niestandardowych obiektów jako parametru lub przyjmując każdą właściwość w obiektach jako parametr, która z nich jest łatwiejsza do utrzymania?

Używanie obiektu niestandardowego do grupowania powiązanych parametrów jest w rzeczywistości zalecanym wzorcem. W ramach refaktoryzacji nazywa się to Obiektem parametrów .

Twój problem leży gdzie indziej. Po pierwsze, ogólne nie Windowpowinny wiedzieć nic o uczniu. Zamiast tego powinieneś mieć coś, StudentWindowco wie tylko o wyświetlaniu Students. Po drugie, absolutnie nie ma problemu z tworzeniem Studentinstancji do testowania, StudentWindowo ile Studentnie zawiera ona złożonej logiki, która drastycznie skomplikowałaby testowanie StudentWindow. Jeśli ma taką logikę Student, należy preferować tworzenie interfejsu i kpiny.

Mówisz, że to

testowanie pojedynczo nie jest łatwe, ponieważ do wywołania funkcji potrzebny jest prawdziwy obiekt Studenta

Ale możesz po prostu utworzyć obiekt studencki, aby przejść do okna:

showInfo(new Student(123,"abc",45,6.7));

Dzwonienie nie wydaje się bardziej skomplikowane.

W kategoriach laika:

• To, co nazywacie „obiektem niestandardowym”, jest zwykle po prostu nazywane obiektem.
• Nie można uniknąć przekazywania obiektów jako parametrów podczas projektowania dowolnego nietrywialnego programu lub interfejsu API lub korzystania z dowolnego nietrywialnego interfejsu API lub biblioteki.
• Przekazywanie obiektów jako parametrów jest całkowicie OK. Spójrz na API Java, a zobaczysz wiele interfejsów, które odbierają obiekty jako parametry.
• Klasy w bibliotekach, których używasz, pisane były przez zwykłych śmiertelników, takich jak ty i ja, więc te, które piszemy, nie są „niestandardowe” , po prostu są.

Edytować:

Jak stwierdza @ Tom.Bowen89 , testowanie metody showInfo nie jest dużo bardziej skomplikowane:

showInfo(new Student(8812372,"Peter Parker",16,8.9));

1. W twoim przykładzie studenckim zakładam, że to proste, aby wywołać konstruktora studenta, aby utworzyć ucznia, który przejdzie do showInfo. Więc nie ma problemu.
2. Zakładając przykład Uczeń jest celowo trywializowany dla tego pytania i trudniej go skonstruować, wtedy możesz użyć podwójnego testu . Istnieje wiele opcji podwójnych testów, próbnych prób, skrótów itp., O których mowa w artykule Martina Fowlera do wyboru.
3. Jeśli chcesz, aby funkcja showInfo była bardziej ogólna, możesz iterować ją po zmiennych publicznych, a może publiczni akcesory obiektu przekazali i wykonali logikę show dla wszystkich z nich. Następnie możesz przekazać dowolny obiekt zgodny z tą umową i będzie działać zgodnie z oczekiwaniami. To byłoby dobre miejsce do korzystania z interfejsu. Na przykład przekaż obiekt Showalny lub ShowInfoable do funkcji showInfo, która może wyświetlać nie tylko informacje o studentach, ale także informacje o dowolnym obiekcie implementującym interfejs (oczywiście interfejsy te wymagają lepszych nazw w zależności od tego, jak konkretny lub ogólny chcesz obiekt, do którego możesz przekazać być i czym Student jest podklasą).
4. Często łatwiej jest ominąć prymityw, a czasem jest to konieczne dla wydajności, ale im więcej można grupować podobne pojęcia, tym bardziej zrozumiały będzie twój kod. Jedyną rzeczą, na którą należy uważać, jest próba rezygnacji z tego i ukończenia korporacyjnego fizzbuzz .

Steve McConnell w Code Complete zajął się tym problemem, omawiając zalety i wady przekazywania obiektów do metod zamiast korzystania z właściwości.

Wybacz mi, jeśli pomylę niektóre szczegóły, pracuję z pamięci, ponieważ minął ponad rok, odkąd miałem dostęp do książki:

Dochodzi do wniosku, że lepiej nie używać obiektu, zamiast tego wysyłać tylko te właściwości, które są absolutnie niezbędne dla metody. Metoda nie powinna wiedzieć nic o obiekcie poza właściwościami, których będzie używał w ramach swoich operacji. Z czasem, jeśli obiekt zostanie kiedykolwiek zmieniony, może to mieć niezamierzone konsekwencje dla metody używającej obiektu.

Zwrócił również uwagę, że jeśli skończysz na metodzie, która akceptuje wiele różnych argumentów, to prawdopodobnie jest to znak, że metoda robi zbyt wiele i powinna zostać podzielona na więcej, mniejszych metod.

Czasami jednak czasami potrzebujesz wielu parametrów. Podany przez niego przykład dotyczy metody, która buduje pełny adres przy użyciu wielu różnych właściwości adresu (choć można to obejść, używając tablicy ciągów, gdy się nad tym zastanowić).

Znacznie łatwiej jest pisać i czytać testy, jeśli zdasz cały obiekt:

public class AStudentView {
    @Test 
    public void displays_failing_grade_warning_when_a_student_with_a_failing_grade_is_shown() {
        StudentView view = aStudentView();
        view.show(aStudent().withAFailingGrade().build());
        Assert.that(view, displaysFailingGradeWarning());
    }

    private Matcher<StudentView> displaysFailingGradeWarning() {
        ...
    }
}

Dla porownania,

view.show(aStudent().withAFailingGrade().build());

wiersz można zapisać, jeśli wartości są przekazywane osobno, jako:

showAStudentWithAFailingGrade(view);

gdzie rzeczywiste wywołanie metody jest gdzieś zakopane

private showAStudentWithAFailingGrade(StudentView view) {
    int someId = .....
    String someName = .....
    int someAge = .....
    // why have been I peeking and poking values I don't care about
    decimal aFailingGrade = .....
    view.show(someId, someName, someAge, aFailingGrade);
}

Mówiąc o tym, że nie można umieścić rzeczywistego wywołania metody w teście, jest to znak, że interfejs API jest zły.

Powinieneś przekazać to, co ma sens, kilka pomysłów:

Łatwiej przetestować. Jeśli trzeba edytować obiekty, co wymaga najmniejszego refaktoryzacji? Czy ponowne użycie tej funkcji do innych celów jest przydatne? Jaka jest najmniejsza ilość informacji potrzebnych do nadania tej funkcji, aby spełniała swoje zadanie? (Po rozbiciu go - może to pozwolić na ponowne użycie tego kodu - należy uważać, aby nie upaść przy projektowaniu tej funkcji, a następnie wąskim gardłem wszystkiego, aby korzystać wyłącznie z tego obiektu).

Wszystkie te zasady programowania są jedynie wskazówkami, które pomogą ci myśleć we właściwym kierunku. Po prostu nie buduj bestii kodowej - jeśli nie masz pewności i chcesz kontynuować, wybierz kierunek / swój własny lub sugestię tutaj, a jeśli osiągniesz punkt, w którym myślisz „och, powinienem to zrobić sposób ”- prawdopodobnie możesz łatwo wrócić i przebudować go z łatwością. (Na przykład, jeśli masz klasę Nauczyciela - potrzebuje tylko tej samej właściwości, co Student, i zmieniasz funkcję, aby zaakceptować dowolny obiekt formularza Osoba)

Byłbym najbardziej skłonny do przekazywania głównego obiektu - ponieważ jak koduję, łatwiej wyjaśnić, co robi ta funkcja.

Jedną wspólną drogą wokół tego jest wstawienie interfejsu między dwoma procesami.

public class Student {

    public int id;
    public String name;
    public int age;
    public float score;
}

interface HasInfo {
    public String getInfo();
}

public class StudentInfo implements HasInfo {
    final Student student;

    public StudentInfo(Student student) {
        this.student = student;
    }

    @Override
    public String getInfo() {
        return student.name;
    }

}

public class Window {

    public void showInfo(HasInfo info) {

    }
}

Czasami robi się to trochę nieporządnie, ale w Javie jest trochę łatwiej, jeśli używasz wewnętrznej klasy.

interface HasInfo {
    public String getInfo();
}

public class Student {

    public int id;
    public String name;
    public int age;
    public float score;

    public HasInfo getInfo() {
        return new HasInfo () {
            @Override
            public String getInfo() {
                return name;
            }

        };
    }
}

Następnie możesz przetestować Windowklasę, podając jej fałszywy HasInfoobiekt.

Podejrzewam, że jest to przykład wzoru dekoratora .

Dodany

Wygląda na pewne zamieszanie spowodowane prostotą kodu. Oto kolejny przykład, który może lepiej zademonstrować tę technikę.

interface Drawable {

    public void Draw(Pane pane);
}

/**
 * Student knows nothing about Window or Drawable.
 */
public class Student {

    public int id;
    public String name;
    public int age;
    public float score;
}

/**
 * DrawsStudents knows about both Students and Drawable (but not Window)
 */
public class DrawsStudents implements Drawable {

    private final Student subject;

    public DrawsStudents(Student subject) {
        this.subject = subject;
    }

    @Override
    public void Draw(Pane pane) {
        // Draw a Student on a Pane
    }

}

/**
 * Window only knows about Drawables.
 */
public class Window {

    public void showInfo(Drawable info) {

    }
}

Masz już wiele dobrych odpowiedzi, ale oto kilka innych sugestii, które mogą pozwolić ci zobaczyć alternatywne rozwiązanie:

• Twój przykład pokazuje, że Student (wyraźnie obiekt modelowy) jest przekazywany do Okna (najwyraźniej obiekt na poziomie widoku). Pośredni obiekt Controller lub Presenter może być korzystny, jeśli jeszcze go nie masz, umożliwiając odizolowanie interfejsu użytkownika od modelu. Kontroler / prezenter powinien zapewnić interfejs, którego można użyć do zastąpienia go do testowania interfejsu użytkownika, i powinien używać interfejsów do odwoływania się do obiektów modelu i wyświetlania obiektów, aby móc odizolować go od obu do testowania. Może być konieczne zapewnienie abstrakcyjnego sposobu ich tworzenia lub ładowania (np. Obiekty fabryczne, obiekty repozytorium lub podobne).

• Przeniesienie odpowiednich części obiektów modelu do obiektu przenoszenia danych jest użytecznym podejściem do łączenia, gdy model staje się zbyt złożony.

• Być może Twój Uczeń narusza Zasadę Segregacji Interfejsu. Jeśli tak, korzystne może być podzielenie go na wiele interfejsów, z którymi łatwiej jest pracować.

• Leniwe ładowanie może ułatwić tworzenie wykresów dużych obiektów.

To właściwie przyzwoite pytanie. Prawdziwym problemem jest tutaj użycie terminu „obiekt”, który może być nieco niejednoznaczny.

Zasadniczo w klasycznym języku OOP termin „obiekt” zaczął oznaczać „instancję klasy”. Instancje klas mogą być dość ciężkie - własności publiczne i prywatne (i te pośrednie), metody, dziedziczenie, zależności itp. Naprawdę nie chciałbyś używać czegoś takiego do przekazywania niektórych właściwości.

W tym przypadku używasz obiektu jako kontenera, który po prostu przechowuje niektóre prymitywy. W C ++ takie obiekty były znane jako structs(i nadal istnieją w językach takich jak C #). W rzeczywistości konstrukcje zostały zaprojektowane dokładnie na użytek, o którym mówisz - zgrupowały powiązane obiekty i prymitywy, gdy miały logiczną relację.

Jednak we współczesnych językach tak naprawdę nie ma różnicy między strukturą a klasą podczas pisania kodu , więc możesz używać obiektu. (Za kulisami istnieją jednak pewne różnice, o których powinieneś wiedzieć - na przykład struct jest typem wartości, a nie typem odniesienia). Zasadniczo, dopóki utrzymasz prosty obiekt, będzie to łatwe przetestować ręcznie. Współczesne języki i narzędzia pozwalają jednak nieco to złagodzić (poprzez interfejsy, kpiny, wstrzykiwanie zależności itp.)