Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm looking for a definition of an abstract object. I cannot find it in my textbook and I've tried googling. Abstract classes and methods I understand. Anyone know what an abstract object is?
There is no such thing as an abstract object, because an object would imply something is real, and an abstraction cannot be real. Because it is abstract.
In layman's terms, you cannot instantiate abstract classes, and an instantiated class is an object.
There are abstract classes and methods, there is no such thing as an Abstract object.
You cannot instantiate an Object from an Abstract class.
You have to make another class extend it and override all the abstract methods it has.
This is why abstract classes are used, to put some constraints on a set of classes that have to extend it.
You should look into inheritance to see why abstract methods are used.
The fact that the notion of Abstract Object is not modeled in the language doesn't necessarily mean that it makes little sense. When we use objects and messages to represent elements of a given reality or fantasy some of them will have a more concrete meaning than others. For instance, if classes are first class objects in your system (cf. Smalltalk,) these objects could be deemed abstract when compared to their instances because they do not represent the thing but the concept associated to such a thing.
For example, the class WaterMolecule would be concrete as a class, its instances -representing H2O molecules- would also be concrete (as stated in the previous answers to this question) but the class WaterMolecule itself, when considered as an object, would fit the notion of an abstract object.
We could say that a class is an abstraction of level 1. An example of abstract object of level 2 would be the class of the class, namely the metaclass. If the metaclass is represented in the language as an object, this would qualify as an abstract object of level 2. Note that you can go a step further and consider the class of these objects, which would qualify as a concrete class (its instances are metaclasses) and, at the same time, as an abstract object (of level 3.)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm reviewing the concepts of OOP, reading .
Here the book defines interface as
The set of all signatures defined by an object’s operations is called the interface to the object. (p.39)
And the abstract class as
An abstract class is one whose main purpose is to define a common interface for its subclasses. An abstract class will defer some or all of its implementation to operations defined in subclasses; hence an abstract class cannot be instantiated. The operations that an abstract class declares but doesn’t implement are called abstract operations. Classes that aren’t abstract are called concrete classes. (p.43)
And I wonder, if I define an abstract class without any internal data (variables) and concrete operations, just some abstract operations, isn't it effectively just a set of signatures? Isn't it then just an interface?
So this is my first question:
Can I say an abstract class with only abstract functions is "effectively (or theoretically)" an interface?
Then I thought, the book also says something about types and classes.
An object’s class defines how the object is implemented. The class defines the object’s internal state and the implementation of its operations. In contrast, an object’s type only refers to its interface—the set of requests to which it can respond. An object can have many types, and objects of different classes can have the same type. (p.44)
Then I remembered that some languages, like Java, does not allow multiple inheritance while it allows multiple implementation. So I guess for some languages (like Java), abstract class with only abstract operations != interfaces.
So this is my second question:
Can I say an abstract class with only abstract functions is "generally equivalent to" an interface in languages that support multiple inheritance?
My first question was like checking definitions, and the second one is about how other languages work. I mainly use Java and Kotlin so I'm not so sure about other languages that support multiple inheritance. I do not expect a general, comprehensive review on current OOP languages, but just a little hint on single language (maybe python?) will be very helpful.
No.
In Java, every class is a subclass of Object, so you can't make an abstract class with only abstract methods. It will always have the method implementations inherited from Object: hashCode(), equals(), toString(), etc.
Yes, pretty much.
In C++, for example, there is no specific interface keyword, and an interface is just a class with no implementations. There is no universal base class in C++, so you can really make a class with no implementations.
Multiple inheritance is not really the deciding feature. Java has multiple inheritance of a sort, with special classes called "interfaces" that can even have default methods.
It's really the universal base class Object that makes the difference. interface is the way you make a class that doesn't inherit from Object.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
Why are interfaces with no super interface subtypes of Object in Java?
What I am asking about here is why was this design choice taken by the language creators i.e. what is the practical purpose of this subtyping?
what is the practical purpose of this subtyping?
The practical purpose is that you can call Object methods using a variable whose type is an interface, most commonly toString(), equals(), and hashCode().
In order for a variable of an interface type to have a non-null value, an object instance must be assigned to it. Since all objects extends Object, it's guaranteed that any object implementing the interface also extends Object.
E.g. List is an interface, but you can call myList.toString() even though toString() is not defined for that interface.
Interfaces are just a "specification" for their subclasses. They usually don't provide any implementeation. So essentially an interface is the most abstract way an object can be seen in Java. However, Java 8 and above provide default and static methods with implementation so this makes interfaces even more similar to abstract classes.
Since every object inherits from Object class, and since interfaces are just an abstract representation of an object, they too need to inherit from an Object.
Note that every class, abstract class and interface that does not explicitly specify their super class, gets assigned Object class as their direct super class at compile time.
This is because Object class already provides some methods that all objects need to implement (e.g. equals(), toString(),...). Especially usefuly methods are hashCode() which is used in various hashtables, or wait(), notify() and notifyAll() which are used when writing multithreaded programs. Because of inheritance you will almost never need to call these methods explicitly, however, if classes did not inherit from Object you would need to write all of these by yourself for every class. Object class therefore reduces programming effort to some extent.
Additionally, this also enables making an argument of type "any", when the value is unknown.
void printObject(Object any) {
System.out.println("Printing object of type: " + any.getClass().getName());
System.out.println(any); // toString called "implicitly"
}
Do try to avoid this kind of code if possible.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
We know that all classes have at least one class as it's superclass i.e. Object class. My question is if Object is a class and we already have a class named Class, but if Object itself is a class why not name it Class and name the original Class class as something else?
What was the reason for choosing this name as it is not an actual object but a class and it is really important to get your nomenclature in place for any programming language, is it to satisfy some kind of Object Oriented relationship such as an Object HAS A Class ?
Instances of the Class class represent the meta information of classes. For example the fields declared in a class or the available methods. This information can for example be used with the reflection API to dynamically access functionality during runtime.
Object defines common functionality shared by all instances of each and every class (including instances of Class). This functionality is extended/modified by deriving from Object or any other class.
Regrading the naming from an OO perspective it seems quite natural to name the root class of everything Object. Naturally one would say trees are objects, and cars are objects. But not trees are classes.
Physically, classes represent Java class definitions.
All compiled Java classes are indeed defined in classes (.class files).
So Class would be a very ambiguous name to also represent the Object class.
To answer to you comment : so why Object as class name ?
Object-oriented programming (OOP) refers to a programming object paradigm where we manipulate objects.
In the class-based programming (the OOP style which Java belongs), class names should represent concepts/things.
So, Object appears as very suitable to name the base class as it refers to a really broad concept/thing.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
So someone tell me if i'm correct or not.
Encapsulation is Data hiding, allowing yourself only to view the
attributes and othering methods in a class privately, while you could you use these methods and abbritures in other classes,
Inheritance is extending a class, like taking some of the methods in the “super class” and pass it in “child class” and modify it or use it there.
Polymorphism is the same thing as inheritance but it's just formatted differently, like if i had an animal class, every animal has a different sound so, from there I would have something like this
Animal cat = new Cat();
overriding & overloading I’m not sure about this one
Abstract classes is taking methods or variables from the super class and pass those methods and variables as “Abstract” so that in the sub class you modify them and edit them.
Does that make sense? Or I misunderstood something?
These things all work together.
An object is something that is self-sufficient, it keeps track of its own state. Encapsulation enforces that separation, the object publishes methods that other objects call, but those methods are responsible for modifying the object's state.
In oo systems that use classes the class is a template for creating objects. Subclassing means creating a new class that is a more specific version of the subclassed class, where subclassed objects inherit the class definitions that specify the methods and fields of the superclasses.
Abstract classes defer some method implementations, leaving them to the subclasses to implement. If the superclass knows something has to happen at some particular point but wants to leave exactly what happens to the discretion of the specific objects, that's what abstract methods are for.
There's a pattern emerging here: objects taking responsibility for themselves, and a hierarchy of types from most abstract/general to most concrete/specific. Polymorphism is about objects' behavior being determined at the time the program runs based on what methods are overridden. Overriding means the subtype has a more specific version of a method that is substituted for the superclass version.
(Overloading otoh is a convenience for allowing a class to have methods with the same name but different parameters.)
The result of this can be a system that at a high level deals with abstract types and lets the objects themselves work out the exact details. The idea is that that way the details can be confined to the subclasses and the program can be modified by creating new subclasses without disrupting the rest of the program. In theory anyway, see Wadler's Expression Problem for where this all goes to hell.
And for examples: read the source that comes with the Jdk. The packages java.lang and java.util have a lot of classes that are examples of OO design.
This is my question
What is the use of a Abstract class even though we cant instantiate a abstract class?
is there a indirect way of creating instances of an Abstract class?
Basically, an abstract class is a class that is not fully implemented. If you know that you will have several subclasses of a class, but that you will never declare objects of the class itself, you should consider making the class abstract. Say, for instance, that you have an array of items, and you want them to all act fairly similarly except in certain circumstances. You could make an abstract superclass, and have all these items be members of subclasses of it. Then have the method whose behaviors differ among the different items be abstract in the superclass - but implement them in the subclass. This way, you can put them all in one array (etc) but they will all respond differently to certain method calls.
Did you understand what is an interface in java ? It is in fact, a programming agreement between the architect, developers. That will not contain any method definitions but their signatures. Since architects need to assure to other world creatures who use this code that this works in all of their scenarios. The same way, if some code is so much standard, and an architect cum developer wishes to use it for a de-facto method, he may include that too in an interface. But this distinction made another introduction to java and that is called as Abstract Class concept.
Abstract classes have importance in relation to runtime polymorphism.