I'm studying Common Lisp (with Lispworks) and I'm trying to get into class system right now. There is a class called standard-object and it is defined as
The class standard-object is an instance of standard-class and is a superclass of every class that is an instance of standard-class except itself.
(taken from http://www.lispworks.com/documentation/HyperSpec/Body/t_std_ob.htm#standard-object)
so it is an instance of standard-class
On the other hand standard-class is a subclass of standard-object
>(subtypep 'standard-class 'standard-object)
=>T, T
How can the standard-object be a superclass for the standard-class and be its instance at the same time? If we define standard-class as a subtype, we should define it after defenition of its supertype (e.g. standard-object), so how can it be, that the superclass becomes the instance? Or my logic is just wrong?
CLOS is an object system, where CLOS concepts itself are first-class objects. Classes themselves are instances - of a meta class. There is some circularity involved.
There is an instance standard-object. It's an instance of standard-class. It is a class itself. All standard CLOS objects will have it as a superclass. There are other types of objects, for example structures. So standard-object is there as a superclass for all typical CLOS objects.
standard-class is in instance of itself. It is the class of all class objects. Since standard-object is also a class, the instance for the class standard-object is an instance of the class standard-class. Since all standard classes are also CLOS objects, standard-class inherits from standard-object.
CL-USER 22 > (class-of (find-class 'standard-object))
#<STANDARD-CLASS STANDARD-CLASS 40F016A063>
The class of the standard-object class object is standard-class.
CL-USER 23 > (class-of (find-class 'standard-class))
#<STANDARD-CLASS STANDARD-CLASS 40F016A063>
The class of the standard-class class object is standard-class.
CL-USER 24 > (find-class 'standard-object)
#<STANDARD-CLASS STANDARD-OBJECT 40F017732B>
The class standard-object is itself an object and a class. It is a superclass of all CLOS objects.
CL-USER 25 > (find-class 'standard-class)
#<STANDARD-CLASS STANDARD-CLASS 40F016A063>
The class standard-class is itself an object and a class. It is a superclass of all CLOS classes.
To understand this you will need to understand the concept of meta class. The instance of a meta class is a class and the instance of a class is an object, so basically we have 3 level hierarchy.
standard-class is a meta-class. standard-object is an instance of metaclass standard-class hence it is class. Every other user defined class by default inherits from standard-object class.
So when you are creating a class, you are basically instantiating standard-class metaclass and this new class is inherited by standard-object class.
I will try to give an answer to only one question that seem to be confusing you:
How can the standard-object be a superclass for the standard-class and be its
instance at the same time?
I hope you are familiar with the concept of relations from mathematics. Relations that are defined on a set with an operation. Examples of relation would include "is divisible by", "is a", "is equal to" etc. So, "is instance of" is a relation, "is a subclass of" is a relation too. They are by no means the same! A sub-class must be a class, an instance may be a class, but commonly it's something else. If you take an example from the nature: primates are a subclass of mammals - this is the "is a subclass of" relation. Lassie (a dog from a movie) is a mammal - this is an example of "is instance of" relation.
Now, what was probably confusing you is that the function of something, which is "an instance of" something else is to be that something's class. This, indeed doesn't happen much in nature, but here's something I could think of:
Language and grammar. Grammar is a set of rules, which define a language, grammar is, itself a language too (i.e. it "is a subclass of" language), while a language instantiates grammar rules, so a language "is an instance of" grammar.
Related
I have read how companion and singleton objects can be used to keep static methods, which makes sense. My question is how is this object made or instantiated it? I have read from some sources on how Objects are instances of the class if used as companion objects while others say they are not instances of the class. Then how are the objects existing or being made? Plus the Object would be same class data type I suppose?
My question is how is this object made or instantiated it?
[…]
Then how are the objects existing or being made?
You don't know, shouldn't know, and can't know.
The Scala Language Specification says that they exist. The Scala Language Specification does not say how they are instantiated. Every implementor is free to implement them however they want.
For example, ECMAScript has object literals, so for Scala.js, there is no need for them to be an instance of any class at all. Scala-native is not dependent on any platform, so it can do whatever it wants. Scala-JVM needs to comply with the restrictions of the JVM, where every object needs to be an instance of a class. In Scala-JVM, every singleton object Foo is an instance of a JVM class named Foo$.
Plus the Object would be same class data type I suppose?
The type of a singleton object Foo is the singleton type Foo.type. It's not a class.
I have read from some sources on how Objects are instances of the class if used as companion objects while others say they are not instances of the class.
Instead of reading "some sources", it's much better to just read the source: the Scala Language Specification, specifically section 5.3.2 Case Classes:
A case class definition of 𝑐[tps](ps1)…(ps𝑛) with type parameters tps and value parameters ps implies the definition of a companion object, which serves as an extractor object. It has the following shape:
object 𝑐 {
def apply[tps](ps1)…(ps𝑛): 𝑐[tps] = new 𝑐[Ts](xs1)…(xs𝑛)
def unapply[tps](𝑥: 𝑐[tps]) =
if (x eq null) scala.None
else scala.Some(𝑥.xs11,…,𝑥.xs1𝑘)
}
Each object has its own class, but you can't access the class directly. This class has a constructor without parameters which is called automatically when it's loaded and creates the only instance.
Objects are instances of the class if used as companion objects
Either you misunderstood or you really shouldn't trust these sources. It's possible for a companion object to extend the trait/class it's companion to, but not at all common.
Companion objects are not instances of the class they're companion of, think of them more like a collection of utility methods. If you're familiar with Java - all the method, that you made static in Java (hence they don't belong to a particular instance, but to class in general) would go to Companion object in Scala. Also, companion objects have access to classes private values.
Objects are lazily initialized for you, you don't need to know when and how exactly are they created, just if you call a function from an object - it will be created for you, and there will be only one instance of it.
We are having a UML course. The teacher said:
Every class should be declared as abstract if it serves as base class for
its derived classes.
In the following figure suppose that we want to derive class german shepherd and class labrador from class chien (Dog woof woof). Is it an obligation for class chien to become an abstract class or not?
Not necessarily.
That statement isn't necessarily true. A more correct statement would be:
Every class should be declared as abstract if it cannot be instantiated without referring to a concrete derived class.
In your example, it makes sense that Dog and Animal would be abstract, because you have more specific classes that likely fill out details that the base classes do not.
However, it is certainly possible to have a class which is concrete and can be instantiated, (and therefore not abstract), but still serve as the base for another class.
It should be abstract if it's a generalization and cannot exist on it's own.
Look at this situation:
In the image above Relation is abstract. It can't exist by it's own. Customer and Employee are normal classes who extend Relation. But Trainee is a Employee.
You could create a Employee, but also a trainee which is a Employee as well.
i have learned class is a blueprint of structurally identical items, and the items created using class are called instances.
please let me know what are the difference between class, object, instance and attribute in object oriented programming concept. is the object, instance, attribute same?
http://en.wikipedia.org/wiki/Class_(computer_programming)
Typically they are used like so:
class - blueprint for creating object instances; defines properties and methods
object - synonymous with instance usually (sometimes improperly equated with class)
instance - an actual manifestation of a class; the class defines what properties and methods the instance has while the instance holds the values of the object attributes
attribute - typically synonymous with "property" (an object member whose value can be set), but in some dynamic languages this can also include "methods" (an object member which can be called)
Yes, you're definition of a class is correct. You can create multiple objects of the same class. Each object is an instance of the class. The term instance can not only mean the object is an instance of the class, but it can also relate to polymorphism. There is a keyword, in java it is called instanceof. With it, you can not only tell if an object is an instance of the class, but if the object is an instance of a superclass. So, instance, can also be more type-oriented. Attributes are members of the class, like its variables.
The following code using UIGestureRecognizer:
UIGestureRecognizer *gestureRecog = [[UIGestureRecognizer alloc]
initWithTarget:self
action:#selector(handletap:)];
[self.view addGestureRecognizer:gestureRecog];
can actually compile and run. I thought abstract class cannot be instantiated?
Abstract classes are not a language feature in Objective-C (unlike Java, for example), so it isn't something the compiler could enforce.
When a class is marked as abstract in the documentation, it is just a hint how it is intended to be used, but neither the runtime, nor the compiler will actually prevent you from instantiating it directly.
The section on abstract classes in the Objective-C Programming Language Guide actually states that NSView is an example of an abstract class that you may sometimes use without subclassing, so the concept as such is not as strict as in other languages/frameworks.
Thanks for omz's answer. This is the related excerpt from Apple's documentation:
Abstract Classes
Some classes are designed only or primarily so that other classes can
inherit from them. These abstract classes group methods and instance
variables that can be used by a number of subclasses into a common
definition. The abstract class is typically incomplete by itself, but
contains useful code that reduces the implementation burden of its
subclasses. (Because abstract classes must have subclasses to be
useful, they’re sometimes also called abstract superclasses.)
Unlike some other languages, Objective-C does not have syntax to mark
classes as abstract, nor does it prevent you from creating an instance
of an abstract class.
The NSObject class is the canonical example of an abstract class in
Cocoa. You never use instances of the NSObject class in an
application—it wouldn’t be good for anything; it would be a generic
object with the ability to do nothing in particular.
The NSView class, on the other hand, provides an example of an
abstract class, instances of which you might occasionally use
directly.
Abstract classes often contain code that helps define the structure of
an application. When you create subclasses of these classes, instances
of your new classes fit effortlessly into the application structure
and work automatically with other objects.
I have a clue about Object Oriented Programming:
I need to have a parent class HandlerException which needs to define the sign of three methods (MethodA, MethodB, MethodC).
Then, I have a child class BusinessHandler which inherits from HandlerException and defines ONLY the MethodA of its parent class.
Then, I have a child class DataHandler which inherits from HandlerException and defines ONLY MethodC of its parent class.
Then, I have a class named CustomerDAO which inherits from DataHandler and consumes the MethodC written on its parent class. (consumes it like: DataHandler.MethodC).
As you can see, its a typical object oriented programming problem; I need to have some static methods (MethodC) to access it directly without any instance of the class. The parent class HandlerException could be abstract? and its 3 methods (A, B and C) could be ???? (that's my question, how is the RIGHT way to write this parent class: abstract with abstract members, or virtual, or maybe an interface?)
I hope you got the idea of my question and that I made myself clear. Thanks in advance.
I forgot: I'm using C#, and to mention: MethodB would be implemented on the next release of the app.
Depends on the language you are using, but it sounds like the HandlerException class would be abstract and all three methods would be virtual.
If the HandlerException class has absolutely no implementation whatsoever (only defines those three methods) then it would probably make sense to make it an interface rather than an abstract class.
Also, where is MethodB implemented? If it isn't implemented by any of those classes, then all the classes would need to be abstract.