so i was just learning the basics of OOP and was wondering
when is it practical to use classes ??
what reason do people have to use them ??
(I'm a noob at this so trying to learn here )
i often see mybb using this whenever i try to code and its awesome
just trying to find out when you *need* to use them
and when you might *want* to use them as they are a good programming practice
It's difficult to say exactly when to use classes, because it varies from person to person. I use classes whenever I have a set of related functions that work on a persistent set of related data. Some people use classes for everything. Some people hate OOP with a passion to the point where they refuse to even try to comprehend using classes.
I, personally, think my definition is best. It lets the user know exactly what is supposed to work with the data they're using.
An example:
In my OS I need a way to keep track of fixed size pages of free memory, give these pages out when needed, and get them back when no longer needed. Perfect fit: a stack class, with a list of free pages, a push member function that adds a no longer needed page to the free stack, and a pop member function that removes a page to give out.
Another example:
I also needed a way to print an integer as it's ASCII representation, because for OS dev you have to do more or less everything yourself at the stage I'm at. This did not need a class because it's a one-off operation. Neither the number being converted, nor the resulting data on the screen need to be kept for the function to work properly. Creating a class for this single operation would have been overkill.
Of course, this is my opinion and YMMV.
Generally I use a class if a group of processes will be required more than once, by group of processes I mean a function that will use another function multiple times throughout it. This is really what OOP is about.
Glad I took the time to read this thread, thanks, to all, for the question and interesting answers.
While also just starting to learn OOP, here is one other tip I recently found:
(Begin with functions)
"if those functions start to get more complex I then OOP it, as it makes it easier to keep adding to it" -
source
##
Question regarding the above advice, and OOP in general:
Do functions also provide inheritance, or
is that only possible with OOP, or
usually easier with OOP, and still possible with functions?
#
// by the way:
...The inheritance concept was invented in 1967 for Simula.
If you're programming Java, anything and everything.
Yeah it depends what you are programming, in a desktop application, unless your using a RAD editor you pretty much have to use an OOP approach (unless it's a very basic command line application).
omg it took a while before i understood all the answers
i meant i started learning OOP in PHP
whooops sorry
Not reading everything, simple answer: whenever you want to.
Classes are not necessary anywhere unless the language or some set of coding standards require them.
One of the most popular languages, C, for example, has no concept of OOP.
(2009-09-18, 07:22 AM)Yumi Wrote: [ -> ]simple answer: whenever you want to.
I agree with Yumi - I have major OCD when it comes to coding, so I find it much more stress-free if everything is in a class...
If you're comfortable with the concept, and it makes it easier to remember where things are, then use them (IMO).
Zinga pretty much said what I was going to. I normally program in C++ working on games, and game related tools (where OO makes sense), and you just have to use the right thing for the right job.
If I want to encapsulate a load of information into one place with functions to work on that data, I'll use a class.
If I just want a lightweight object with public access, I'll use a struct. (To be fair, a struct is nothing more than a class that just defaults to having public instead of private access to it's members -
See Here).
If I just want a function that works on nothing but the data passed to it, I'll make that either a free-standing function (or a static member function of a class if it makes sense to).