Conceptually, how should this be structured in OOP?

Question

So, I have a UIImageView that can be rotated around its center using touchMoved.

Currently, all the code is inside my ViewController, detecting the touch, calculation and tracking of the current rotation, the image itself and the actual rotation of the image.

But now I want to remove it and do it right. This "spinner" that I created must be a separate object that can be created several times and dropped to where I need it.

So, I create my new Spinner class and track its own image and angle properties ...

But should it be an NSObject with the UIImageView property, or is it the UIImageView itself? And how should orders be handled, does the ViewController need to play any role, or can the object somehow track its own touches?

-

Edited: Still hoping for a clear answer to this old question of mine.

Subclass of UIControl I assume it makes sense when my counter is more than an abstract image that rotates and responds to touch.

But when it is more complex with position, speed, it is necessary to interact with other objects, be saved in several starts (subclass NSManagedObject?), Etc. Touch and image become only a small part of the whole. That's why I thought UIImage would be just another property of the object.

As a simple example, think of a bunch of balls jumping in a box. They should bounce off the sides, bounce off of each other, rotate, respond to gravity, respond when touched - and persist between starts.

So conceptually, how should this be structured in OOP?

Answer 1

You ask for the “right path”, as if the OOP had one correct answer.

In fact, there is not a single right design. It's all about how you expect the code to be expanded and reassigned in the future.

If you really want to prepare for every imaginary extension, then you end up with a ridiculously complex design and still won't cover it all.

In your example: moving from a touch-based controlled counter to something that is part of 2D physics modeling ... it's a pretty long jump. Why would I even want to implement this with a common base class?

• If you just need a base class for “something on the screen that can rotate” ... I would say that is too general. Not enough added value to justify the new class: UIView can already do this.

• If your source object was intended for user input, then stick with the iOS design pattern and the UIControl subclass.

• If you fancy a physical simulation. Then you probably have a whole class structure that does not depend on how it is displayed on the screen:

A Hard class to describe the mechanical properties (shape, weight, ...) of each object (possibly a class tree. You can use separate delegates to detect conflicts). Rigid state describing the position and speed for Rigid. RigidSimulator, owning a set of Rigids and RigidState for each tight. A RigidViewController that can create a UIView (possibly a UIImageView) for a given hard drive and can adjust its size and position (considering RigidState). ... Something like that.

Answer 2

You should use UIControl as a parent class with the addition of the UIImageView property as a subquery. UIControl has methods that you can override to track touches.

Answer 3

I have an object that is very similar to this one. I call it MBlob for MediaBlob. He knows how to do all kinds of things, for example, how to divide it into 2, combine with another MBlob (resize accordingly based on the form), etc. He also knows how to appear in the WebView (loading the URL), receive (for example, rotation, gestures), etc. A very convenient class for creating small applications, and I assume that many developers have something similar. A similar class is used in applications for application applications, QCount (free) and QPlus.

One way to structure, such as an object, is a child of NSObject, and then connect to some protocols for the inline elements that you want to use. For example, my interface looks like this:

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

All properties are implemented as @synthesize varName = _varName in the .m file.

Then you can connect all kinds of views from this element. This may be redundant, but my MBlob even knows how to start the settings editor to edit its own settings without worrying about VC ownership. Here is food for thought:

 @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; 

My caveat is that Apple made a lot of things easy thanks to the built-in classes, so don't overdo it. For example, in my code above, do I really need a font? I do not know, this is not active code for me, but this is an example of the type of object you are describing. If you add more functionality, go with the umbrella subclass of NSObject and create any other class that you want to use.

Good luck

Damien