macOS Architecture Question: Best way to create objects from a file?

[ataylor2009]

Okay, so I have a software architecture question for those more experienced than myself (which is nearly everybody)...

I need to create about 150 objects. Each object has about a dozen instance variables. The variables (and hence the objects) do not change state during the life of the application (i.e., each object is created at runtime and does not change).

How would you recommend going about this? I'm familiar enough with arrays, property lists, dictionaries, etc. to do some research and (probably) figure out how to code it on my own, but I'm really having a hard time determining which is the best implementation strategy from an architectural standpoint. For example, I have no idea whether 1,800 items (150 objects * 12 variables) is too many for a *.plist file, etc., etc.

Thanks in advance for any advice you can offer.

 

[robbieduncan]

Well I suppose the first question is why you need a plist at all. If the objects are totally static can you not create them in code? If you need, or simply prefer, a plist/configurability for whatever reason then a plist would be fine: simply use an array as the root object and include a dictionary for each object you want to create. The dictionaries should contain key/value pairs for each ivar.

 

[ataylor2009]

Hard-coding 1,800 variables doesn't seem like a good idea...with the variable data in a text file that gets read into the 150 objects, when my variable data changes, I don't have to re-code / re-compile the code. I thought that was basic object-oriented design procedure?

 

[robbieduncan]

I thought that was basic object-oriented design procedure?

I agree it's a better idea to put it in a configuration file if you expect this data to ever change, but it's got absolutely nothing to do with OO programming or design: it's be a good idea in a purely procedural design.

 

[lee1210]

I would say you could have a path in a plist to where an archive lives. On my phone so I can't post a link, but you might want to look into Apple's Archives and Serializations Programming Guide, as there are already facilities in place to help you achieve this in a standard, architecturally independent way.

-Lee

 

[robbieduncan]

I would say you could have a path in a plist to where an archive lives. On my phone so I can't post a link, but you might want to look into Apple's Archives and Serializations Programming Guide, as there are already facilities in place to help you achieve this in a standard, architecturally independent way.

The only issue with this is that you have to have the objects in your code to serialise them. So you have to write the code to generate them once anyway...

 

[lazydog]

Okay, so I have a software architecture question for those more experienced than myself (which is nearly everybody)...

I need to create about 150 objects. Each object has about a dozen instance variables. The variables (and hence the objects) do not change state during the life of the application (i.e., each object is created at runtime and does not change).

How would you recommend going about this? I'm familiar enough with arrays, property lists, dictionaries, etc. to do some research and (probably) figure out how to code it on my own, but I'm really having a hard time determining which is the best implementation strategy from an architectural standpoint. For example, I have no idea whether 1,800 items (150 objects * 12 variables) is too many for a *.plist file, etc., etc.

Thanks in advance for any advice you can offer.

Hi

Quick question: Is the data for initialising your 1800 variables coming from another source, eg Excel, db, XML? Or are you coding the data by hand?!!! If by hand you may want to use something like Excel just to make data easier to enter and maintain, and then export as an initialisation file in csv, xml or whatever.

b e n

 

[ataylor2009]

The only issue with this is that you have to have the objects in your code to serialise them. So you have to write the code to generate them once anyway...

This is my problem exactly. I can't write the objects to a file, unless and until I have created the objects. Right now, I think my intent is to create the objects once at runtime, and then save the object graph to a file so they don't have to be created again next time (this plan is not fully baked yet, though).

The reason I want the data in a file is so that I can change it to alter the program's behavior. Imagine my objects are cars, and my variables are color, tire size, number of doors, etc. I'll almost certainly want to change the game later to represent, say, a 2-door blue sports car, versus the 4-door red station wagon I started out with.

 

[lee1210]

1) Bumping is unnecessary and discouraged by the forum rules.
2) If this was something I was working on, I'd write the archiving/serializing/plist'ing, etc. code first, test it on a few objects, then use it to generate a command line app that could be fed all the parameters for ONE object and serialized it. Then whatever format you have the data in, you can just use awk, etc. to generate the commands needed to run your command line serializer over all n-thousand records. Then you have the code you need to archive/unarchive already done, and can build that into your "full" app. I'm not saying this is the best, i'm sure others have an opinion on this as well, but I always try to write utilities that work correctly ONCE, then just run that thing N-thousand times before I'd write something that reads and parses a file, etc. since there are already great commandline tools to do that for you.

-Lee

 

[robbieduncan]

The option Lee suggests above is a good one. If you want to retain the flexibility of a file you can edit directly then a plist will be fine. I'd suggest a structure of something like this:

<plist>
 <array>
  <dict>
   <key>ObjectType</key>
   <string>ClassNameForThisObjectHere</string>
   <key>Configuration</key>
   <dict>
    <!-- Key value pairs for init here -->
   </dict>
  </dict>
  <!-- More objects here like above -->
 </array>
</plist>

So you iterate over the dictionaries in the array. For each dictionary extract the ObjectType and Configuration keys. For each ObjectType supported define an init method like:

-(id) initWithDictionary:(NSDictionary *) configuration
{
}

You can instansiate the object defined using the standard (well standard-ish) method of turning a NSString into a Class.

This pattern has issues, mostly that it's very easy to pass an invalid configuration dictionary to the object which will cause it to fail to instansiate correctly.

 

[pilotError]

You could always create an XML file and just load it during startup.

The benefit here is that you can edit the XML file with an editor without having to do any coding. The code to read it into a Dictionary or an object should be pretty straight forward as well.

 

[ataylor2009]

You could always create an XML file and just load it during startup. The benefit here is that you can edit the XML file with an editor without having to do any coding. The code to read it into a Dictionary or an object should be pretty straight forward as well.

Forgive me, but this seems like twice the work: Re-code my existing 1,800-line data file from plain text to XML (which I know nothing about), and then write some new code to read that other new code.

As for the two replies before the one I quoted above - I'm sorry, but I have no idea what you're talking about (which is not to say that the answers aren't correct, or that I don't appreciate you guys making the effort to help me). I don't need to edit the data file; it already exists. I may want to swap in a new data file for some future version of the application, but as long as the application can read a text file to build its library of objects, it shouldn't matter what's in the data file.

Let me try to rephrase my original question: I have a plain-text data file. There is one piece of data (whether it be a number or a string) on each line of the file (i.e. all separated by newlines). I want to create an object in my application, read the first 10 lines of data (or whatever) into the instance variables of the object, save the object, and repeat 150 times, and then get on with my application logic. Or maybe I need to repeat 150 times, and then save all the objects. I don't know (which is why I'm here).

Continued thanks to all of you for trying to help me out.

 

[kainjow]

If your file format is plain text, all separated by lines, and there is a fixed number of lines per each group/object, you can just use NSString's stringWithContentsOfFile: method, and then use componentsSeparatedByString: to get an array of all the lines. Then create a mutable array, loop through each line and create objects as necessary.

Why would you want to re-save it? There is no need for this if you can read the file directly in its original format.

Edit: it'd help if you can post a sample of your data file.

 

[larkost]

There is another posible solution for this: If your data is near-enough static, you might want to create a small script that could create a c file from your data, which could then be included in your program. This would have the benefit of being the fastest data access possible, while still allowing you some ease of maintenance.

 

[ataylor2009]

If your file format is plain text, all separated by lines, and there is a fixed number of lines per each group/object, you can just use NSString's stringWithContentsOfFile: method, and then use componentsSeparatedByString: to get an array of all the lines. Then create a mutable array, loop through each line and create objects as necessary.

This is the way I wrote the original version of the application. It works, but I thought somebody might know of a better way (or a more standardized way) of doing it.

 

[Kurukuru]

I wrote an application that did something along these lines recently, reading data from a plain text file, manipulating it (or not), then saving it...

Plain text file:
n=name of object
d=object's data
n=name of another object
d=another object's data

The program reads in the file, line at a time, using the ?= to know the meaning of each line (not strictly necessary if you know the order of the lines, but adds a little robustness). It creates a node in a singly linked list for each object, which is made up of (in this case) two lines of information. Before the program terminates, the linked list is written back out to the file (actually to a second copy of the file, to prevent permanent loss of data in case of power failure during the write).

 

[kainjow]

This is the way I wrote the original version of the application. It works, but I thought somebody might know of a better way (or a more standardized way) of doing it.

Well once your file is being read, "better" mostly applies to improving performance and memory use. Unless you notice those being a problem, I wouldn't touch it. Though you could put the code that loads the file in a separate thread if you notice it blocking the main thread.