How the FUCK can both high-level and low-level classes both "depend on abstractions"...

How the FUCK can both high-level and low-level classes both "depend on abstractions"? Surely as you get low enough you have to start actually implementing the concrete logic you need to get the work done.

Attached: dip.png (959x480, 38.24K)

Have you never seen a corporate application? You go through 23 interfaces and factories to get to a 10-line method that fetches something from a DB, because "muh clean architecture" and "muh layers".

>Surely as you get low enough you have to start actually implementing the concrete logic you need to get the work done.
This kills the eternal NEET

its women.

The "abstraction" it's referring to here is basically the contract-style communication between services. The high level service does not depend on a PARTICULAR low-level service, it depends on the fact that it is something that accepts X input and provides Y output. And similarly, a low-level service does not rely on the fact that it is going to be used by a particular high-level service; instead it is committed to being something that accepts X input and provides Y output.

In software terms, they both "rely" on the interface, though if you want to be pedantic you could try to complain about the use of the word in simple English.

Yes you stupid shit. You need to decouple your code the maximum from the technological stack. If tomorrow my organization is switching to a different database, I want to minimize the impact it will have on the code.
Layers work if properly applied.

It's just an autistic way to say "decide on your abstractions first and have the low level class implement the decided-on abstraction"

The idea is that you can swap one low level implementation with another very easily, if they both implement the same interface and other classes use that interface instead of the concrete implementations.

Disregard all architecture advice, just write code and make cool stuff. Maintainability is a meme, everything gets rewritten every few years anyway outside the government, banks, and really big companies. And they all suck ass to work for.

Everyone with triple digit iq does this intuitively. Muh software design principles.

Yeah that's right. Because if you have your 23 layers, you can freely move from Postgres to Mongo to S3 to a file system without rewriting anything else, as they have the exact same capabilities and of course you do not use any specific functionality besides retrieving and updating. And furthermore, DB switching happens on average every 3 months, so this is the most important reason for your endless abstractions over abstractions.

I said "layers work if properly applied".
Data layer needs to be separated from the business logic layer... This is pretty straight forward.

Top kek. Do you even fucking know when you'd actually switch databases? What the different types of SQL are good at? What different types of NoSQL databases are good at? Because more often than not it requires a complete fucking redesign, and databases are used per application rather than organization anyway. Do you seriously fucking think you'll only replace the CRUD logic if you switch from Postgre to Cassandra? Fucking OOPlets.

>You need to follow SOLID because... YOU JUST DO, OK?

Attached: Uncle_Bob_400x400.png (400x400, 285.54K)

You illiterate fuck.
Databases switches in an organization usually occur due to licencing, migrating from legacy databases, or other internal decisions
>databases are used per application rather than organization anyway
Detected for never worked in an organization...
Enterprise databases usually have licencing and usually all applications in an organization use the same DB. Even for the DB team, it's easier to manage.

Abstraction layers are pretty common such that you have an interface that any lower-level code conforms to, allowing for easy swapping if necessary. This happens all the down to the hardware itself with HALs.

This writing however is the most confusing and retarded way of trying to articulate that.

dinosaur company detected!
different databases have different purposes
just in one kubernetes config, you might have three or four different databases
mysql, redis, mongo, etcd, all serving different purposes

I can't wait for the day to come when the government regulates programming
>you have a license for writing that javascript project?
>not using TDD? license revoked
>self taught? are you fucking stupid? how are we gonna depend on software that wasn't done by a professional. can you imagine if building architects were """self taught""" and started building us houses that collapsed after a few months? to jail with you.
this would filter out all the boot campers and pajeets

Attached: 1592032943251.jpg (764x713, 308.89K)

>mysql, redis, mongo, etcd
>not just using mssql for everything
ngmi

Attached: 3p96advw8uz71.png (3392x4000, 396.17K)

I will never understand this shit. It's adding modularity to stuff that's very much cpupled. No, you're not gonna use a different FileSystem Writer down the line. Your code doesn't expect that, it will not work

abstractions=interfaces in 99% of modern languages.

The author had to keep the principle abstract so that it doesn't get tied to a particular means of abstraction (like interfaces). Another example would be header files in C/C++.

inb4 "I don't need interfaces". In the real world of ever changing shit, you do.

that's what you get when you always
follow advice like "every function should be at most 10 lines long".
imagine a program that's not too complicated, but not trivial, so something that would amount to 10000 lines of actual logic in total if you were to write it down as a normal program.
if you can only write 10 lines at a time, the only way to get to 10000 is with lots of nested calls. even if you imagine a super clean function that only reuses other smaller functions, it could only make 10 function calls at most. in reality, functions are reused much less often, which means you have to go down lots of levels everywhere.