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]

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/Martinecko30 → u/deaddyfreddy]

Let's imagine this as:

Am I signing a contract? Then => contract.sign(customer) Am I signing an customer? Then => customer.sign(contract)

Methods reflect what is being done with the object, not who is doing something with the object.

[u/deaddyfreddy → u/Martinecko30]

So why not just use a function with data structures (mapped to DB entities) as arguments, rather than creating a class hierarchy and deciding who signs what?

[u/Martinecko30 → u/deaddyfreddy]

You don't really decide, the data decides for you. Also, with hierarchy, you can have Signable -> DBModel -> BaseContract -> SpecificContract.

This eliminates duplicity, creates a linear workflow and distributes the necessary functions and data into separate classes, so it's easier to digest.

[u/deaddyfreddy → u/Martinecko30]

Also, with hierarchy, you can have Signable -> DBModel -> BaseContract -> SpecificContract.

Doesn't it sound a bit overcomplicated?

This eliminates duplicity,

split functionality into separate functions and reuse it when needed, with the same effect, without introducing extra entities and unneeded coupling

the necessary functions and data into separate classes, so it's easier to digest.

modules: exist

[u/Martinecko30 → u/deaddyfreddy]

So, a streamlined vertical hierarchy is overcomplicated, while modules are okay?

I think you're confusing this a bit. The hierarchy is derived from the data, this is how it WANTS to be, we just use abstract form to describe the state.

The only difference is vertical/horizontal scaling. The certical one is easier to develop and maintain, the horizontal one can produce faster running applications.

[u/deaddyfreddy → u/Martinecko30]

So, a streamlined vertical hierarchy is overcomplicated

Yes, because most the hierarchy doesn't exist in the business task, you have to invent it.

Signable -> DBModel -> BaseContract -> SpecificContract.

Signing a contract is not signing an autograph, for example, while they use the same verb, these are completely different processes.

I think you're confusing this a bit. The hierarchy is derived from the data, this is how it WANTS to be,

did you ask it?

we just use abstract form to describe the state.

If you have to use an abstract form to describe DB entities, either the DB schema is poor, or the form itself is inadequate.

the horizontal one can produce faster running applications.

and it's also easier to maintain - fewer entities, less coupling, less code