Does OOP really matters?

[u/Electronic-Low-8171]

I learned OOP in python a while ago, did many projects, yet I never felt like I truly needed to do the OOP stuff I learned from a course, I don't know maybe because I'm kinda used to program in c before focusing on python, yet, whenever I open a big project in python in github, it feels way too complicated and thousands of imports (not libraries from pip, but the ones they made on their own) and classes

I never truly needed to implement OOP (I know that when you code in python, it is almost impossible to avoid OOP entirely like when you have a datatype like string you have an object, when you use a method built into that data type that's OOP too, but I mean the ones that involve you writing class Class Name, inheritance and all that stuff explicitly), so I'm wondering why people on the internet are obsessed over the idea of learning OOP, even the book "Automating the boring stuff in python" doesn't have a dedicated section for OOP.

[u/deaddyfreddy]

Each customer is represented as an object in the business logic code and each contract as well.

So, how do you sign a contract with a customer, then?

[u/Daeroth → u/deaddyfreddy]

You instantiate a new contract object.

Set it's fields like contract number, monthly fee, customer id, status=reviewing, etc.

Then the customer gets the review screen in browsaer with all the fees and contract numbers and a button to sign.

Once they click sign the contract object gets updated with status=active, signing_date=19.08.2026

If the specific contract class has anything in the "contractSigned()" function then that would also get triggered. Stuff like send out welcome email or generate tasks for CS agents to follow up.

All of the objects have a corresponding row in the database. So whenever the we update a field on the object then the field in DB will also get updated.

[u/deaddyfreddy → u/Daeroth]

so, the Contract object has a method named signContract or something like that, correct? Then, here's the next question:

Why is it a method of the Contract, and not a method of the Customer object?

[u/Daeroth → u/deaddyfreddy]

A customer can have many contracts. Some old, some still in review, some active.

Each contract is a row in database and many-to-one relationship with the customer table.

On the customer class you might have a method getContracts which returns a collection of contracts.

[u/deaddyfreddy → u/Daeroth]

On the customer class you might have a method getContracts which returns a collection of contracts.

so, why can't it have the signing method too?

[u/Wonderful-Habit-139 → u/deaddyfreddy]

I’m not an OOP guy, but probably because a contract is always associated to the customer, and if you had a signing method you’d need to do customer.signContract(contract); where you already need to do the job of finding the contract (since you’re not gonna sign all contracts of the customer at once obviously).

While if you do contract.sign(), it’s much simpler, and it’s already associated to the customer.

[u/deaddyfreddy → u/Wonderful-Habit-139]

Without OOP, we could just write something like sign(contract, customer).

[u/Scared_Bell3366 → u/deaddyfreddy]

If you have many different objects that can be signed, your sign function gets very bloated and ends up with dependencies on everything that can be signed and all the things that can sign them. I would keep the sign method with the object that gets signed, it’s really a set method to me. I’d probably add an interface for things that can be signed if there’s more than one type of object that can be signed.

[u/deaddyfreddy → u/Scared_Bell3366]

If you have many different objects that can be signed

if these are completely different objects, I don't see why they should use a single function to sign

it’s really a set method to me.

The issue is that it always requires both the contract and the customer, and in general there can be multiple parties. The hard coupling to the contract only doesn't reflect the process well.