How to learn to translate real world problems to code?

Question

I'm kind of a beginner to Java and OOP and I didn't quite get the whole concept of seeing a real world problem and translating it to classes and code.

For example, I was reading a book on UML and at the beginning the author takes the example of a tic tac toe game and says: "In this example, it's natural to see three classes: Board, Player and Position." Then, he creates the methods in each class and explains how they relate. What I can't understand is how he thought all this.

So, where should I start to learn how to see a real world problem and then "translate" it into code?

Answer 1

When considering your problem think of the "things" that the problem involves - these are usually real objects, like cars or users. These become your classes.

Then consider actions and what the actions is performed on, so a car might StartEngine, and a user might Login. These are methods.

Finally (ish) you have information about your objects, eg a car has 4 wheels, a user has a name. These are properties.

Its a bit simplistic but its a start point.

Answer 2

Necessity is the mother of invention. You may need to get your hands on an actual problem to solve before you can expand your ability to split it into seperable units.

Decide on some project of moderate size, and try to program it. Focus on the "nouns" and "verbs" of the problem and try to base the code structure around them.

Answer 3

You should read this book: Head First Design Patterns

It gives you briliant examples of transfoming real world objects to classes.

Answer 4

Although I started in OOP, I often find that my thoughts on a new problem drift closer to one of two much more basic methodologies.

1) What are the data and structures that I'd need?

This is identical to the OOP "what objects do I need" but more basic, easier to understand. Say I have the requirement "Read an address book file, send an email to all the email addresses in it." I know I'll need to keep a collection of address records as I read them from the file, so I know I'll need a collection. Usually a List or Array is a good start. If I need "named access" I'll use a dictionary/map. More specific data structures fill particular roles that you'll learn as you go (queues, dequeues, stacks, sets, etc.)

I'll also need address records, so I figure out what I need to track: name, email address, phone number, etc. That's my basic objects right there.

2) What inputs and outputs am I dealing with? What methods would bridge those?

A computer is nothing but input and output. A program inputs and outputs. A method inputs and outputs. If you break your problem down step by step into what goes in and what comes out, you'll often begin to see a solution. I have a List of Addresses (input) and I need emails (output). (Okay technically emailing is probably a side-effect, for all you Functional Programming purists, but we'll say its one of many potential outputs.)

I look in my language documentation for how to email things. I write methods that use those library methods. I need a place to put those methods, so I make a new class and call it "SpamBot3000". I need a way to manage my spam bots so I make another class called "SpamBotManger" and so on. Once you've defined the base problem and started on it, the rest of the classes will usually manifest themselves as necessities.

As a final example, your Tic-Tac-Toe player. My first thought would have been, "I need a board. I can probably use an array of chars for that, holding 'x' 'o' or ' ' as needed." Then I'd put that array in a class, Board. Then I'd add simple methods like "SetSpaceToChar(char c)". Then I'd go "Right, I need a 'Player' class to actually handle whose turn it is and which letter to put. Maybe a 'Game' class to keep score." Then later on I'd think, "You know, letting people put any char into the grid is dangerous. I should switch from char to a specialized type, 'Space' that can only be x o or blank."

In that light, as tiny steps that build on each other, maybe the class structure makes a bit more sense.

Answer 5

It's also about evolution. Don't be afraid to take a stab at something and then tear it apart when you find it just doesn't feel right. Nobody gets it right the first time.

I remember a project when I was getting started trying to get my head around OOP. I think I had classes that represented customers, dealers, products, etc. I needed to represent these as XML at some point so I added code to each class to do that. Then I realized that 'xml-ness' had nothing to do with 'customer-ness' and pulled it out. That's called refactoring and you'll do that over and over until you find a solution that is more natural.

Read, study this site (LOTS of skill here) and write programs.

It's fun!

Answer 6

In short, translating the real world problem to code is probably the hardest part of a programmers job. The code serves as a representation of that problem and how effective the solution is, in terms of correctness, efficiency and extensibility, is a function of how well that translation is made, i.e., how well you understand that problem.

For any real world example, there are going to be lots of a class/code representations that are going to be 'natural'. It's a process of experience and experimentation to find the one that works for a particular problem - often the right designs aren't the ones that are natural and intuitive, but the ones that can be reused and extended in a sane fashion. A Visitor pattern, for example, is not something you'd find represented in your problem, but something you would impose upon it to make your solution better.

For this particular example I think your book's example is poor. On my initial reading and still, I don't know what these map to. I think my first intuitive approach would be to represent a player, the game (containing whose move it is, the whether it's complete or not) and the board itself. You could also represent the board within the player objects by keeping track of where they placed their tokens. There are endless permutations of this,even for this simple problem. There's also no right answer without knowing how the tic-tac-toe will be used, where it's running, etc. etc. (Though there are always wrong answers :) )

Learning this isn't something we can tell you how to do here. Despite the fact that you're writing code, doing this sort of translation is a bit of art - go out, see what works, try to copy it, change it a little bit, watch it fail, learn why it failed, think of ways to fix it, ask questions and break it as many ways as possible.

Answer 7

Right now what you pick as classes doesn't matter too much. I'd just start coding. Figuring out all your objects up-front doesn't work well, you can get an idea but the entire school of thought called "Agile" has built up around the concept that you won't get it right anyway, so don't stress it, just code.

You can take some steps to make your code better as you go:

When you notice that you are passing the same 2 or 3 pieces of data around to a few methods, look at them, they have something in common. Consider what that data "Means" and make an object to represent it and encapsulate that data.

If you notice that a method doesn't access any members in your object, it's probably not in the right place. Also if a method takes an object as a parameter and uses it a LOT, it should probably be a method of that object (and not take the parameter)

I've almost never seen an object that's too small/you can (almost) never have too many objects--so break objects into new objects a lot. I suppose if two objects live and die together and are always passed to the same third object you might consider combining them.

Don't use inheritance unless it really makes sense--consider it a last resort and always prefer having one object contain another instead.

Just iterate over these steps (and check the book "Refactoring" for more) and your code will turn out okay.

Once you get in the habit of how good OO code is written by writing it, you'll find it's easier to answer a question like the one you posed.

Answer 8

Not all problems have to be solved in an OOP fashion.

Real world programs are mash up of different styles.

You will generally find that code goes through a few states:

(1) You start with a clean solution (possibly). (2) It goes live and bugs are found. (3) Bugs are fixed, code becomes more stable. (4) New features are added, the "clean-ness" starts to drop. (5) After many cycles, the initial clean structure becomes a complex mess. (6) Sometimes refactoring occurs. (7) Code is either re-written OR slowly slimed down and cleaned up.

During the clean up OOP may be used to achieve good code - reuse.

Answer 9

Good question.

First, you think of objects from the real world problem. In the tic-tac-toe game, Player, Position, and Board come to mind.

In an XML Parser, you'd have a Decode class. Decode is more like a process than a real world object, but it's obvious that in an XML Parser, you'd have to decode the XML.

Then, you come up with what you want the classes to do. These would be the methods.

In most real world problems, you're not going to identify all of the classes and methods right away. That's okay. You identify and code them as you think of them.

Answer 10

For school problems, the problems are usually simple as the professor usually will provide detailed requirements and they already know the solution.

For actual consulting jobs, things get hairy as the customers tend to not know how to articulate the solution (if they did they won't really need consultants). Let's presume it is a consulting job you are asking for and not a school problem.

For the most part most business problems I have experienced can be broken down into OO methodology as the main container. This is because it is easier to communicate with non technical people in those terms.

First steps are usually to get good requirements. From those you can start breaking things apart into use cases. A typical use case diagram will show interaction between a user and a system, and sometimes system to system. The interaction will show "actions" that would be performed and a direction. In simple OO concepts, you now have broken down your problem into objects that interact with each other. You have also done one of the paradigms which is encapsulation.

From there you continue to break things apart into smaller objects that talk to each other. At this point no code has been written yet. Right now you are on designing still. However as you go through it and refine things you get to start seeing how things would be assembled and you can start building in those stages. However, don't start building yet.

At this point comes experience and understanding design patterns and other modelling techniques. You want to start grouping things together or breaking things apart or moving things around until you are comfortable you are not repeating yourself too much or making things wired so it becomes like spaghetti. Don't over analyze though, just allocate maybe 2 to 4 hours, it is usually enough for most applications where a framework has been defined for you, 4-8 if you're building a framework. The reason I say this is because I am lucky enough to use IDEs that support refactoring so I can change my mind and move stuff around as needed.

Add a few tests to prove your thing works. You don't need to test everything, but try to get good enough coverage. The test cases will allow you to refactor more fearlessly because you have something to double check that whatever you did, didn't break any existing expectations.

There you go you now have translated business requirements into an object model which you have mechanically translated to code for the most part.

You can stop here if you want, or you can always go back and say, there has to be a better way of doing X and adjust accordingly. Just don't go past your limit.

Just a reminder again, OO decomposition is not applicable to all cases especially when it comes to dealing with business users. I do rule decomposition (sort of a cross between functional and declarative programming) and workflow decomposition. However, OO decomposition is the easiest to understand (not necessarily to do it).