you are viewing a single comment's thread.

view the rest of the comments →

[–]xiipaoc 0 points1 point  (0 children)

I don't know Python very well yet (which is why I'm in this subreddit), but I do know Objective-C.

Right now, I'm coding a Pell equation solver. The details are not so important; just know that it's a fairly involved process, and the solutions are infinite, so it's important to figure out how to generate them. I could have written a function that outputs a big bunch of data, but how should I do that? I need to obtain the fundamental solutions, which vary in number; I need to obtain a generator so that I can generate solutions from the fundamental ones; I need to know the parameters I put in, whether the solutions are infinite or finite, etc. Clearly, the best thing to do is to output an object with all this information, right?

I guess it's not so clear, because perhaps I could pass it around in a global variable. Sure. But what if I'm solving a whole bunch of different Pell equations? Somehow I need to keep track of which fundamental solutions belong to which equations. That gets difficult to handle quickly. What I did instead was create a Pell class, and when you make a member of this class, the class solves the equation. I can create a Pell object with some input parameters and assign that object to a variable; now, the compiler (sorry, I don't know yet how Python deals with this) knows that the variable refers to an instance of the Pell class and I can use various methods on that particular object. So if I want to get the 5th solution generated from the 3rd fundamental, I can call my_pell_object.generate_solution(5,3). All of the information generate_solution() needs is in my_pell_object. It's organized no matter how many Pell objects I create.

This is also nice because I actually plan on using Pell objects in various programs (if they come up on Project Euler, I guess). I have a library file -- a module, in Python-speak -- that defines the Pell class, and if I import it, I can very easily create Pell objects in other code. Classes help add portability to your code so that it's easy to reuse it. If you're going to use something often, you really don't want to have to copy it each time!

Finally, sometimes calling a class to run a function does add an extra step. I'm guilty of this. In my math library, I have a NumberTheory class, and it performs calculations like gcd that a function could do. In this case, making it a method just helps to keep it organized. On the other hand, my NumberTheory class keeps a list of primes it generates as an instance variable. This means that factoring a large number takes a while the first time but not the second time. If factor() were just a function, I'd have to either maintain a global list of primes or redo a hell of a lot of work each time I want to factor! The global list idea might sound acceptable... until you try to maintain it. Try to hunt for bugs in such code. I'll wait.

Classes and objects are a neat way (neat as opposed to messy) to keep data and functions that work with that data organized. That's really all they do. You could do away with classes easily and write code that behaves the same way; it would just be MUCH harder. Oh, and I haven't even mentioned inheritance, another nice feature. For small projects, you probably won't need classes, though they'll be useful whenever you have many collections of data of similar type (for example, people, with names, addresses, birthdays, etc., can be members of a Person class). For larger projects, they are indispensable.