oop

[glass pasture]

since im learning alone i just need to know whats the next step
or where to really implement oop practices in projects

[modern kayak]

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

[rain prawn]

ok what do you currently know about oop?

whats your current state?

[glass pasture]

i learned it at school last year in c++ mainly and then i went to python learned a lil too ut when i went to django i didn't even have to use a class to create my web app project (first)

now we in java but i feel like we repeating the same stuff

i need a vision

[glass pasture]

i know all the basic stuff inhertance collections exeptions , encapsulation practices and so on

[rain prawn]

collections and exceptions are not part of OOP

lets start at the beginning

classes and objects

what can you tell me about them

[glass pasture]

classes are a collection of fields with various data types that has constructors to initialize those fields and also methodS

object are used to instance a class

i tried not googling

excuse my english btw plz

[rain prawn]

all good

we would call classes a template/blueprint for objects

and objects are an instance of a class

constructors are the starting point of an instance

and methods are used to operate on our instance

imagine a class like this:

public class Car {
    
    // fields, constructor ...

    public void move() {
        // implementation of this method
    }

}

we have a Car class which is the template for a car instance

it defines stuff like fields and methods

we have a method move() which is used to operate on a specific Car instance

an instance is made with the new keyword

Car porsche = new Car(...);

what do you know about methods?

[glass pasture]

everything tbh

its simple

[rain prawn]

ok yeah it is

[glass pasture]

parameters and return type and instructions

[rain prawn]

do you know about access modifier (public, protected ...)?

[glass pasture]

yes

[rain prawn]

I am not sure if they are like in c/c++

[glass pasture]

me too but in c++ it only gets complicated when there is inhertance of multiple class

diamond inhertance and such stuff

[rain prawn]

which isnt possible in java

[glass pasture]

really

[rain prawn]

you can only extend one class

but implement multiple

difference between abstract classes and interfaces

ok do you know about static?

[glass pasture]

i think so static is when we want some data variable to bbe the same whenever we instance the class

[glass pasture]

that is pretty confusing since i just started java idk too much the diff btw extend and implement

[rain prawn]

we will get to that later

[glass pasture]

okk

[rain prawn]

kinda

[modern kayak]

The keyword static controls ownership (not accessibility). A method or field that is static belongs to the class instead of an instance of a class. Suppose there is a simple class called Person:

class Person {
  String name;

  Person(String name) {
    this.name = name;
  }

  String getName() {
    return name;
  }
}

Now, you can create as many instances of this class as you want:

Person first = new Person("John");
Person second = new Person("Jane");

And each person has his own name, because it is non-static. So we can do

System.out.println(second.getName()); // prints Jane

In total, since there exist 2 instances of the Person class now, we also have 2 names and also 2 getName() methods. Each belonging to its corresponding instance of the class.

Now, if something is static, it belongs to the class and not to instances of it. While we just created 2 instances of Person, there exists exactly one class Person itself. So if we write:

class Person {
  static int amountOfEyes = 2;

  String name;

  Person(String name) {
    this.name = name;
  }

  String getName() {
    return name;
  }
}

Then amountOfEyes belongs to the Person class, not to the instances we created. As a result, there exist in total 2 names, 2 getName() methods but only one amountOfEyes variable.

As such, we also access this variable through the class, not through instances of it:

// Like this
System.out.println(Person.amountOfEyes);

So neither first nor second nor third have their own amountOfEyes. There is only one amountOfEyes and it belongs to the Person class itself.

To summarize, static things belong to the class, there is only one class no matter how many instances you create of it. Non-static things belong to instances of a class, each instance has its own set of non-static fields and methods.

squidxtv • used /tag id: static · Dec 10, 2023, 11:13 PM

[rain prawn]

this explains it really good

To summarize, static things belong to the class, there is only one class no matter how many instances you create of it. Non-static things belong to instances of a class, each instance has its own set of non-static fields and methods.

[glass pasture]

yess i get it

the static means its general for the class all instance have it

[rain prawn]

yeah they all share it

now there are 4 important concepts in OOP:

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

Abstraction is achieved by using interfaces and abstract classes

its use case is hiding complexity of implementation

and exposing simpler interfaces

for example List<> and ArrayList<>/LinkedList<>

List is our interface

[glass pasture]

im afraid i dont get it

[rain prawn]

OOP can be tricky

but at some point it will make click in your head

its just so many new things coming up

[rain prawn]

which defines the methods

our subclasses need to implement those

like add(), remove(), clear() ...

another good example would be Entities in Minecraft

you played it?

[glass pasture]

not really lol roblox yeah my bro is a dev

[rain prawn]

ok but Entities are more general anyways

imagine you have a game which has a Cow and Sheep

both are so called Entity

now instead of doing this:

public class Cow {
    ...
}

public class Sheep {
    ...
}

we would do this to represent our Cow/Sheep as a class which we later instantiate if we for example spawn one:

public interface Entity {
    void spawn(); // example methods
    void despawn(); 
}

public class Cow implements Entity {
    ...

    @Override
    public void spawn() {
        // implement this method
    }

    @Override
    public void despawn() {
        // implement this metho
    }

}

public class Sheep implements Entity {
    ...

    @Override
    public void spawn() {
        // implement this method
    }

    @Override
    public void despawn() {
        // implement this metho
    }

}

so we have a general concept (an Entity in this case) and have subclasses which are a type of an Entity in our case

this can be useful for stuff like this:

imagine we need to store all Entities in our world

without our interface we would need to do this:

List<Cow> cows = new ArrayList();
List<Sheep> sheeps = new ArrayList();
...

create a List for each new Entity in our world

but instead with the Entity interface we could do this:

List<Entity> entities = new ArrayList();

and could store all entities in this arraylist

no matter if they are cows or sheeps

so in this case we dont care about the internal implementation of our Entity (either a cow or a sheep)

so we abstract away our concept of our Cow and Sheep

and have an Entity instead

[glass pasture]

what defines what classes are inside the entites is the implents keyword ?

[rain prawn]

what?

the implements keyword is used to say that a class is implementing an interface

so a subclass of an interface

[glass pasture]

yes ik

cow sheep are classes

entity is an interface that has methods

[rain prawn]

yeah

its totally fine to do this in java

Entity cow = new Cow();

[glass pasture]

when we create a list of entities what are we exactly doing

[glass pasture]

oh lol thats new

[rain prawn]

because Cow is a subclass of Entity

same as doing this:

List<String> lines = new ArrayList<>();

we have the implementation ArrayList but abstract away the implementation and store it in a general concept List

[glass pasture]

oh

[rain prawn]

because we dont care about the underlying implementation

we dont care if its a Cow/Sheep or in this case an ArrayList/LinkedList/whatever

[glass pasture]

okey after reading multiple times i kinda get it

[rain prawn]

yeah its hard to get, but learning by doing is really helpful

and you will get it soon

now this was all closely related to Inheritance

it allows us that one class gets all the fields and methods from another class (its superclass)

this can be achieved with interfaces and abstract classes

if we look back at the Entity example:

public interface Entity {
    void spawn(); // example methods
    void despawn(); 
}

public class Cow implements Entity {
    ...

    @Override
    public void spawn() {
        // implement this method
    }

    @Override
    public void despawn() {
        // implement this metho
    }

}

public class Sheep implements Entity {
    ...

    @Override
    public void spawn() {
        // implement this method
    }

    @Override
    public void despawn() {
        // implement this metho
    }

}

we define the spawn and despawn methods

Entity is called the superclass or parentclass

[spice zinc]

it helps to look at abstraction irl too, makes things a bit easier to relate to code

[rain prawn]

and Cow/Sheep is our subclass/childclass

[glass pasture]

how

[rain prawn]

the problem is that you later only think in that point of view

everything in real life can be a class

it got its properties

and its functionality

[spice zinc]

think of a fish tank. it accepts fish. fish function the same way (they swim, they eat, etc...)

but "fish" is just an abstraction; the actual types of fish are "clown fish", "puffer fish", etc...

so a FishTank could accept Fish, without having to know exactly what type of fish is being added to it

[glass pasture]

yes abstract is by def not specific ig

[glass pasture]

thats a good example

[rain prawn]

same with our Entity or literally anything in the world

[spice zinc]

class FishTank {
    List<Fish> fishies;

    void addFish(Fish fish) {
        fishies.add(fish);
    }

    void addFood(FishFood food) {
        for(Fish fish : fishies) 
            fish.eat(food)
    }
}```

[glass pasture]

i really thought interfaces have nothing to do with inhertance

[spice zinc]

helps to look at a few examples. a WashingMachine accepts Clothes, but "clothes" is just an abstraction for "pants", "shirt", etc..

stores sell "items", which is just an abstraction

a store may sell "balls", which is an abstraction for "soccer ball", "base ball", ... you start forming hierarchies of abstractions: "a soccer ball is a ball, and a ball is an item" https://en.wikipedia.org/wiki/Is-a

so yeah, inheritance plays a role. but its more of a type-inheritance situation

[rain prawn]

yeah you will end up with such an hierarchies for example

you could store all in a List<Item>, or maybe if you want to store all Balls in a list you would have List<Ball> which would accept SoccerBall and Basketball but would not accept Drink/Water because they are not of type Ball

this is a good short explanation for these topics but is not covering all

https://www.baeldung.com/java-oop

need to go to bed now

[glass pasture]

i just wanted to say

it

thank u bro for ur time

+REP

u too dioxin

[rain prawn]

np

[uncut maple]

hello

[spice zinc]

hey. have a question?

[uncut maple]

@spice zinc yes?

[spice zinc]

whats your question?

[uncut maple]

how program

question mark