有问题的申请建立如下：
用户选择作业 这份工作可以有很多组成部分 每个组件可以有许多lineitems。我不清楚这应该如何构建 - 这应该是阶级还是结构？ 看到一次只处理一份工作，我相信工作应该是一个班级。 但是，当某个对象类型有多个时，我不清楚如何形成它们，比如组件和lineitem对象。
该应用程序由ViewControllers和TableViewControllers组成。 所有数据都是从JSON中的服务器获取的，并根据需要填充到适当的视图中。 以下是当前设置的对象类型：
工作对象：
// Job Object // public struct Job { static var globalId : String? static var name : String? static var status : String? static var client = Client() static var components = Array<Component>() // etc.. }像这样的组件：
// JobComponent Object // public struct Component { var name:String? = "" var fmRecordId : String? var startTS:NSDate? var endTS:NSDate? var notes:String? = "" var items = Array<Lineitem>() // etc... }最后，一个lineitem：
// Lineitem Object // public struct Lineitem { var fmRecordId = String() var itemName = String() var itemNumber = String() // etc... }所有这些对象都构建在名为“PL”的public class 。
当用户选择lineitem并编辑它的值时，这些值在编辑它们的VC之外是不可用的，因为VC没有引用传递的lineitem，它只是复制它。 组件也是如此。
我找到的解决方法是使用Job struct PL.Job.self并始终修改组件和lineitems，如下所示i =数组中所需的索引：
PL.Job.components[i]访问组件 PL.Job.components[i].items[i]访问该组件中的特定项目。但是，这不能很好地扩展。
期望的行为是能够将引用传递给对象的特定实例，而不是传递PL.Job对象中这些对象的索引路径。
我很清楚目前的结构存在问题，但有人可以指出我正确的方向吗？
The application in question is built as follows:
A user selects a job the job can have many components each component can have many lineitems.I am not clear on how this should be structured - should this be class or structs? Seeing that only one job is being processed at a time, I am fairly confident that jobs should be a class. However, when there are multiples of a certain object type, I am not exactly clear on how to form them, like the components and lineitem objects.
The application consists of ViewControllers and TableViewControllers. All the data is fetched from a server in JSON and populated into the appropriate view as needed. Here are the object types as they are currently setup:
A job object:
// Job Object // public struct Job { static var globalId : String? static var name : String? static var status : String? static var client = Client() static var components = Array<Component>() // etc.. }A Component like so:
// JobComponent Object // public struct Component { var name:String? = "" var fmRecordId : String? var startTS:NSDate? var endTS:NSDate? var notes:String? = "" var items = Array<Lineitem>() // etc... }and finally, a lineitem:
// Lineitem Object // public struct Lineitem { var fmRecordId = String() var itemName = String() var itemNumber = String() // etc... }All of these object are built within a public class called "PL".
When a user selects lineitem and edits it's values, the values are not available outside the VC in which they are edited because the VC isn't referencing the lineitem that is was passed, it is simply copying it. The same happens with components.
A workaround I found was to use the the Job struct PL.Job.self and always modify the components and lineitems like so where i = a desired index in the array:
PL.Job.components[i] to access a component PL.Job.components[i].items[i] to access a specific item within that component.However, this doesn't scale very well.
The desired behavior is to be able to pass a reference to a particular instance of an object around rather than pass around the index path of those objects in the PL.Job object.
I am well aware there is something wrong with how this is currently structured, but could someone please point me in the right direction?
最满意答案
几点：
您只能通过引用传递类实例。 如果您希望能够传递对特定LineItem或Component或Job的引用，并且希望能够对在任何地方都有效的对象进行更改，那么您需要将它们定义为类而不是结构。 结构类型的实例始终按值传递，而不是引用。 传递值类型时，会复制它，这意味着您创建了一个全新的对象副本，并且对副本进行变更不会对原始副本产生影响。
您的Job结构只有静态属性 - 也就是说，整个应用程序中只会有一个globalId ， name ， status等。 如果您想拥有多个Job实例，那么这些实例不应该是静态属性。 你说一次只能处理一个Job ，所以也许这是故意的。 无论哪种方式，仍然经常更喜欢创建具有这些属性的Job类的实例。 如果您决定在内存中保留对多个作业的引用，或允许用户在不同作业之间进行选择，或在作业之间切换等，它肯定会为您提供更大的灵活性。例如，您可能希望允许用户切换到他们之前处理的Job ，而不必破坏他们现在正在处理的Job 。
但我认为主要的一点是，如果您希望能够通过引用传递它们，则需要将对象定义为类。 如果修改通过引用传递的对象，则对同一对象的所有其他引用将显示相同的更改（因为，毕竟它们只是对同一对象的引用）。 这不适用于值类型，如结构。
A couple of points:
You can only pass class instances by reference. If you want to be able to pass a reference to a particular LineItem or Component or Job, and you want to be able to make changes to that object that are effective everywhere, then you need to define them as classes and not structs. Instances of struct types are always passed by value and not be reference. And when a value type is passed, it is copied, meaning that you create an entirely new copy of the object, and mutating the copy has no effect on the original.
Your Job struct only has static properties - i.e., there will only ever be one globalId, name, status etc. throughout your entire application. If you want to have multiple instances of Job, then these should not be static properties. You say that only one Job will be processed at a time, so maybe that was intentional. Either way, it is still often preferable to create an instance of a Job class that has those properties. It certainly would give you more flexibility later if you decide to make it possible to hold references to multiple jobs in memory, or to allow the user to select between different jobs, or switch between jobs, etc. For example, you may want to allow a user to switch to the Job they were processing earlier without necessarily destroying the Job that they are working on now.
But I think the main point is that you will need to define your objects as classes if you want to be able to pass them by reference. If you modify an object that is passed by reference, all other references to the same object will show the same changes (because, after all, they are just references to the same object). That doesn't work with value types, like structs.
更多推荐
发布评论