Концептуально, как это должно быть структурировано в ООП?

Question

Итак, у меня есть UIImageView, который можно вращать вокруг его центра с помощью touchsMoved.

В настоящее время весь код находится внутри моего ViewController, обнаруживает касание, вычисляет и отслеживает текущее вращение, само изображение и фактическое вращение изображения.

Но теперь я хочу привести это в порядок и сделать это правильно. Этот «блесна», который я создал, должен быть отдельным объектом, который может быть создан несколько раз и помещен туда, где он мне нужен.

Итак, я создаю свой новый класс Spinner, и он отслеживает свои собственные свойства изображения и угла ...

Но должен ли это быть объект NSObject со свойством UIImageView, или это действительно сам UIImageView? И как следует обрабатывать касания, должен ли ViewController играть роль или объект может каким-то образом отслеживать свои прикосновения?

-

Отредактировано: все еще надеюсь на четкий ответ на этот мой старый вопрос.

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

Но когда это сложнее с положением, скоростью, необходимо взаимодействовать с другими объектами, сохраняться при многократных запусках (подкласс NSManagedObject?) И т. Д. Касание и изображение становятся лишь малой частью целого. Вот почему я думал, что UIImage будет просто еще одним свойством объекта.

В качестве простого примера представьте, как в коробке отскакивает куча шаров. Они должны отскакивать от боков, отскакивать друг от друга, вращаться, реагировать на гравитацию, реагировать на прикосновения - и сохраняться между запусками.

Итак, концептуально, как это должно быть структурировано в ООП?

Answer 1

Вы должны использовать UIControl в качестве родительского класса, со свойством UIImageView, добавленным в качестве подпредставления. В UIControl есть методы, которые вы можете переопределить для отслеживания касаний.

Answer 2

Вы спрашиваете о «правильном пути», как будто в ООП есть один правильный ответ.

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

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

В вашем примере: переход от вращающегося в касание вращателя к чему-то, что является частью двумерного физического моделирования ... это довольно длинный прыжок.Почему я бы даже хотел реализовать это с помощью общего базового класса?

• Если вы просто хотите, чтобы базовый класс для «чего-то на экране могло вращаться» ... Я бы сказал, что этослишком общий.Недостаточно добавленной стоимости, чтобы оправдать новый класс для этого: UIView уже может это сделать.

• Если ваш исходный объект был предназначен для получения пользовательского ввода, тогда придерживайтесь шаблона проектирования.iOS и подкласс UIControl.

• Если вы предполагаете физическое моделирование.Тогда у вас, вероятно, будет целая структура класса, которая не зависит от того, как она отображается на экране:

Жесткий класс для описания механических свойств (форма, вес, ...) каждого объекта(возможно, дерево классов. Вы можете использовать отдельные делегаты для обнаружения столкновений.) RigidState, описывающий положение и скорость для Rigid.RigidSimulator, владеющий набором Rigids и RigidState для каждого жесткого диска.RigidViewController, который может создать UIView (возможно, UIImageView) для данного Rigid и может отрегулировать его размер и положение (учитывая RigidState).... Что-то в этом роде.

Answer 3

У меня есть объект, который очень похож на это. Я называю это MBlob, для MediaBlob. Он знает, как делать все что угодно, например, как разделить его на 2, объединить с другим MBlob (изменение размера соответствующим образом на основе формы) и т. Д. Он также знает, как порождать себя в WebView (загрузка URL), получать измененный размер (например, поворот, жесты) и т. д. Очень удобный класс для создания небольших приложений, и я предполагаю, что у многих разработчиков есть нечто подобное. Аналогичный класс используется в приложениях моего магазина приложений, QCount (бесплатно) и QPlus.

Один из способов структурирования объектов, таких как объект, заключается в том, что он является потомком NSObject, а затем подключает некоторые протоколы для встроенных элементов, которые вы хотите использовать. Например, мой интерфейс выглядит так:

@interface MBlob : NSObject <UIWebViewDelegate, UIPopoverControllerDelegate> {
    id _delegate;
}

Все свойства реализованы как @synthesize varName = _varName в файле .m.

Тогда вы можете подключить все виды просмотров из этого пункта. Это может быть излишним, но мой MBlob даже знает, как запустить редактор настроек, чтобы редактировать свои собственные настройки, не беспокоясь о собственном VC. Вот немного пищи для размышлений:

@property (nonatomic, strong) UIView* preview;
@property (nonatomic, strong) UIView* displayView;
@property (nonatomic, strong) UIWebView* webView;
@property (nonatomic, strong) UIToolbar* toolbar;
@property (nonatomic, strong) UIActivityIndicatorView* activityIndicator;
@property (nonatomic, strong) NSTimer* timer;
@property (nonatomic, strong) NSString* mediaType;
@property (nonatomic, strong) NSString* mediaValue;
@property (nonatomic) CGFloat   aspectRatio; // width:height
@property (nonatomic) BOOL      aspectRatioLocked; 
@property (nonatomic) CGSize    nativeSize;
@property (nonatomic) CGPoint   nativeLocation;
@property (nonatomic, strong) NSString* title;
@property (nonatomic, strong) UITextField* titleTextField;
@property (nonatomic, strong) UIFont* font;
@property (nonatomic) BOOL fullScreen;
@property (nonatomic, strong) WebviewButtonPreferences* webviewButtonPreferences;
@property (nonatomic, strong) PreferencesEditorViewController* preferencesEditorVC;

Мое единственное предупреждение в том, что Apple упростила многие вещи с помощью встроенных классов, поэтому не переусердствуйте. Например, в моем коде выше, мне действительно нужен шрифт? Я не знаю, это больше не мой активный код, но это пример объекта, который вы описываете. Если вы добавите больше функциональности, выберите подкласс NSObject и создайте любой другой класс, для которого вы хотите использовать свойство.

Удачи,

Дэмиен