#parent classes and child classes

1 messages · Page 1 of 1 (latest)

pliant pasture
#

stupid question (maybe?) but what am i supposed to put in the parent classes and child classes? and can you give me an example, please? thank you and please ping me once you reply

jagged baneBOT
#

<@&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>.

#
TJ-Bot
Stupid question (maybe?) but what am i supposed to put in the parent classes and child classes? and can you give me an example, please? thank you and please ping me once you reply

In object-oriented programming, parent classes are used to create general attributes and methods that can be inherited by child classes. Child classes, on the other hand, are used to specialize and add unique features to the attributes and methods inherited from their parent class.

For example, let's say we have a parent class called Animal with attributes like name and age, as well as methods like eat() and sleep(). We can then create a child class called Dog that inherits from the Animal class. The Dog class can add specific attributes like breed and methods like bark().

In this example, the Animal class serves as the parent class with general attributes and methods that are common to all animals. The Dog class is a child class that specializes in dog-specific attributes and methods while still having access to the general characteristics defined in the Animal class.

When creating parent and child classes, it's important to think about the relationships between them and how they can share functionality while also allowing for specialization. This concept is fundamental in object-oriented programming and allows for efficient code reuse and organization.

- AI generated response
royal cave
#

@pliant pasture Ugh

#

so this question has some actual answers

#

but my guess is that you are learning inheritance way too early in your curriculum

#

and the examples you've been shown have been like

# 
public class Person {
    String name;
}

public class Student extends Person {
    int studentId;
}

public class Teacher extends Person {
    String subject;
    boolean substitute;
}
#

in which case all i can say is the mechanics

#

you put shared things in the parent classes

little cove
royal cave
#

and things specific to those child classes in them

#

this works, but there are more compelling uses of it that aren't quite so additive / "student is a person"-ey

little cove
pliant pasture
# royal cave you put shared things in the parent classes

let's say i want to create, idk three classes: Dog, Cat and Bird and have a move() method. dogs and cats move through the ground and birds move through the air. would i just make a generic move() for the Animal class and another one for Bird?

#

i.e, a child classes that does something differently compared to the other child classes

little cove
#

they can all move, they just move differently. thats polymorphism at work

royal cave
#

so one for Dog

#

one for Cat

#

and one for Bird

pliant pasture
#

yeah but lets assume dogs and cats move exactly the same way

royal cave
#

but then have Animal have just a "abstract" method

#

then you can choose to either

#
  • Put that default behavior in Animal
  • Write out that behavior twice, once for Cat and once for Dog
  • Make a Mammal or other intermediate to hold the behavior
#

Of those the 2nd one is more commonly useful than you'd expect given how much "always reuse" is espoused

pliant pasture
#

hmm, and what if i want a Shape, Circle and Square? if i have a type, do i put it on Shape or the child classes

royal cave
#

what do you mean by type?

pliant pasture
#

shape type, like circle, rectangle, etc.

royal cave
#

well few options for that

little cove
#

Shape is the type

#

the child classes are also types

pliant pasture
little cove
#

Circle and Square would be concrete types, which extend the Shape type

royal cave
#
  • Don't use a type property at all. Just check with shape instanceof Circle
  • Use a String type(); and put the abstract method on Shape and implement it differently depending on which
  • Use a ShapeType type(); and its the same as the last one except you have an enum ShapeType { SQUARE, CIRCLE } to disambiguate
  • The same as either of the last two options but also have a type field on Shape
#

so like

class Shape {
    String type;

    Shape(String type) {
        this.type = type;
    }
}

class Circle extends Shape {
    int radius;

    Circle(int radius) {
        super("circle");
        this.radius = radius;
    }
}
little cove
#

dont use any of those though, use polymorphism

#

you shouldnt have to check the type unless you're performing introspection

royal cave
#

the first one is the most sensible, but it depends why you want to access the type

pliant pasture
#

sorry if im being annoying but one last example: let's say i have a LibraryItem, and a Book and Magazine that extend the first class. if i want a String type and a getType(), which class do i put it on?

little cove
royal cave
#

well again, matters why you want a type

little cove
#

the whole point of the type system is to not need that

royal cave
#

but it seems like that would be constant per subclass

little cove
#

if you really need the type, there's getClass()

#

but thats for introspection - a class is a type. when you define a class, you are defining the type. no need to have some extra type variable

royal cave
#

so i would use an abstract String getType() on library item then just have each subclass return a string literal directly

pliant pasture
#

ohh alright!! thank you both so much, you're amazing

#

i hope you have a great day, both of you :)