#Polymorphism meaning

1 messages · Page 1 of 1 (latest)

vale sentinel
#

From what I understand polymorphism is something like
ParentClass obj = new ChildClass(stuff in param);

nova creekBOT
#

<@&987246399047479336> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

vale sentinel
#

is there anything else to it?

nova creekBOT
#
TJ-Bot
From what I understand polymorphism is something like ParentClass bbj = new ChildClass(stuff in param);

Polymorphism in Java refers to the ability of a variable to reference objects of different classes in an inheritance hierarchy.

In the context provided, the line of code "ParentClass bbj = new ChildClass(stuff in param);" demonstrates polymorphism through a concept called dynamic method dispatch. This means that the reference variable 'bbj' of type ParentClass can refer to an object of ChildClass.

By using this approach, you can write more flexible and reusable code as you can create methods that accept objects of the parent class but can also work with objects of any child class. This allows for code that is easier to maintain and extend.

Polymorphism is closely related to inheritance in Java, as it relies on class hierarchies where child classes inherit from parent classes. By utilizing polymorphism, you can write more generic code that can work with multiple related classes without needing to know the specific details about each class.

Overall, polymorphism is a key feature of object-oriented programming in Java that allows for flexibility and extensibility in your code by enabling different classes to be treated uniformly through their common parent class.

- AI generated response
vale sentinel
#

its ust using the parent class to refer to child class?

#

but whats the difference between
ParentClass obj = new ChildClass();
and
ChildClass obj = new ChildClass();

#

i think its like u can access childclass and parentclass methods but cant u already do that with the extends keyword

exotic bronze
#

parentObj can point to a boyObj or girlObj, but boyObj type variable can't point to a girl

#

because girl IS A parent, but girl IS NOT A boy

tawdry cliff
#

The value of it is not in the declaration of a variable, but in the signature of methods.

public T doSomething(ParentClass o) {
   ...
}

This method can be used with any subclass of ParentClass.

dense snow
#

Fun with pattern matching as well.

tawdry cliff
#

We generally declare variables with the most general type, to (a) communicate to readers/maintainers that we're only using properties common to this type, not only the subtype, and (b) to make it easier to change our minds about the subtype with minimal change to the application.

#

Usually justified as an application of the Liskov Substitution Principle, though often that's an overreach.

vale sentinel
#

yeah but functionally is it different? or is it just a convention used

tawdry cliff
#

You can only access methods declared on the supertype (or it's supertype). But the implementation that is executed is whatever is on the actual object type (ChildClass in this case).

vale sentinel
prime zealot
tawdry cliff
#

You can think of it as the compiler sees ParentClass, but the runtime applies ChildClass.

dense snow
#

Any ancestral class.

prime zealot
#

when u write Animal animal = new Dog(); then u created a dog, not an "animal"

#

the instance is the dog

vale sentinel
#

yes

prime zealot
#

but u point to it via a variable that says "i can refer to anything thats an animal"

#

by that u increase ur code modularity

#

ur code can now also work with a cat

#

should u decide in the future

vale sentinel
#

ohh ok

#

so its mainly used if you want to refer to the child classes easily

#

like if you want to add a cat class or smth you can do
Animal animal = new Cat();

prime zealot
#

i think ur missing the point

#

see, if u need a list in ur code

#

then u should write List

#

not ArrayList

#

u dont want to be too specific

#

but only mention what u actually need

#

bc that way ur code can then work with anything that fulfils the requirements

vale sentinel
#

ok

prime zealot
#

lets say u write a method that feeds sth

#

then all u need is that the thing u want to feed has a eat(Food food) method

#

u dont need the fact that it can walk

#

or bark

#

or jump

vale sentinel
#

yeah

prime zealot
#

so ideally what u want to do in this situation to maximize code modularity/flexibility is to create an interface that specifies just eat

# 
interface CanEat {
  void eat(Food food);
}
#

and now u can write

vale sentinel
#

ohh so if you want a method to work generically then you use polymorphism?

prime zealot
# 
public void feedIt(CanEat canEat) {
  canEat.eat(new Banana());
}
tawdry cliff
#

People ask "why can't I"

Animal animal = new Dog();
animal.bark();

But think of animal in the more general form. The compiler may not be able to prove it's a dog.

void m(Animal animal) {
    animal.bark();
}

This could never safely compile, because I might pass a reference to a Cat object.

The benefit of being able to use an object reference as one of its ancestral types, is so you can define behaviour that is valid for all subclasses. That is the 'polymorphic' behaviour.

prime zealot
#

maximum flexibility

vale sentinel
#

yeah

tawdry cliff
# 
void m(Animal animal) {
    animal.makeNoise();
}

Dog and Cat can make different noises, but our code works with both.

vale sentinel
#

ohh

tawdry cliff
#

And as Zabuzard indicates, we would generally favour interface types that are more general than the object-hierarchy. This is less restrictive for the caller.

prime zealot
#

these things make a lot of sense once u write larger projects with hundreds of files

tawdry cliff
#

or thousands...

vale sentinel
#

so if you want smth to work more generally you use polymorphism

prime zealot
#

cause u really dont want to have to change all ur code just to let it additionally handle a cat and a bird

#

ideally u just always write down the type that u actually need

#

if all u need to do is iterate over sth then ideally u write Iterable and not List and not ArrayList

vale sentinel
prime zealot
#

it ties in very well with the purpose of interfaces

vale sentinel
#

giving behaviors to objects

tawdry cliff
#

"Make whatever noise this object makes" instead of writing "if it's a bird, chirp, else if it's a cat, meow, else if it's a dog, bark, else fail because we don't handle this one yet"

vale sentinel
#

was my explanation good

#

like if you want something to work for all versions of the object you use polymorphism

#

and add override methods only when you need to

dense snow