Possible Duplicate:
How to Think in OO
I am sort of new to programming. I am working with Objective-C and iPhone app Dev. I am having some trouble wrapping my mind around the OOP mindset. Does anyone have any tips or tricks to think or visualize the programming process before you sit down and start it?
That is called designing. What you need to do is to write up use cases and identify your requirements (search information about functional and non-functional requirements). If you want to visualize your code, then you should read about UML.
When dealing with OO design one of the best approaches you can take is to step away from keyboard and thing of the problem in small building block type portions. Each of these objects will have properties that describe them and actions that they can execute, together this will encompass the notion of the self sufficient object and what it will need to get the job done. Once the building blocks are in place then you will think from a higher level of how these objects will interact with one another in order to solve the problem at hand. A tool that some people find handy for this is UML, but its a preference.
While reading about OO design and programming you'll come across two concepts: coupling and cohesion. The former is about how each class depends on each other, and the later is about a class focusing on those things that are its responsibility.
Without getting deeper on the topic, I bring up those two concepts because it has helped me a lot to thing on those terms. The first step is to be clear on what your application must do. Think about the "happy path" as well as what happens when things go wrong, for example the user not filling in the right information.
Now start designing your classes, how those relate and what each class provides to the system as a whole. This design phase is typically represented as a set of UML diagrams, but some written paragraphs would do if you are not familiar with UML. If you see a class is doing things that don't belong there, change your design. It's inexpensive to change it while on paper.
Don't start thinking on how to implement certain functions just yet. For example if your application will use the GPS hardware, don't worry on how to access it. Suppose that part is solved. Start thinking on what you'll do with the data? Which class will receive that data? Who's going to process it?
What you describe seems to suggest a question more about software design than about programming. To that end, I've found the best way to learn design paradigms, especially early on, is to consume good design. If you'd like to learn about OO design paradigms, write software that uses a high quality OO framework. Both the Java and .Net libraries are examples. Because I suspect you're actually more interested in the appropriate design methods for Objective C, consume the ones provided by Apple to learn how things are done and why they're done that way.
Eventually, with practice and experience, you'll begin to develop an intuition for design that captures higher level concepts such as dependencies, coupling and cohesion. Then it can be very valuable to read about some of the abstract design principles and apply them to your own code. Look at something you wrote six months ago. What do you like? What don't you like? What would you do differently?
This is essentially the act of developing any professional skill:
Execute => Critique => Distill the lesson => Apply the lesson => Repeat.
I think the most critical point is that you not get bogged down too deeply early on, learning doesn't happen when you're stuck in the middle of analysis paralysis. Instead, try something (using a good source repository, of course). If it blows up, you have a snapshot back where you started so you can apply the lessons and try again.
Ultimately, in the world of OO, I'd suggest a couple of core best practices to get you started:
Avoid circular dependencies. If you have two objects that depend on each other, you've probably done something wrong. (There are exceptions, of course, but you shouldn't be using this technique at a beginning level.)
Isolate the implementation from the contract. Maintain two separate concepts in your mind between "what" an object does and "how" it does it. I don't know Objective C, so I don't know what particular abstraction your language exposes this with. In C++ you can specify the contract with a purely virtual abstract base class. C# does so with an interface. If you are able to reason about the "what" (the contract) separately from the "how" (the implementation), you'll have an easier time creating functional, high quality software (in my experience).
I really like to think of all applications in terms of data flow. It's good to diagram out what screens will be like first, then say "what data is going to be where" which helps you group data into different possibly objects and hierarchies.
Then, when you know what data is going to be on what screens you can tie it to controls or UI elements, and figure out by what mechanism those elements are going to get data. That helps you figure out an object management layer (the "control" part of MVC) to help route and acquire data.
I find that drawing out the main models in my application in block style (preferably on something like a whiteboard) really helps. As you draw the models and work out how they relate to one another you'll start to recognise holes in your application (models you haven't thought of yet) and fill them in.
You definitely don't have to have a "complete" map of your application before you start coding but a draft really helps. Once you've got a map to work with you'll find creating the controller functions and views much easier as well (as it will be obvious what is needed where).
I'm assuming you're working in some kind of MVC framework but this will work with other styles as well.
Think about Object Responsibility.
And read the Design Patterns book to familiarize yourself with some proven abstractions.
Think of a deck of cards. Each chard has attributes. Your original deck might have red backs. You could create another deck that has all the same attributes, but instead, it has blue backs. Each card is different, but they all share characteristics.
The best way to learn most things, and most things in programming, is to use something that is an example of what you aspire to do. So, since you tagged this with iphone and objective-c, I would recommend using the Cocoa (Touch) APIs and get an understanding for how they are designed. Start with some of the huge amounts of sample code from Apple and others. Once you've used some of the frameworks, you not only know how to get some things to work, but you have gained a feel for common patterns and pitfalls. Reading books and tutorials is good too, but there is no way around the fact that it's always hard in the beginning. But fun too.