Help me find the correct object-oriented design-pattern/workflow

February 8, 2009 9:32 AM

Help me find the correct object-oriented design-pattern/workflow

I am working a new project in objective-c, however I am having trouble finding the optimal design for the workflow. Most of the work I have been doing so far has been on the abstract frameworks/engine, but now I am playing around with different implementations in a class called Sketch, continuously changing the settings and logic. So far I have been just changing the code, commenting out this and that, all in the same file, thus losing previous setups. I am using version control, however not sure if I should be branching these various setups, as I wouldn't want the changes for the specific sketch to propagate back up. I may want to refine it to one master Sketch at one point, or merge together several, but at this point I just want to have a good workflow setup so that I can play around at will, testing out ideas.

So what is the optimal design pattern to be able to work both on the frameworks, in one place, and these various implementations of it. Subclassing the Sketch class from one generic class, or interfacing? Keeping the frameworks in a different folder, importing it as a static library into sketch projects?.. thanks!

posted by martini to computers & internet (5 answers total)

Do you have a spec? It sounds like you don't know what you're building. If you don't have a spec, you should stop writing code and start figuring out what you're really building.

You don't need to branch if you're trying things out. Just check-in everytime you think you have something useful that you may want to roll back to. That way its all in the version history. Much better than commenting things out. Of course, you don't want to break other people who need to work in the code, so make sure what you have always builds. Though it sounds like you may be the only one working on it.
posted by jeffamaphone at 9:42 AM on February 8, 2009

Yes it is a personal project, I am the only one working on it, and no I don't have a spec, it is a creative project where I just code in new ideas as I go along. Also I should note that I have a secondary intention of publishing the API and having a downloadable empty project for someone to work on who was not familiar with iPhone development, and could just tell them, put your whole program in Sketch.m or whatever, and stick to these C functions.
posted by martini at 9:47 AM on February 8, 2009

To keep things relatively simple, if you're doing things with a standard iPhone MVC pattern, in your main view controller's viewDidLoad or initWithNibName:

// Sketchv1 *sketchv1 = [[Sketchv1 alloc] initWithNibName:@"Sketchv1" bundle:nil];
// [self.view addSubview:[sketchv1 view]];

// Sketchv2 *sketchv2 = [[Sketchv2 alloc] initWithNibName:@"Sketchv2" bundle:nil];
// [self.view addSubview:[sketchv2 view]];

// Sketchv3 *sketchv3 = [[Sketchv3 alloc] initWithNibName:@"Sketchv3" bundle:nil];
// [self.view addSubview:[sketchv3 view]];

Make Sketchv1-v3 subclasses of Sketch with your different method overrides and new methods in them, uncomment whichever on you want to work with in the main view controller, go to town.

It does sound like you'd make yourself happier in the very long run if you stopped now that things have hit this level of "what now?" complexity and planned and documented a bit. Specifically if the idea is to end up with an API, you could work backwards from the interface you want to end up offering.
posted by Your Time Machine Sucks at 10:08 AM on February 8, 2009

This is a pretty darn confusing question -- are you asking how to handle your workflow, or how you should structure your code? Those are two completely separate issues which you seem to be treating interchangeably.

For the code structure: there's no way for anyone to help you with this, since you haven't described what you're trying to build.

For the workflow: your first step should be to write yourself a spec. Put down the keyboard, grab a pencil and at the very least sketch out an object model. Personally I tend to start with the interface and work backwards from there to determine what objects and data structures I'll need to support it. Some people start from the data structure and work up to the interface. It depends on what you're trying to build.

Once you've got at least a high-level roadmap of what you're trying to build, you can start coding without having to stop and change everything around multiple times as you go along.


I have a secondary intention of publishing the API

It is way, way, way too early to be thinking about this.
posted by ook at 10:13 AM on February 8, 2009

It may help if you try the following: imagine or role-lay being a "Sketch". What are your responsibilities to other code, what must you do internally to meet those responsibilities, what other objects do you need to use or own to meet those responsibilities?
posted by orthogonality at 11:24 AM on February 8, 2009 [1 favorite]