[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
▼ Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


File: 879m2h-840443585.jpg (69 KB, 500x500)
69 KB JPG
junior full stack fag asking why OOP is memed on for being hot dog shit aside from this bullshit
>RepositoryFacadeServerSingletonList
^^wtf is this shit^^
what are the alternatives?
>>
File: praise_bell_labs.png (106 KB, 853x621)
106 KB PNG
>>110276259
>what are the alternatives?
Data Oriented Design
Basically everything invented after C was a mistake. Learn Odin.
>>
>>110276259
A singleton is a static class that will only exist once. OOP people do this because they have literally no idea what file-scope is.

Before anyone says otherwise, OOP is about data structures called classes, that have procs in them called methods, and can inherit data from a parent class.
>>
>>110276287
>OOP people do this because they have literally no idea what file-scope is.
Fucking hell this is actually so true. I am doing C and embedded programming in university, with the less experienced teachers I had to constantly explain that static "global scope" variables are file-scoped and don't pollute anyone else's namespace, thus wont ever cause collisions, but they just wouldn't get it, just continued seething about muh globals. These people literally don't understand the concept of file scoped variable.
The ones that had private sector experience didn't mind them at all, in fact only praised my architectures.
>>
>>110276259
>what are the alternatives?
There are no real alternatives for enterprise software. The people complaining about OOP have yet to create anything that isn't a toy.
>>
Alternatives are classified shit you do not have access to and autism
>>
>>110276259
>what are the alternatives?
No alternative. Ask anybody.
>stop using classes, use typeclasses
So classes
>uh, umm...nyo....it's very different..
So classes
boom
>>
>>110276359
I love it when some autismo starts sperging during class and rants about shit thats not relevant
>>
>>110276259
>Needing a "finished" whiteboard model before actually working on anything
>Forcing simple data to have oodles of hierarchical nonsense attached
>King of boilerplate wheelspinning
>Tightly coupling data structures to procedures for no reason
>Forcing goddamn everything to be a stateful reference type
>Complicating what in intelligent languages would be a module

Objects have one purpose: To implement a stateful entity that will live in memory and respond to a specific interface of functions/messages. It is not a universal hammer, it is not how most problems should be solved.
>>
just make shit already autistic nigger
ur tripping over air
>>
>>110276259
Skill issue.
OOP is for high level abstractions and as a means to implement powerful features, like drag and drop plugins functionality.
It is not intended to be used for simple stuff close to the hardware where Data Oriented and Functional are kings.
>>
cuz functional better
>muh memory fingerprint
dont careeee
>>
>>110276287
>singleton
Singleton is an anti pattern. Just use a global const or something.

>>110276259
OOP is not bad, you are using it wrong.
>>
File: vibing.jpg (99 KB, 800x945)
99 KB JPG
>>110276259
I am really tired of those frauds who love to build Rube Goldberg machines.
It is no surprise to me they believe LLMs can code better than juniors, because most of them are retarded and brainwashed.
>>
It's not that OOP is inherently bad. It's people not using it correctly. OOP is supposed to help reduce complexity, not increase it.

Examples:

>turn a very simple REST call into a giant esoteric mess of heavily nested classes, functions, constants, and member variables
>adding or modifying logic at one place requires changing code everywhere else
>data has no clear ownership and is modified everywhere, passed around like some whore
>you have no idea where the data got modified without looking through the whole execution path
>>
>>110276359
This was me a couple months ago. Now i usualy stuff all my global values in a one-off non constant struct. To keep my global data in on place, but no classes was ever needed. I guess it works similar to a singleton, only now it dont have a fancy pantsy gay name
>>
>>110276287
>A singleton is a static class that will only exist once. OOP people do this because they have literally no idea what file-scope is.
Not exactly.

Singleton is used when you have a piece of shit language that can't have static class members. Or one who has them but with limitations.

Otherwise, you don't need singletons.
>>
>>110277765
>data has no clear ownership and is modified everywhere, passed around like some whore
based. This is #1 problem with dweebs doing OOP.

Frankly i would prefer functions operating over immutable data way over OOP. The sissies here will scream "but you have no encapsulation" etc. The code being understandable, concise, and explicit in its business logic is a goal far, far more important than encapsulation.
>>
>>110276259
>what are the alternatives?
procedural programming and heavy arena allocator use to escape the hellscape of pointer rat nests

>>110277908
singletons exist because C++ is so dogshit that it has no guarantees on the order constructors fire in for global/static variables.
>>
File: 1794067883204174.png (204 KB, 614x615)
204 KB PNG
>>110277274
The problem with objects, is exactly this:
> a stateful entity that will live in memory and respond to a specific interface of functions/messages.
Because, programs are really autistic, and everything needs to know exactly who they are talking to. Changing another object, or moving things around means that you will have to travel from file to file, class to class, all over the place, and change the boilerplate spagetti code that communicates to other objects.
>>
>>110277765
>>110277930
individual objects "owning" memory is clownworld shit
>>
>>110276259
>>110277765
>>110277930
The data being passed around and modified in different classes, functions, methods, etc. is on purpose. It's to protect the integrity of the entire system. That class over there has no business knowing what's happening in this class. Just as this class has no business knowing what's happening in that class. Until calls are made and data exchanged. It's the point. This isn't some fucking babby script kiddie shit. This isn't your MySpace page. We're doing important shit.
>>
>>110278003
Unless it's for some API you know the internals of are going to change, marking things as private only exists to stop brown people from doing stupid shit. It is a defensive feature that assumes incompetency.
>>
>>110278003
>i am a retard doesn't know what is "functional programmig passing immutable data", but due to Dunning-Kruger i feel the urge to give my opinion.

kek
>>
>>110277765
>data has no clear ownership and is modified everywhere, passed around like some whore
This is good actually.
>>
>>110276259
My dear you can have the same shit on non oop languages, that's just a name calling.
>>
>>110276278
Odin was invented after C.
>>
>>110276259
>OOP is memed on
Because it made a shit ton of promises but it turns out the only idea worth any value were namespaces tied to data types (which makes autocomplete much easier) and subject-verb-object grammar which is a better fit with many spoken languages than verb-subject-object or object-subject-verb. Also the godawful design pattern shit that was a failed attempt to salvage the OO mess that only made things an order of magnitude worse.
>>
>>110277993
>you will have to travel from file to file, class to class
This is how we know that Java is the only OO language to which you have ever been exposed.
>>
>>110276259
>why OOP is memed on for being hot dog shit
because people get filtered by OOP but don't want to admit it
every complaint about OOP is never backed by a concrete example, because such an example would immediately reveal the skill issue of the complainer

>>110276287
>OOP is about data structures called classes, that have procs in them called methods, and can inherit data from a parent class.
that's a really ass definition of OOP
>>
>>110277274
>>Needing a "finished" whiteboard model before actually working on anything
wrong
>>Forcing simple data to have oodles of hierarchical nonsense attached
wrong
>>King of boilerplate wheelspinning
not even a point made
>>Tightly coupling data structures to procedures for no reason
fundamentally wrong
>>Forcing goddamn everything to be a stateful reference type
irrelevant
>>Complicating what in intelligent languages would be a module
skill issue
>>
>>110278698
smart pointers, RAII and heap allocations at an individual object level of granularity make for a completely deranged memory model and it's why most people think manual memory management is some daunting task. object level encapsulation is also usually stupid. deep object hierarchies and classic OOP world modeling has been proven to be a terrible idea

I don't have anything good to say about OOP
>>
>>110278812
memory management is a different level of abstraction from what a programming paradigm defines
>>
I'm just learning to program but I'm already annoyed by all the gay shit about hiding access to data behind objects or closures. Just let anything access the data and don't mess up. Duh.
>>
>>110278870
yes and no

the paradigm influences the way you think about and approach problems. in this case, the tools of the paradigm itself are literally built for handling allocations in this same mental framework.
>>
>>110278908
>the tools of the paradigm itself are literally built for handling allocations in this same mental framework.
no, that's just you mixing two different layers of abstraction

OOP (or any other paradigm for that matter) doesn't define anything about memory management. memory management is an implementation detail of specific programming languages
>>
>>110278960
bro, the language follows the paradigm. these things are only a step removed from eachother
>>
>>110278983
each language implements its paradigm differently. many languages don't even stick to a single paradigm
the most unhinged take is to complain about OOP while using something as abominable as C++ as the example of "OOP"
>>
OOP good if you’re not a retard
Just get over yourself and start doing things.
Inversion of control is made a lot easier with it, you can inherit whatever you need and just fill out your part of the contract.
If you worked on systems with millions of lines of code that need to be understood by body rental mystery meat programmers you’d know you cannot always read the whole code, and the bounding allowed by oop makes it possible to maintain readability as the project grows. Think of it like an extreme programming version of microservices, but so much that you monolithical app is made of internal microservices
>>
>>110277901
Most of my "singleton" files begin with a
static struct {...} this;
. If this singleton needs to be known by multiple files, then I name it something more unique and extern it, like with my vulkan renderer. There's a global "vk" struct with all the renderer state. Because any other solution would be far uglier and annoying to write.
>>
objects should have have methods
>>
>>110278523
>subject-verb-object grammar
Elaborate
>>
>>110279784
Yes for me in odin its
CORE : struct(
Stuff...
) ={}
Or something similar, and i name it with all caps
>>
>>110277901
>>110280096
Its not a contant thoug, retard
>>
>>110278063
It's not good in practice. When the data is modified everywhere willy-nilly it completely defeats the the point of encapsulation. It's a sign of disorganized development.
>>
>>110280122
>It's a sign of disorganized development.
only if you've bought into the idea that encapsulation should be drawn around individual objects
>>
>>110280122
>It's a sign
But is it a pain in the ass?
>>
>>110276287
>because they have literally no idea what file-scope is
Is this why they always complain about muh globals?
>>
>>110276259
Hating on OOP is so 2010s.

By now, every non-retarded programmer has realized OOP is trash. Those who still believe otherwise are hopeless. Maybe they even think LLMs are good.
>>
>>110276259
Do you want a short answer or an effortpost answer?

Short answer is that OOP by itself is fine. It makes a lot of stuff easier. That has the effect of allowing more people to do shit. That has the knock-on effect of having more people who barely know their shit do things.

So they start adding on more shit to make it cooler and more for smart people. Patterns are really just a way of noticing that you have some problems showing up again and again. So you solve it in pretty much the same way again and again. It's a get this... PATTERN of doing things.

Also, your class name doesn't make sense. It should be something like a
ServerRepositoryFacadeListSingleton. That is a completely retarded thing to have and excellent Spring-quality ragebait. At leaset this way it makes some sense.

If you want something that could conceivably exist, try something like
"AbstractProxyFactory" which is completely clear and readable in what it does.
(It's an abstract proxy-factory. A proxy is something that you put in front of the real object so you can intercept calls to it so you can do things like check for annotations and such. A factory would take an object and give you back a proxy of it for example. Spring does this a billion times, so they have a lot of proxyfactories. Therefore it makes sense that they have an abstract one that just has what's common for all of them, so you can subclass that and save yourself a lot of trouble. Especially given that Spring rewrites your running code for its @Bean things.)

An effortpost would be a long post about how OOP is actually fine, at least some form of it, but it's not rigidly defined, so you have a morass of morons (absolute alliteration art) running around making up versions of OOP and another shitting on it.
>>
>>110276359
It can be annoying to deal with actual global static stuff when you're running unit tests, and a warning against doing that can lead to people not scoping their retarded criticisms.

>>110277274
Imagine implementing something like a database connection pool.
If you put it inside a class, you can do things like setting the connection string, username, password etc. somewhere no other object is allowed to touch or even read it.

You can add a bunch of tweakable settings to it, and make those settings mutable, but only through a function you have to call that can validate your new changes, preventing murder and mayhem should someone fuck them up. Sure you can call getConnection() and get a connection (provided there is a free one. inb4 just make a lot, that costs you perf.)

But for most users, all they really want is a ref to that pool so they can get a connection when they need to talk to the DB. Doesn't this sound nice and simple?

But if you don't fucking whiteboard that shit out before you code something the entire enterprise uses, I will personally see that you are fired (out of a cannon, into the sun).
>>
File: 1623806385442.png (316 KB, 702x838)
316 KB PNG
>>110281138
>It can be annoying to deal with actual global static stuff when you're running unit tests,
I don't run unit tests
>>
>>110281149
> We all have test environments.
> Some of us also have dedicated prod environments.
>>
>>110276259

Guessing you're not full stack?

You see, our understanding of systems is a little bit... *different*, from yours.

When we take a look at the pathways of logic and data we see *everything*, all at once. This is what makes full stack engineers so powerful within the workplace; our understanding is holistic, which is why we can quickly parse systems and designs that may seem obtuse to front or back end engineers.

Next time you talk to a full stack, show some humility. A dash of respect doesn't hurt either. It costs you nothing.

And remember, there's a reason almost all 10x engineers are full stack.
>>
File: imm-objs.jpg (32 KB, 428x305)
32 KB JPG
>>110277930
>functions operating over immutable data way over OOP
Cosmolang solved this problem with Immutable Objects.
obj#{_prototype: {}, move: rel#, x: 1.0, y: 1.0}
obj#{_prototype: {}, move: rel#, x: 2.0, y: 1.0}
obj#{_prototype: {}, move: rel#, x: 3.0, y: 1.0}
obj#{_prototype: {}, move: rel#, x: 4.0, y: 1.0}
>>
I'm sure 90% of OOP camp is just because some fucking idiot thought they want job safety, probably somewhere in academia, and were able to sell the idea successfully to idiots. 90% of design patterns are useless abstractions, only causing mental gymnastics around the problems they're trying to solve. If OOP was easy (and useful), every webdev framework would be OOP, yet all of them seem to favor FP.

>>110278874
oh my sweet summer child, hiding data is not even that bad in the grand scheme of things. bad, but not the worst part.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.