I am a bit confused. I was reading a book about Django, and I came across a parent class that is calling itself using super() method. I am used to subclasses calling parent class using super(), but not a parent class calling itself, especially using super method. see the code below:
class OwnerMixin(object):
def get_queryset(self):
qs = super(OwnerMixin, self).get_queryset()
return qs.filter(owner=self.request.user)
Related
sealed class DestinationScreen(val route:String){
object Signup: DestinationScreen(route = "signup")
}
Now I am developing navigation screen above.
I don't understand this statement.
object Signup: DestinationScreen(route = "signup")
I think Signup is property. So to set it, should we write this below?
object Signup = DestinationScreen(route = "signup")
Why does not using = issue the instance and set the Signup property?
Please teach me. Thank you.
Nope. Signup is not a property. It's basically a class which extends DestinationScreen except it's a special class object which acts as a singleton and is initiated at the same point it's described. That's why you write it like that.
Why it looks like a property to you is you happen to declare it in another class (which makes it an inner class). But you can declare it outside of the class too.
More about Kotlin objects https://kotlinlang.org/docs/object-declarations.html
Sealed classes represent a class with a fixed number of subclasses. At first, you declare the parent class, for example, a class that describes Screen of your app. Then, you declare all children of this class. For example, HomeScreen and LoginScreen:
sealed class Screen
class HomeScreen : Screen()
class LoginScreen : Screen()
All subclasses can be written outside of the parent class (but must be located in the same file due to compiler limitations).
You can use the object keyword instead of class modifier in case of a class has no properties. It means that the object keyword declares a singleton class.
Because you are using inheritance, not an assigment.
A sealed class is a class which subtypes are known by the compiler so it allows you to create flow controls by type:
sealed class Result {
data class Success(val data...): Result()
data class Error(val exception...): Result()
}
So you can do:
when(val result = ...) {
is Success -> result.data
is Error -> result.error
}
Whith normal inheritance like on interfaces, open classes or abstract classes you dont know the typed thar inherit from the super type.
I'm wondering which of the following two methods would be more efficient, or if it doesn't actually matter which route you take as the overhead is minuscule.
Essentially, is it better to instantiate a class (for example, 'Db') that you know is going to be used often in a parent class and simply extend the parent class whenever you want to use 'Db', or is it better to instantiate 'Db' separately in the constructor of the classes you want to use it.
Obviously the best route to take in terms of avoiding duplicate code would be to instantiate it in a parent class but just out of curiosity I was wondering if anyone has any insight into how significant/insignificant the effect on the server is for these two routes.
Route 1:
// Parent
class template {
public function __construct() {
$this->db = new Db();
}
}
// Child
class login extends template {
public function __construct() {
// Has access to $this->db
}
}
Route 2:
class login {
public function __construct() {
$this->db = new Db();
}
}
Thanks in advance.
It shouldn't matter performance wise.
If you extend the template class, you still have to instantiate the child class, which in turn will call the constructor of the parent implicitly. This means that in both cases, the DB class will be instantiated. Even worse, the extended class will probably be a little bit slower because it has the added overhead of an extra function call (that of the parent construct method).
That being said I strongly recommend to read up on composition over inheritance. Parent child relations are there to enforce an "is a" relationship. If you start extending the same class simply for performance reasons, chances are you are going to shoot yourself in the foot later on. It is simply unexpected behavior for most programmers to have unrelated classes extend from the same parent.
My understanding is that we can't override the member variable but when i am running the below program, i am getting unexpected o/p
class Parent {
String message = "parent";
void say() {
System.out.println(message);
}
}
class Child extends Parent {
String message = "child";
}
public class Test {
public static void main(String[] args) {
new Child().say();
}
}
In the o/p i am getting "parent" While we are calling the say method using child object and even there is no Parent reference.
Can anybody help me to understand it.
Thanks
The "say" method is on the parent class, not on the child. So when it call for the "message" member it looks at his own, not at the child's one. The fact that the call is make through a child class has nothing to do in it.
Indeed, the member variable is not overriden here. This is expected behavior.
EDIT :
The Java Language Specification says that "If the class declares a field with a certain name, then the declaration of that field is said to hide any and all accessible declarations of fields with the same name in superclasses, and superinterfaces of the class."
"Inherit" does not mean "copy". When you call the "say" method on a child instance, is not a "code copy" of the method that is called, but the method of the parent class, as it is defined in the parent class. And the parent class know nothing about the child variable member.
your child class is extend parent class features! so child class has say method by default and it's value (parent) because parent class say method will called when you call say method from child object. if you want to print "child" instead, you need override your say method in the child class and change that default feature, which extends from parent class.
When you're instantiating an object of a class that inherits from a parent class the constructor calls the superclasses constructor in most langiages I know and my question is: when the superclasse's constructor is called there will effectively be an object of that type in memory, but we're creating an object of the subclass with(in this example) additional values to add to the object so how is that accomplished in memory? Is it added to the original object? Are the contents of the original object copied into a new object with space for all the variables? Or is it something completely different?
A different question that just occured to me, are class variables, like in java, kept in the data segment of the program in memory? How are classes, not the objects, stored in memory for that matter?
Thanks.
I don't really know how engine works, but I know how to test memory usage in PHP. Both scripts
class base {
public function __construct() {
}
}
$start_memory = memory_get_usage();
$object = new base;
echo memory_get_usage() - $start_memory;
and
class base {
public function __construct() {
}
}
class derived extends base {
public function __construct() {
}
}
$start_memory = memory_get_usage();
$object = new derived;
echo memory_get_usage() - $start_memory;
return the same value. It means there'is only one instance in memory, not parent + it's child, when class is extended
phpfiddles: 1st script, 2nd script
Classed are code that define its object, so they are in Code Segment of program. And all class variables are in data segment.
And when we create an object of subclass, first its parents' object are created and it is extended for subclass members. That's why subclass object has all members of its parent class.
I have a groovy class that looks up a method reference and then invokes it. The method being invoked is a private method. When the actual class is an instance of the child class, it throws an error that it cannot find the private method, even though it is the public method in the parent that actually calls it.
In this case, I could obviously just call pMethod2() directly and that works, but I'm trying to understand why this doesn't work as written and if there's a way to correct it so it works.
class Parent {
def pMethod1() {
def m = this.&pMethod2
m() // this call fails if the calling class is of type Child
}
private def pMethod2() {}
public static void main(String[] args) {
new Child().pMethod1();
}
}
class Child extends Parent {}
It is a bit confusing, especially if you're used to C / C++. What you get when using the ".&" operator in Groovy is not an address, but an instance of MethodClosure.
The MethodClosure object contains an owner and a delegate object, which is used when resolving the method to call. In your example, the owner and delegate object will be "this", which is an instance of Child. The method to call is simply stored as a string.
So, the assignment
m = this.&pMethod2
is just a shorthand way of writing
m = new MethodClosure(this, "pMethod2")
When you invoke the m() closure, it will try to resolve (at runtime) the method by looking for methods named "pMethod2" in the owner and the delegate objects respectively. Since the owner and delegate is an instance of Child, it will not find private methods located in Parent.
To make your example work you must make sure that the method is visible to the owner and/or delegate of the closure.
This can be done several ways, for instance by changing the access modifier of pMethod2 to protected, or by creating the closure with an instance of Parent; something like this:
m = new Parent().&pMethod2
Note that is is irrelevant that you created the MethodClosure instance in a method where pMethod2 is actually visible. It is also irrelevant that you invoke the closure in a method where it is visible. The method is not visible to the owner or delegate of the MethodClosure, which is what is being used when resolving the method.