ios - Swift: To struct, or not to struct -

i'm making switch objective-c swift. i'm creating view layout system client make apps more flexible in layout, without using auto layout want design screens remotely , auto-layout complex them. tried using structs , protocols found quite clumsy, i'm suspecting i'm not thinking right way.

with classes, structure follows:

class viewmodel {     var frame: cgrect = .zero }  class viewgroupmodel: viewmodel {     var weight: int = 1     var children:[viewmodel] = [viewmodel]() }  class horizontalviewgroupmodel: viewgroupmodel { }  class verticalviewgroupmodel: viewgroupmodel { } 

i tried approach protocols defining viewmodel protocol, , viewgroupmodel protocol, found created lot of duplication (properties). there better approach? considered practice use classes in case?

edit: in case better not uses classes, looking answer gives me concrete solution in terms of structs , protocols.

if concern merely how implement protocol's properties, wouldn't let sway choice between struct vs class. if had variety of properties struct types must implement, have 2 basic options:

1. if you're talking few properties, implement few properties in struct types conform protocol. time. e.g. when defining custom types conform mkannotation, implement 3 required properties.

   sure, if we're talking larger set of properties, gets tedious, compiler holds our hand through process, ensuring don't miss anything. challenge modest.

2. while i'm not fan of approach, https://stackoverflow.com/a/38885813/1271826 shows implement shared properties component, have struct wrap of these properties, , implement default computed properties protocol in extension:

   enum subviewarrangement {     case none     case horizontal     case vertical     case flow }  struct viewcomponent {     var frame = cgrect.zero     var weight = 1     var subviews = [viewmodel]()     var subviewarrangement = subviewarrangement.none }  protocol hasviewcomponent {     var viewcomponent: viewcomponent { set } }  protocol viewmodel: hasviewcomponent { }  extension viewmodel {     var frame: cgrect {         { return viewcomponent.frame }         set { viewcomponent.frame = newvalue }     }     var weight: int {         { return viewcomponent.weight }         set { viewcomponent.weight = newvalue }     }     var subviews: [viewmodel] {         { return viewcomponent.subviews }         set { viewcomponent.subviews = newvalue }     }     var subviewarrangement: subviewarrangement {         { return viewcomponent.subviewarrangement }         set { viewcomponent.subviewarrangement = newvalue }     } } 

   where, can create instance conforms viewmodel, so:

   struct labelmodel: viewmodel {     var viewcomponent = viewcomponent() }  var label = labelmodel() label.weight = 2 print(label.weight) 

   i have confess, isn't elegant approach. (i hesitate present it.) avoids having implement of properties individually in types conform viewmodel.

so, let's set property question aside. real question whether should using value type (struct) or reference type (class). think it's illuminating consider apple's discussion of value vs reference semantics near end (@42:15) protocol-oriented programming in swift video. touch upon cases may still want use classes. example, suggest might want use reference types when, "copying or comparing instances doesn't make sense". suggest rule might apply when dealing "window" instances. same applies here.

on top of that, doesn't seem me there benefit use value types represent view hierarchy, collection of reference type objects. makes more confusing. stick class types, accurately mirror view hierarchy represents.

don't me wrong: we're used using reference types think it's challenge our preconceived notions , take long hard @ whether value type better address situation. in case, though, wouldn't worry , stick class hierarchy mirrors hierarchy of objects you're modeling.

---

that having been said, class hierarchy proposed in question doesn't quite feel right, either. feels strange can instantiate viewmodel can't later add subviews (whereas uiview objects have subview property). also, horizontal , vertical group types don't feel correct either. example, should single type "axis" property, uistackview or other "arrangement" property, broaden notion capture uicollectionview layouts, too?. you'll see in viewcomponent example, above, i've flattened bit, these 2 caveats in mind, whatever see fit.