10
Zauważyłem, że nawet przy przestrzeganiu zasady OOD jednorazowej odpowiedzialności, czasami klasy nadal rosną. Czasami dostęp do zmiennych członków bezpośrednio w metodach przypomina globalny stan i wiele rzeczy istnieje w bieżącym zakresie. Wystarczy spojrzeć na obecnie działającą metodę, nie można już określić, skąd pochodzą zmienne invidiual dostępne w bieżącym zakresie.Czy uzyskać dostęp do zmiennych członków bezpośrednio lub przekazać jako parametr?
Kiedy ostatnio współpracowałem z przyjacielem, zdałem sobie sprawę, że piszę o wiele bardziej szczegółowy kod niż on, ponieważ przekazuję zmienne członkowskie wciąż jako parametry do każdej z metod.
Czy to jest zła praktyka?
edit: Przykład:
class AddNumbers {
public:
int a, b;
// ...
int addNumbers {
// I could have called this without arguments like this:
// return internalAlgorithmAddNumbers();
// because the data needed to compute the result is in members.
return internalAlgorithmAddNumbers(a,b);
}
private:
int internalAlgorithmAddNumbers(int sum1, int sum2) { return sum1+sum2; }
};
Jeśli twoje zajęcia są zbyt duże, podziel je. Jeśli masz zmienną składową, użyj jej. Jeśli nie używasz zmiennych członkowskich w metodzie, prawdopodobnie powinno to być 'static', ale robi to dziwnie. – Flexo
Przepraszam, wydaje mi się, że mam mały problem z twoim angielskim. Przekazujesz zmienne składowe jako parametry? Publiczne zmienne członków? Lub nowe wartości dla tych zmiennych członkowskich? Jestem trochę zdezorientowany. – ATaylor
Przepraszam, że nie było to jasne. Podczas implementacji algorytmu zwykle ponownie analizuję parametry, jakie przyjmuje sygnatura metody, chociaż dane wymagane przez algorytm mogą być w rzeczywistości pobierane bezpośrednio ze zmiennych składowych. Załóżmy, że masz klasę, która dodaje dwie liczby i ma 2 liczby a i b jako zmienne składowe. Wtedy zamiast mieć prywatną metodę dodawania z zerowymi parametrami, nadal definiowałbym funkcję przyjmującą 2 argumenty int. W ten sposób mogłem później ponownie użyć algorytmu również poza klasą. – Tom