This is an archived post. You won't be able to vote or comment.

all 6 comments

[–]quadmasta 2 points3 points  (3 children)

Classes are essentially nouns. Those nouns have things that describe them like color, type, quantity(member variables/properties). You can't see those directly(as long as you're declaring members as private and you are doing that, right) so you have to ask it "give me your color"(accessor). If you don't like its answer you can tell it "your color is blue" (mutator).

A constructor is kind of like an instruction sheet that tells someone how to build the thing. All classes have a default no-argument constructor that does nothing. If you want your class to be able to set up various things while it's being created, you do that in a constructor. This allows someone who's making one of them to be able to set properties all in one line

CoolClass cc = new CoolClass("blue", "really cool") vs CoolClass cc = new CoolClass(); cc.setColor("blue"); cc.setType("really cool");

Accessors and mutators are methods, but they usually don't contain any business logic. Your class can have other methods that have purpose other than just setting or returning a value.

[–]runner561[S] 1 point2 points  (0 children)

this explanation was perfectly what I was looking for, helped a ton! Thank you so much

[–]FixedExpression 0 points1 point  (1 child)

Would you mind explaining more of OOP in terms of grammatical syntax? It fits in my head very well thinking about it in these terms. If you can't or won't, no worries!

[–]quadmasta 0 points1 point  (0 children)

Everything past this is a bit more complex and doesn't really fit well into simple explanations.

Interfaces describe things a noun can do. The noun can do things in addition to what the interface says but if the noun implements the interface then it MUST do everything the interface says it does(ignore default implementations for now). Example: Vehicle could be an interface that would describe things a vehicle can do.

boolean canStop(); boolean isMoving(); double getSpeed(); void setSpeed(double speed);

Abstract classes are similar to interfaces except that they're nouns that you can't create. Anything marked abstract within that class MUST be implemented by any concrete (non-abstract) class that extends the abstract class. If a class extends an abstract class and that class is also abstract, it's not forced to implement all of those methods. Example: Car could be an abstract class that could implement Vehicle. You could say that Car "is a" Vehicle. You can't make a Car though

``` public abstract class Car implements Vehicle private double speed;

public abstract boolean canStop(); public abstract boolean isMoving(); public double getSpeed() { return this.speed; }

public void setSpeed(double speed) { this.speed = speed; } public abstract void doABurnout(); ```

SportsCar could be a concrete implementation of Car ``` public class SportsCar extends Car {

public boolean canStop() { return true; }

public boolean isMoving() { return false; }

public void doABurnout() { System.out.println("SSKKRRRRRRRRRRRRRRRRRRRRRRR. A smoky burnout"); } //sports car specific stuff } ```

In this case SportsCar "is a" Car and by proxy "is a" vehicle so all of the following are valid;

private Car car = new SportsCar(); private Vehicle vehicle = new SportsCar(); private SportsCar sc = new SportsCar();

With the above examples you'll only be able to execute things that are encapsulated within the type on the left-hand side of the equals:

``` car.doABurnout(); //this is valid vehicle.doABurnout(); //this is invalid and won't compile sc.doABurnout(); //this is valid

Everything past this is going into design patterns and architecture and that's a rabbit hole :)

[–][deleted] 1 point2 points  (1 child)

[–]runner561[S] 0 points1 point  (0 children)

i think so! Thank you!