Metody użytkowe w obiektyw-c

Question

Gdzie należy umieścić metody użytkowe w funkcji -c?

E.g. dodatkowe narzędzia do zarządzania ścieżkami, które są wywoływane przez wiele klas.

Widziałem przykłady, gdzie są umieszczone w głównym pliku appdelegate i dlatego są dostępne dla wszystkich. Wydaje mi się to jednak trochę dziwne, ale ...

Answer 1

Tak, to jest dość dziwne (i zła praktyka).

Prawdopodobnie najczęstszym idiomem jest użycie kategorii do rozszerzenia istniejących klas systemowych. W kilku przypadkach, gdy żadna klasa systemowa nie jest odpowiednia, niektórzy mogą utworzyć klasę narzędzi składającą się głównie z metod klasy lub klasy singleton z metodami instancji.

To zależy od metod i miejsca, w którym pasują do ogólnej struktury aplikacji (i zawsze MVC za rzeczami).

Answer 2

Masz kilka opcji:

• Najprostszym rozwiązaniem jest mieć zbiór funkcji C dla typowych zadań (jeśli używasz rozszerzenia .m, można użyć objective-c obiektów w swoich funkcji C). Z Twojego kodu, na przykład, zadzwonisz na numer showAlertDialog().
• Możesz mieć "klasę narzędzi" z garstką metod klasy, które importujesz do każdego pliku. Na przykład możesz zadzwonić pod numer +[MyUtilities showAlertDialog]. Jest to najbardziej bezpośredni odpowiednik statycznych klas użytkowych, na przykład Java, ale jest trochę niezgrabny w Objective-C.
• Inną opcją, jak powiedział Paul Lynch, jest użycie kategorii w celu rozszerzenia wspólnych klas. Jedynym problemem jest to, że może to prowadzić do problemów z utrzymaniem. Działa również tylko w celu rozszerzenia już istniejących klas i tylko wtedy, gdy nie potrzebujesz dostępu do ivars. Możesz mieć kategorię dla NSObject, która umożliwiłaby dostęp do metod ze wszystkich twoich obiektów, ale zdecydowanie zaleciłbym, aby nie odpowiadała (może to prowadzić do poważnych problemów z utrzymaniem).

Osobiście używam kombinacji opcji 1 i 3. Kiedy mam funkcjonalność wyraźnie powiązaną z konkretną istniejącą klasą, używam kategorii. W przeciwnym razie używam funkcji C.