Classes
Pages: 12
Today in my lecture we went over classes for the first time. All I could think to myself was " What is the benefit? " I felt that we did so much work for just a little bit of code. Literally we had 3 lines of output on our screen. So, I decided to make this post to see the positive side of classes. What is the big deal about classes? Maybe it was because it was the first lecture on this subject. I'm not sure. Are classes more work?
im guessing you havent written in c because you seem to take the string class for granted... yes that would be because its the first lecture but your also in a class your not trying to build a product. they are teaching skills that can be used to make products. think of hello world. its probably the most written program and (in terms of c, c++, java, obj-c, and especially assembly) it probably has the largest ratio of work to non-usefullness. its not going to make you any money, just teach you about the language. and yes classes can be more work. classes, if used very shallowly, can be easy and simple and solve minor problems. however if you want to go deep into oop, classes can do so much more like polymorphism, operator overloading, making your own types, virtualiation, etc etc
http://www.geocities.com/tablizer/oopbad.htm
http://harmful.cat-v.org/software/OO_programming/
OOP is about putting together data and functions.
The benefit is that... umm... abstraction... something... polymorphism...
The drawback is: takes long to learn the style, takes long to design the classes (and the relationships between them)... and if you get the design wrong, or need to significantly change it, you'll waste even more time trying to reuse your code, until you finally decide to rewrite it -- which means redesigning it.
I could be wrong though.
http://harmful.cat-v.org/software/OO_programming/
OOP is about putting together data and functions.
The benefit is that... umm... abstraction... something... polymorphism...
The drawback is: takes long to learn the style, takes long to design the classes (and the relationships between them)... and if you get the design wrong, or need to significantly change it, you'll waste even more time trying to reuse your code, until you finally decide to rewrite it -- which means redesigning it.
I could be wrong though.
OOP is about bringing code closer to design. Classes are like small modules.
There really is nothing that can be done with classes, that couldn't be done without them (Including polymorphism, maybe not so elegantly. Not sure about RAII, I think that might take revised language design...). You may at first be compelled by this and consider OOP a waste of time, but at some point you'll start working with nontrivial projects and you will see what is good for you.
There really is nothing that can be done with classes, that couldn't be done without them (Including polymorphism, maybe not so elegantly. Not sure about RAII, I think that might take revised language design...). You may at first be compelled by this and consider OOP a waste of time, but at some point you'll start working with nontrivial projects and you will see what is good for you.
Programming is about solving problems. Solving the problem begins with thinking about it effectively.
Some problems are easy to think about if you think about some aspect of them as distinct things. Once you've thought about the problem and have an idea of what you're going to program, it would be nice if you could continue to use your mental model of "distinct things" as you program. This will make it easier for you to think about what you're doing.
C++ provides some "distinct things" for you to start with. int. double. float. char. string. Classes enable you to build new kinds of "distinct things", and to dictate how they work.
You are likely to have thought of more complicated "distinct things". For example, if you wanted to model the flight of a flock of birds according to some simple rules, you might have thought of each bird as a "distinct thing". If you could program with lots of actual bird objects, you would find it much easier to put the solution in your head into code. You might have come up with a different solution in which you did not consider each bird to be a "distinct thing", so that solution would not be such a good fit for using classes.
Classes allow you to create new kinds of object (where the old ones are things such as int, double, float etc.), of which you can then create as many as you like (just like you can create lots of different int variables).
Use them when it helps you think about the problem and when it helps you organise your code. Don't use them when they don't help. They're not magic; they're another tool to help you think about the problem effectively, and to help you cast the solution in your head into code.
Some problems are easy to think about if you think about some aspect of them as distinct things. Once you've thought about the problem and have an idea of what you're going to program, it would be nice if you could continue to use your mental model of "distinct things" as you program. This will make it easier for you to think about what you're doing.
C++ provides some "distinct things" for you to start with. int. double. float. char. string. Classes enable you to build new kinds of "distinct things", and to dictate how they work.
You are likely to have thought of more complicated "distinct things". For example, if you wanted to model the flight of a flock of birds according to some simple rules, you might have thought of each bird as a "distinct thing". If you could program with lots of actual bird objects, you would find it much easier to put the solution in your head into code. You might have come up with a different solution in which you did not consider each bird to be a "distinct thing", so that solution would not be such a good fit for using classes.
Classes allow you to create new kinds of object (where the old ones are things such as int, double, float etc.), of which you can then create as many as you like (just like you can create lots of different int variables).
Use them when it helps you think about the problem and when it helps you organise your code. Don't use them when they don't help. They're not magic; they're another tool to help you think about the problem effectively, and to help you cast the solution in your head into code.
Last edited on
@Moschops, I hate to nag, but your answer lacks distinction between C struct and C++/Java class.
It does indeed not talk about how classes are implemented in various languages. As far as I am concerned the important point of classes is covered in my answer. To my mind, the degree to which different programming languages make this easier by providing various facilities in the language is not the point of classes themselves.
Some people take a different approach and like to talk about classes in terms of their implementation in the language rather than what they're for; that's up to them. We can all only provide an opinion.
Some people take a different approach and like to talk about classes in terms of their implementation in the language rather than what they're for; that's up to them. We can all only provide an opinion.
So, When I think about structures I feel like those are a better solution then classes. We learned that there is only one difference between structures and classes although I cannot remember if off the top of my head.
Why not just use structures?
Why not just use structures?
In C, a structure is a different beast, in that they do not have their own functions (i.e. class functions, or class methods) and you cannot do various funky things like inheritance with them.
In C++, a class and a struct are identical but for default privacy level, so if you would rather say struct than class in your code, go ahead.
Well that makes no sense. In C++, they're identical but for default privacy. They're very nearly the exact same thing, so saying one is better makes no sense.
Don't get confused between the concept of a class, which is a distinct kind of thing you can create as many of as you like to help you think and organise your code, and the syntax and particular features of a class in C++.
In other languages, how you go about making classes and what they can do differs; your question was "what are classes for?" which has the same answer across all programming languages; each programming language will provide different ways and features for you to actually create classes, with some of them providing more funky features than others.
In C++, a class and a struct are identical but for default privacy level, so if you would rather say struct than class in your code, go ahead.
| When I think about structures I feel like those are a better solution then classes. |
Well that makes no sense. In C++, they're identical but for default privacy. They're very nearly the exact same thing, so saying one is better makes no sense.
Don't get confused between the concept of a class, which is a distinct kind of thing you can create as many of as you like to help you think and organise your code, and the syntax and particular features of a class in C++.
In other languages, how you go about making classes and what they can do differs; your question was "what are classes for?" which has the same answer across all programming languages; each programming language will provide different ways and features for you to actually create classes, with some of them providing more funky features than others.
Last edited on
@Moschops, Definitions of paradigms are a bit loose and you are free to call things what you like, but if you call C OOP, I'd like to know what you don't consider OOP. Apart from asm and brainfuck.
Last edited on
To my mind, languages aren't OOP. How you use them is (or is not) OOP.
Some languages make OOP a lot easier than others, some languages make it almost impossible, some languages pretty much give you no choice but to code in an OOP way.
Some languages make OOP a lot easier than others, some languages make it almost impossible, some languages pretty much give you no choice but to code in an OOP way.
Well that makes no sense. Yes it does :) When I learned structures it was less work then learning classes now. So I think they are better.
| When I learned structures it was less work then learning classes now. |
When you learned structures, was that a C++ lesson? In C++, a struct and a class are identical but for default privacy. If you found struct easy but class hard (even though you'd already learned it, except you were calling it struct) then something went very wrong.
If I had to guess, whoever taught you struct pretended they teaching C instead of C++ that day.
It is common amongst C++ programmers to use struct when they just want an object with data and no functions (i.e. use it as if it were a C struct), but it's just a habit. In C++, struct and class are identical but for default privacy.
Last edited on
| No c++, in classes we had 3 screens open....structures we had one. |
The world is deceptive sometimes. You cannot measure complexity by how many screens someone has chosen to use whilst talking about it :)
| The drawback is: takes long to learn the style, takes long to design the classes (and the relationships between them)... and if you get the design wrong, or need to significantly change it, you'll waste even more time trying to reuse your code, until you finally decide to rewrite it -- which means redesigning it. |
I disagree with just about all of this. I'd say it's easier to learn and design as you can model problems as you would in your mind. Code that is written well the first time can be easily modified without having to change the whole implementation. Much easier than without OOP. And good OO code can be reused with no problem as well. I take general purpose classes out of old programs and all the time and pretty much copy paste them into a new program.
To the original poster >
If you are planning a career as a programmer (or want to be very good at it), even if you NEVER use classes yourself, you need to understand them in order to read other people's code because they will use them.
If you aren't seriously interested in programming or planning to persue it professionally, then it's only important enough to get you sucessfully through your course.
It's really that simple.
If you are planning a career as a programmer (or want to be very good at it), even if you NEVER use classes yourself, you need to understand them in order to read other people's code because they will use them.
If you aren't seriously interested in programming or planning to persue it professionally, then it's only important enough to get you sucessfully through your course.
It's really that simple.
Last edited on
It is all about encapsulating state so it is not global anymore. State is encapsulated in objects. Objects are pretty intuitive to understand. Classes are for compile-time correctness verification that you request from objects only the services that are supported by them.
IMHO programming with classes is much more programmer-friendly because the tools can understand more about your programs. Contrary in e.g. JavaScript you don't have all those goodies like e.g. code completion.
The same can be said about functions. That doesn't convince me to classes in any way.
IMHO programming with classes is much more programmer-friendly because the tools can understand more about your programs. Contrary in e.g. JavaScript you don't have all those goodies like e.g. code completion.
I take general purpose classes out of old programs and all the time and pretty much copy paste them into a new program. |
The same can be said about functions. That doesn't convince me to classes in any way.
Last edited on
Imagine that there were no languages and you had to write everything in machine code. Would you and everyone like you spend time and effort to create a language that made the task far easier so that you could do more in your lifetime? Or would you just keep writing machine code for the rest of your life?
Classes don't make sense when you use them for trivial things, like the example you describe. They make perfect sense when you're trying to make an entire game engine, however. Obviously a quick hand-drawn sketch of something isn't as good as the real thing, but it gives you the basic idea of what the real thing is like.
Classes don't make sense when you use them for trivial things, like the example you describe. They make perfect sense when you're trying to make an entire game engine, however. Obviously a quick hand-drawn sketch of something isn't as good as the real thing, but it gives you the basic idea of what the real thing is like.
Last edited on
of course classes can be done without. the point of an abstracted language or an abstracted feature in a language is to make things easier.
Pages: 12