Any interesting explanations, links, or articles so I can get a good idea?
People often say things like java is class oriented, it's not totally object oriented. I have also heard similar things in interviews. I am interested in knowing if these sort of statements are true.
By "class-oriented programming", do you mean aspect-oriented programming or maybe role-oriented programming?
Lazycoder has an article which refers to an excerpt of a podcast
I'd say you're pretty much talking about the same thing. Objects are generally considered instances of classes. OO programming could also be called class based programming. There are many resources out there for OO--this site, other sites, books, etc.
The idea is that in a static language like C# or Java, OO concepts are all bound in class hierarchies. So if you want polymorphism, you look at inheritance or a interface contract.
So if I have AdminUser and ForumUser, and I want to treat them the same way for the purposes of getting their username, I will implment a IUser interface that has a method called GetUsername();. If AdminUser and ForumUser both implement that interface, I can cast them to IUser and call GetUsername().
On dynamic languages, polymorphism is accomplished by what the object actually does. You don't care if it is AdminUser, ForumUser, or FooUser, what you care about is if the object has a GetUsername() method.
This takes alot of overhead out of polymorphism and class heirarchies, because you don't have to explicitly design these relationships in, they can occur more naturally. It is a fundamentally different way about thinking of things that requires far less decision making up front, and far less work refactoring later on if you change your mind.
If I were to do the same thing in ruby, I would do
@user.username if @user.responds_to? :username
I dont care what kind of user it is, I don't even nessicarily care if it is even a user at all. All I care about is if it has a username. If I care more about the object then I will ask it more questions, but it is the idea that those questions happen when (and where) I need to ask them, and I only have to ask as many as I want to. In a "Class Oriented" language, it is far more rigid, if you want to do something like that you have specific choices that have to be done in a specific way. Either interface or inheritance explicitly defined in their classes at compiled time, with casting as the mechanism for actually treating the objects differently.
Pobably you mean class-oriented as oposed to prototype-oriented programming, they are both object oriented, but in prototype based programming you don't have classes, you just clone objects and add methods to them.
Some prorotype based programming languajes are Self and JavaScript
Retort to posts claiming class-oriented and object-oriented are equivalent terms:
They aren't. While classes imply object-oriented programming, object-oriented programming does not imply classes. Specifically, prototype-based OO can be done without classes.
This is a potential difference in terminology, but I've never seen "class-oriented" used as a term before (and I did attempt to Google-- apparently I failed).
Class-oriented programming doesn't exist.
There are two variants of object-oriented programming, the more common is based on classes, but there are also programming languages based on prototypes where behavior is inherited directly between objects via prototyping.
Languages like C#, Java and C++ do object orientation with classes. The programmer defines a class of objects and can then instantiate instances of this class.
Another form of OO programming is prototype based. You build an object by adding behaviour on the fly and create new objects by cloning them. You can then change the behaviour of the clone even further by adding more functions. Javascript/ECMAscript use this model and if I'm not mistaken common lisp object system also is based on this.
Other dynamic languages like ruby and python even combine these models, letting the user define and instantiate classes and then change the resulting objects.
Proponents of the last two forms of OO programming often call the first form class-oriented. This is a useful distinction because the dynamics of these two forms of oo programming are quite different.
I think I have seen this question in a interview test:
Java is:
a) object oriented language
b) class oriented language
c) procedural language
d) ...
The correct answer should be obvious to anyone registered at this site.
Scott Bellware explains it in this video better than I can. Plus, it's a worthwile video for anyone who programs in static languages and is curious about ruby.
http://blog.scottbellware.com/2010/06/video-ruby-for-net-developers-from.html
I'm sure the answer to the OP quetions is well explained within.
Well I'd say it's true - that java is a class oriented (if anything) language. But it's not alone. :)
Class oriented (in my view) meaning that what you do in Java is just define classes. They contain all the methods - behavior, all the fields. Than in runtime objects just represent a state upon which you call a given method of a class. When you're calling an object method you implicitly pass in a parameter but otherwise it's just like a class/static call. In that objects are just a data structures, and all this talk that they encapsulate state and behavior is BS :P. How would you change a behavior of an object. When it's defined the limit is set - it does what it does and it does it until it dies. :) (maybe you could work around it in some clever and hairy way but that's certainly not the way the language meant it to be :) )
The term "class-oriented programming" is sometimes used to denote the lack of proper facilities in (most) languages to reason about objects. A class which is brought to life at runtime is what we call an instance. In this context, an instance does not map 1:1 with an object; and therefore, a class does not map 1:1 with an object.
Object-oriented programming is not about classes, polymorphism or type systems. Object-oriented programming is a reflection of a faculty or type of reasoning about problems; how we perceive, model and interact with the world.
Unfortunately, this is embodiment is forsaken in most languages, and is something that by necessity is pushed outside of the codespace. In some cases, this type of reasoning may not happen at all, due to the tendency to think about a problem in the terms of the language itself.
For further exploration, see this talk by Trygve Reenskaug: http://vimeo.com/8235394