In object oriented programming, when you create a property...

In object oriented programming, when you create a property, are you really just constructing a new sub-class of the object?

Other urls found in this thread:

javaworld.com/article/2077424/learn-java/does-java-pass-by-reference-or-pass-by-value.html
twitter.com/NSFWRedditVideo

what?

Short answer: "No."

Long answer: "What?"

In a sense, from the language spec perspective, you have a class, which has attributes that are members of the class. but the class can be a member of a super class. Still, classes have accessors and mutators of their attributes, but their attributes also have encapsulated data.

Are you really just creating a new encapsulated class for the data of a class?

I get the difference between classes, methods and attributes, but I'm trying to gain more insight from the perspective of a language spec, and considering stuff I learned from other paradigms like functional, and even more different stuff like lambda calc.

I hope this makes at least a little sense. I don't think my understanding is wrong, but it is incomplete, which can make it wrong, in another sense.

no. that would be an association. a class that has a class as an attribute it's associated to the other class. a sublcass would be if the class extends the other class

define "property"

ah okay, i see what you mean about associations.

but onto this part
>a sublcass would be if the class extends the other class
are properties extended by classes?

properties aren't extended. the class is.
the superclass variables can be used by the subclass if they are allowed to, according to their visibility modifiers

Well, i guess I'm borrowing a functional term, but C# has something called "property" which is a way to make private attributes accessible publically

class TimePeriod
{
private double seconds;

/* this is the property, Hours
* it's not an attribute because it encapsulates both special methods
* as a single Method. You can say t.Hours = 50 or WriteLine(t.Hours) because it's overloaded
*/
public double Hours
{
get { return seconds / 3600; }
set { seconds = value * 3600; }
}
}


class Program
{
static void Main()
{
TimePeriod t = new TimePeriod();

// Assigning the Hours property causes the 'set' accessor to be called.
t.Hours = 24;

// Evaluating the Hours property causes the 'get' accessor to be called.
System.Console.WriteLine("Time in hours: " + t.Hours);
}
}
// Output: Time in hours: 24

it is just a shorthand for java style getters and setters over a member variable

You got everything right but no, it's not a subclass. What is your doubt?

Well it just seems like the attributes need to be constructed (declared, initialised, and given mutators/accessors), so a "property" is a special "constructor" for attributes. and if something needs to be constructed, then it can almost be called a class.

So if you didn't at a specific time need to be concerned with the distinctions between class, attribute, and method, you could safely say that a class's attributes are in line with the essence of object oriented hierarchical design because they are, at their core, just encapsulated mini-classes. If that's the truth, then to me i can see the real - hate to use such a buzzword - but the beauty of the OOP design paradigm.

You can think of it that way if you feel.

Under the hood that's the natural properties of properties. When you declare them, the type is checked and according to that a memory space is allocated. When they are initialized the value is moved to that location in memory. Getters and setters are just C# abstractions.
A class on the other hand has a different implementation and a bigger overhead.

no. it's just pointers. you are exchanging pointers. you are not instantiating nothing on getters and setters, just exchanging memory addresses

constructors in oop languages have a very specific meaning, don't use it for stuff other than it's meaning

I see. Thank you. I guess I'll loosely roll with this way of thinking about it until I gain a better understanding.

Oh, nobody said they were just pointers. But that begs the question if they were pointers then why is a constructor necessary? You wouldn't even need a default constructor for a class because the attributes would already be there before you constructed them.

Are they really pointers?

oh, sorry, I may have misinterpreted what you meant. You're talking about "properties" in C#, right?

you use a constructor in order to create a class with the initial data needed. in the constructor what happens is that the object is created with the member variables pointing to the ones passed to the constructor parameters. you don't need to initialize all member variables when you create a class, you can leave them empty and they will point to nothing.

you are thinking that the data that they point to is specified when you write the code, but the pointing happens a runtime. you point to a instance, not to a class. the type specified in the property or member variable is the type. the member variable field is a placeholder for an instance of that class

>no gear attribute

>empty and they will point to nothing.
ah so that's what happens, they just point to nothing, and you'll have a class instance that can be dynamically updated

Classes inside of a class is called composition, much like function composition in math. This is a "has-a" relationship. When a class has a superclass, this is an "is-a" relationship. A mercedes "is-a" car. A car "has-a" wheel. In Java and C++ I think all objects are passed by reference, which is a fancy way of saying that a variable name for an object is just a pointer that points to the object's memory location. The constructor builds this memory location and inits vars and the deconstructor frees the object's memory. Java doesn't use deconstructors because it automatics cleans house. I guess all the methods and attributes are included in that memory location, and are accessible with the "." operator . Each new object has it's own methods and attributes in memory, but not static methods/attributes. Those belong to the class but I don't know how they work memory wise.

yes, they will point to null until you assign an object or variable to them

c++ is by reference and java is by value

no, i remember now, c++ is also by value until you use pointers

Methods are by value, objects are by reference. I think some primitives are also by (like arrays) but that's because they're actually objects.

javaworld.com/article/2077424/learn-java/does-java-pass-by-reference-or-pass-by-value.html

I'm actually reading some conflicting shit about this, so I'm going to agree that it's pass by value. But to sum my post up, an object is a pointer to a memory location, with no overlap with other objects.

>speed isn't an attribute

I hate OOP

OP.car (refuel () {max[0]})

>not making an instance of the propertie to assign them other properties