Почему делегирование класса так загадочно?

Question

Вероятно, это еще один сложный вопрос новичка, который заставит всех хлопнуть себя по лбу и сказать: «Дааааа!» НО, после очередного долгого периода чтения и просмотра бесчисленных видеороликов Брэда Ларсона, я остаюсь озадаченным, почему делегирование вообще и делегирование CALayer в частности, кажется такой загадочной темой.

Все книги и д-р Ларсон говорят о «не подклассификации CALayers», если вы не хотите высокой степени инкапсуляции, но нигде я не нашел краткого и точного примера преимуществ, которые может предложить делегация CALayer. Кажется, что каждый использует либо объект контроллера представления хоста в качестве своего рода небрежного делегата, либо они сгребают все в делегат приложения «в качестве краткого примера того, чего можно достичь».

Я пытаюсь выучить «ЛУЧШУЮ ПРАКТИКУ» заранее - потому что я такой новый и потому что я не хочу развивать какие-то плохие или неряшливые черты программирования - поэтому я стремлюсь изучить каждый новый шаг, который я взять в мельчайших деталях. Из того, что я могу собрать, класс делегатов CALayer содержит только около 3 специфичных для делегата методов. Это 'displayLayer:', 'drawLayer: InContext:' и 'actionForLayer: ForKey:'. В моих сгенерированных Opacity Quartz я использовал цветовые переменные, которыми я хочу манипулировать во время выполнения, и делаю это без подкласса CALayer. Одним из побочных эффектов использования пар ключ-значение является то, что существует метод класса с именем defaultValueForKey:, который описывает начальное значение моих цветов в соответствии со значением ключа, используемым для их идентификации. Это НЕ (очевидно) метод делегата CALayer. Итак, как я могу реализовать этот код (который после всего устанавливает только значение по умолчанию) без подкласса CALayer? Похоже, что делегирование в порядке, если вам нужны только несколько специфичных для делегата методов.

Может ли кто-нибудь объяснить, почему при реализации делегирования сотрудники Apple не просто переносили модуль компиляции определения метода из модуля класса в назначенный модуль делегата. например Просто поместите начальный параметр перед каждым методом, обычно доступным в классе (или подклассе) по фразе; 'forLayer: (CALayer *) TheRest: OfThe: метод'? Таким образом, простой переключатель или стек if-then может применить обычный метод класса в одном централизованном объекте - делегате.

Как я уже сказал в начале, я, вероятно, упускаю что-то довольно простое, но кто-нибудь может мне сказать, как я реализую все свои переменные цвета для ключевого значения без подкласса CALayer?

Спасибо заранее, * 1011 В.В. *

Answer 1

Ты слишком много думаешь.Как вы упомянули, вы новичок в платформе.В Какао есть много идиом, но одна из них похожа на Perl: «есть несколько способов сделать это».

Какао имеет историю делегирования, потому что большую часть времени вам просто нужнометод или два, и кто хочет сложность из миллиона классов с несколькими методами.Делегаты позволяют вам обойти это простым способом.

Так что, в основном, вместо того, чтобы анализировать все с общей инженерной точки зрения, просто используйте платформу.Напишите немного кода.Напишите некоторый код "неправильный путь".Напишите об этом много.

Почему?Потому что, если это «неправильный путь», вы сами это почувствуете.Вы начнете проклинать его в процессе обслуживания или чего-то еще, а затем вы поймете «правильный путь».Что такое «правильный путь»?То, как вам удобнее.

Большинство из этих решений оказывают минимальное влияние на производительность и т. Д., Поэтому не беспокойтесь об этом.И поэтому не имеет значения, какую технику вы выберете.

Пишите код.Много пиши об этом.Чем больше вы пишете, тем больше вы чувствуете, когда какая техника правильна, а какая нет.Или когда правильный путь до сих пор становится неправильным и должен быть реорганизован в новый правильный путь.

Потому что то, что правильно или неправильно сейчас, может быть не позже.