OOP constructors

Can someone redpill me on Constructors ?

Why do I need them?
My class has methods, I can just instantiate an object then call methods....where do constructors fall in this simple usage pattern?

A constructor is a method that is called on object instantiation

They're useful for initialising object state and passing in parameters
Example:
File file = new File("blah.txt");

If you fill your class with useful default values upon creation, you're using a constructor.

So thats only one call.

your_class instance;
has then everything you need to make it work right away. Which is one call, not two, hence cleaner
your_class instance;
instance.set_some_values(a,b,c,d,e);

You can also pass them arguments (if you write the constructor eccordingly) to give them different default values. That comes in pretty handy


your_class instance(a,b,c,d,e);

Also it enables you to finetune visibilty, if it is for instance not meant that the user can set values after creation themselves, you can directly only set the constructor public, not the set functions

...

wait so is the "init" method in python a constructor then?

what would the code for the File class look like here?

Yes

so does every class just have a single init constructor? can there be multiple constructors?

Depending on the language, you can have constructors that take different parameters, yes. However, typically, it's not done too often.

You can have multiple "overloaded" constructors with different parameters. For example one constructor might have no inputs. One might take an integer. One might take a string. One might take an int and a string. Anything you want, as long as there aren't duplicates.

well based on a quick google search, Python doesn't support constructor overloading. What do I do in that case?

I assume overloading is needed to instantiate an object with different parameters

When you instantiate an object you call the default constructor fgt.

Exactly this. If two constructors for the same class took the same parameters, it'd be considered an error as the 'signature' of the constructors conflict. That is to say, the language would have no way of distinguishing which constructor you intend to use because they are called in exactly the same ways.

As
said, they help to avoid unitialized variables. Anyone who has ever programmed in C probably has faced some heisenbug which in the end was some unitialized int somewhere.

In C++ when a struct's variable is "const" you need to set its value at instantiation, you can't (or better yet, shouldn't) set it afterwards by setters.

>Can someone redpill me on
this phrase makes you look like you're not very good at getting laid.

>Anyone who has ever programmed in C probably has faced some heisenbug which in the end was some unitialized int somewhere.

True. Just debugged my own shell for 2 hours today only to find out that I forgot to dup a file descriptor.

Have optional parameters

what is the point in a language using overloading rather than optional parameters?

You get to use the word overloading.

o-oh..

Look up the concepts of composition, inversion of control, and dependency injection.

Constructors let you generate objects with configurable capabilities without leaking interface details to callers. This is useful when building systems with loose coupling, as it helps improve maintainability.

Constructors are also integral to the concept of RAII, where your class lifetime completely controls the lifetime of all of its dependencies. This allows you to build memory-safe programs without needing a stop-the-world garbage collection.

Jeez, you're an assh*le

Very helpful. I can see these being important to enterprise software / large projects where you integrate with internal and external teams.

Thanks.

Depending on how the overloading is implemented, you get static dispatch which gets resolved at compile time rather than run time. It will run slightly faster in exchange for being less flexible.

Less typing. Optionals are a little cumbersome in Java. Optional.of(value) or Optional.empty() and they don't always serialize nicely.

Say if you have a record class for a DynamoDb table you could have a constructor that creates an instance with only the hash and range key (primary key in a relational db) fields set for lookups, and one which accepts all the fields for your application to call when you're creating new records.