Literally what's the problem with OOP

Nothing wrong with it and it's useful in many applications. Just happens to often be overused.

Use it because it makes sense for your application, not because you want to use OOP.

Although my problem with majority of OOP languages is that it hides copying vs sharing on e.g. function calls, not making it obvious when objects are copied and when aliased.

class members are just global variables. A function should do the same thing every time you call it and only change based on the arguments you provide. OOP fucks this up, making reasoning about state impossible. Add in constructors etc... and you often cannot reason about the initial state of objects. What a mess.

But null & downcasting are objectively bad and you shouldn't need to use them in any language with a decent type system.

Are you talking about c++ or another languag?

Heh fuck that shit we need MORE abstraction layers.

interface IBindable {
val field: T
fun addObserver( observer: IBindObserver, trigger : Boolean = true ) : Contract
}

class Bindable(default: T)
: IBindable
{
private var underlying = Underlying(default, this)

override var field: T
get() = underlying.value
set(value) {underlying.value = value}

// ....

private class Underlying( default: T, root: Bindable) {
var value: T = default
set(value) {
val prev = field
if( value != field) {
field = value
triggers.forEach { it.invoke(value,prev)}
}
}
}

operator fun getValue(thisRef: Any, prop: KProperty): T = field
operator fun setValue(thisRef:Any, prop: KProperty, value: T) {field = value}
}

interface IThing
{
val xBind : IBindable
var x : Double
}
class Thing() : IThing
{
val xBind = Bindable(0.0)
var x by xBind
}

I ain't even gotta TELL you whether or not my fields are explicit or backed. I love doing niggerlicious shit in Kotlin.

C++ grinds my gears with r-value references for sure having no special syntax for caller scope, but not what I meant

Please, do enlighten me on why a built-in failure value is bad, but Optional with exceptions is good.

Enlighten me on why downcasting breaks OOP but quadrupling your code base so you can add a controller to wrap your already otherwise tightly coupled, self contained module that fits an external generic interface is better.

C++ makes this shit the worst. Add in copy constructors, move semantics, all the pointer shit from C, smart pointers, RAII, operator overloading, Static/dynamic allocation, constructors, destructors. It becomes almost impossible to know how modifying an object is going to work and if you are going to leak memory.

Poor API design is not a fault of the language.
C++ does not make it easier, I can at least agree with that.

yeah, the reason to like Rust at least a little bit is how obvious and predictable all these semantics makes
Also r-value reference is really the same thing as good old pointer except it contracts the aliased thing isn't null or uninitialized. Why the hell make so much difference and required boilerplate about it.

OOP forces you to conceptualize a system as objects with "state" and "behavior". State variables and methods. This works in some domains, like GUIs or video games, where you have distinct "things" that take actions.

However many programming projects don't fit into this paradigm. Most of the time, the task is more about taking data from Point A to Point B, and doing a few transformations in between.

Perfectly executed OOP is probably ok. But anyone who has done real world programming knows this never happens. Objects become giant amalgamations of unrelated state. You end up getting side effects happening all over the place. It becomes impossible to know what your program does just by reading the code. Tools like Visual Studio with its excellent debugging features arose because OOP code has complexified things to the point where the only way to know what your code is doing is by running it and dropping breakpoints in to see whats actually happening.

this.
i just started working on a code base of 100k lines of C++ and the fucking thing has 500 classed in total.

You can do statelessness in OOP. Actually most industry stuff is driven by asynchronous, test-driven depency-injection stuff which makes statelessness if not forced, HIGHLY encouraged. The only state you should have are your queues, your schedules, and your Database.

Don't know if you'd call it OOP. But they do.

Smalltalk is fine. CLOS of Common Lisp is fine.

OOP requires statefulness by definition. You can use OOP languages to do stateless programming but at that point your design approach is no longer OOP.

200 lines per class on average? Probably should be broken up more. 200 is reasonable, but I bet some of them have over 1000. How the hell would you isolate and test a 1000-line monolith? Unless it's like a Simplex algorithm or something.

People don't know OOP and just build class and objects instead of thinks better abstractions.

OOP in the loo

I disagree with that. It doesn't require state, it requires objects. It's not so much about how complicated the objects and how they live are it's about the objects defining scopes and roles. This guy makes coffee. This other guy has a coffee maker. It doesn't need a durable state in order for this object-oriented relationship to exist.

People trying to use it every fucking where and hailing it as the be all end all solution for all problems.

>by definition
Show me the definition.

"having a coffee maker" is state

Attached: oop.png (1364x1328, 986K)

oop

Attached: OOP_in_loo.jpg (624x351, 43K)

If you call that state, there's no such thing as stateless

It's not stateful if it's intrinsic to what the object that has the coffee maker is. That's how Dependency injection works. This guy is not responsible for making coffee, but he IS responsible for having a coffee maker. No matter how many times you call him coffee will be made the same way. But you COULD create a different version of him that does it differently.

That's not OOP, that's emulating procedural programming with objects.

The entire point of objects is to encapsulate state. You can use objects as function carriers, but that's not OOP any more.

the C++ style of OO which was widely copied by most languages is just an extention of imperative programming that connects structs with procedures. When you use inheritance it makes everything very static and monolithic, refactoring a large OO application basically means rewriting the entire app from scratch.

The problem with OOP is that hard coupling is bad, and inheritance is hard coupling.

Without inheritance, OOP is just structs and generic functions.

class ClassName{
/* definitions go here */
};

not true at all

See here is where you are confused. Using dependency injection explicitly makes this situation stateful. The behavior of the coffee maker changes depending on what you inject into him. His state may never change over the course of the program, but his still has state.

To make this situation stateless you would use polymorphism. Two subclasses of coffee maker which make coffee differently.

Again, I disagree. And not really how I've seen it taught these days. Objects encapsulate. But they don't need to encapsulate state. They could encapsulate responsibilities.

You can call it "mimicking procedural programming" if you want (whatever that means; at the end of the day everything's compiled to procedural bytecode). But for us, the hierarchy of scope as expressed through objects and their relationship to other objects is the abstraction which we are leveraging to get modular code which is testable at the individual level and whose access levels are intrinsic to what an object does. Doesn't have to be the only way to do basically the same thing, but it's how we do it.

C did it right.
Oh you want to combine these different data into one thing? Here you go, a struct.
Oh you want to do things with the struct? Write a method that takes a pointer to it.
Oh you want to do ""inheritance""?
Just put your parent struct inside the child struct as first member and now you can safely typecast the poiner to the child as a pointer to the parent. Done and Done.

>See here is where you are confused. Using dependency injection explicitly makes this situation stateful
I'm sorry, your definition of "stateful is meaningless to me. It has nothing to do with thread-safety and pure functions, so I don't particularly care what your precise definition is.

I had a job once where people code without commenting a shit. I had to use classes without knowing what they actually did. It was all about creating virtual classes because they fucked up their inheritance everywhere. Shit was impossible to debug. I quit the job after a few weeks trying to figure out their shit. Turns out within one year they had 3 software engineer before me that resigned, and another person working with me thought about resigning too.

Run away from those people.

The stupid contrived example is always the cause of problems when discussing or teaching oop. Programs have state and you can't get around that. Objects do not have to express state, they can be trivial data containers that you apply filters and maps to, or they can be pass through generic concepts that use one processing path or another. If the program is not transforming itself from one input to the next, you are not representing state. This is basically all modern webserver code.

see OOP is fine. Most of the time, people using it are retarded

I odn't think it's taught poorly. Where I studied, the people teaching everything about oop, UML and all this shit were actually pretty good. Problem is most of the student (like 75% of them) wanted to fix everything using inheritance and creating classes where you didn't need it. I'm pretty sure those people didn't understood the point and never will

Dependency injection is a solution for a problem that shouldn't exist in the first place. When I see people get a hard-on for DI it's a good indicator they are a weak programmer.

You forget that the vast majority of CS undergraduate and postgraduate degree holders learned in India. Even plenty of US schools are shitty Java shops that use the cat/dog/human/animal example from day one.

OOP is indeed taught poorly in most schools, and often as the goal rather than the means

How do you feel about "composition over inheritance"?

OOP is retarded because it leads to retarded code.

Most programmers are total brainlets who can't actually understand anything other than purely procedural design. Since OO is taught pretty much universally these developers end up cargo culting OO patterns without actually building a useful architecture. The OO ends up just being a layer of nonsensical complexity as a result, and people blame OO instead of the programmer.

Many problems lend themselves to an OO solution. Many problems do not. A good programmer will research the problem at hand until it's obvious to them which paradigm to use for part or all of the solution. These patterns, OO, functional, procedural, declarative, are all tools. None of them are really superior to another in the general case. Religious fervor around them comes from people who don't really understand them.

>the hierarchy of scope as expressed through objects and their relationship to other objects is the abstraction which we are leveraging to get modular code which is testable at the individual level and whose access levels are intrinsic to what an object does.
Wew, you should be a businessman or salesperosn.

>purely procedural design
That is often the best design, by the way.

spell it backwards

pee oh oh?

Care to elaborate on this? Because DI at its core just means initializing a value using another value and is used absolutely everywhere, even in immutable functional programming contexts.

eep ho ho?

Attached: 111.png (640x480, 324K)

Objets are a social construct and don't mix well with mathematical concepts, its just adding another layer of irony into your code. Its like trying to understand a joke made by an autistic person, he is just describing the real world.

>objects are a social construct
>adding another layer of irony
9/10 fuck c++

I'd turn that around and say that mathematical concepts and constructs are not a good way of describing solutions to social problems. I'm not suggesting OOP and inheritance is the best way to model every problem domain (in most instances it is quite useless) but it does help bridge the gap between the two worlds.

Hard coupling is not "bad". It's counterproductive to reuse, but lots of code is never reused. You should be using inheritance when tight coupling is desirable. When coupling is counterproductive you should be using interfaces or contracts. Sometimes it makes sense to provide a base/abstract class as your integration point, but you need to be very careful to not fall into the fragile base class or god class antipatterns. Be extremely defensive with scoping and make it very clear what acceptable use cases are if you ever do this.

I don't really agree. When handling relational data I've found that the declarative approach of SQL is far superior to anything else. When working with parallelism, the functional approach results in the fewest issues. OO lends itself to problems which require many controlled mutations of clearly grouped state. Procedural is really only good when there's a clear and obvious flow of events which must happen in order, which is typically what happens in an individual method. I wouldn't want to model most problems in a purely procedural way unless they were trivial or a small part of a larger whole (a single method). Procedural gets a lot of work, but rarely as an overarching scheme.

even C-tards use OOP without realizing it. Many of the libraries they use have structs that you don't know the contents of which you pass to functions that act like methods. OOP is just a nice way of organizing a program

lombok

in the setter/getter, you can put all the mutex bullshit in them so you don't have to shit up your main program with that stuff. It can also have a call to refresh the variable if it needs to be filled in before being read. setters and getters dindu nothing wrong

>You should be using inheritance when tight coupling is desirable.
I'd say you should always prefer composition. Any problem that can be solved with inheritance can be solved with composition. The inverse is not true.

It's usually cleaner to construct an object once via factory or parameters, and have data driven mutators as a public interface. Getters and setters are a relic of java's awful reflection-based libraries.
Plain-old-data-objects (aka structs) don't need getters and setters as the processing implementation can do the necessary locking locally.

An honest, meaningful answer? I thought I was on Jow Forums

But to extend on this, in my experience programming modular robots, OOP makes programmatical representations of real "stuff" easy. Small things like motors and sensors are objects; combined systems like a drive base can be objects containing the small stuff; the whole robot can be an object containing the combined systems. OOP is intuitive and useful for these bots

Thats nice, you are able to come up with one example where OO actually models real world objects. Problem is we live in a data/web centered world now and having to create a class and instantiate and object just to read in data from somewhere is needless bloat/verbosity/clutter

just write bytes to registers bro

Nothing. It's just difficult so often done terribly and then people blame it on the paradigm itself. Pretty much like C++.

People fuck it up and make a bunch of useless classes when everything could have been put under one. Basically it's a good paradigm to add a lot of shit code that is hard to traverse.

>It's just difficult so often done terribly and then people blame it on the paradigm itself.
OO in C++ is difficult because its a weak stopgap for not having a real module system. C++ has OO and a build system that dont know anything about eachother. And then it has to add namespaces on top of that because neither the OO nor the build system does real encapsulation

snake case is great. If you love all your variable names being longer than they need to be for no reason

What's better?
This:
void function() {
}
Or this:
void function()
{
}

Attached: ZeZP35F.jpg (2000x2668, 484K)

this C++ is just absolute garbage at the things it is supposed to be modern at.

Not user but sameline is the only way

>People fuck it up and make a bunch of useless classes when everything could have been put under one.
class MyEntireProgram{
// all variables, data structure, method definitions go here
//...
//...
//...
};

int main(){
MyEntireProgram my_program_instance;
my_program_instance.run_program();

return 0;
}
people actually do this

Attached: s_.jpg (795x595, 58K)

>you can put all the mutex bullshit in them
This doesn't help at all because you still have to know where they are because locks aren't composable.

this is actually true. I see this all the time in open source

API_Program* = new API_Program;
API_Program->Init();
API_Program->run();
API_Program->end();
free(API_Program);

Uhh no. C++'s OO does encapsulation pretty well as long as you stay away from static members. Friendship is better encapsulation than Java's package access right.

what if you had sub-programs?
class Program;
class MySubProgram1 extends Program;
class MySubProgram2 extends Program;
class MySubProgram3 extends Program;
class MyProgram extends Program{
private:
MySubProgram1 msp1;
....
}

Simply beautiful.

>why a built-in failure value is bad
Because it's not a failure value. It's exactly the same kind of thing as every good value but it crashes your program.
>Optional with exceptions is good
Optional is good because you make a distinction between good and possibly bad values on the type level. Exceptions aren't good but call them algebraic effects and we're good to go.

They are not bad from an OOP perspective, they are bad from a type safety perspective.

You can get around null entirely with a monadic option/maybe type. You can get around downcasting by not upcasting in the first place, and using generics instead of casting to a base class.

nothing
t. just another instance

this is what peak performant c++ looks like,
you may not like it,
but c++ doesn't get any better than this

So DI is a = f(b)? Well shit, that is a solid piece of science.

>creating a giant monolithic god class.
>good coding

pick one.

>not up casting in the first place
Do what? That's literally the point of interfaces.
>generics instead of casting
What do you think a generic is other than casting to the base type? Or are you talking about composure via generics, which is still interface casting?
Optional is only useful in languages with pattern matching, and even then can he accomplished in a safer way always since matching will always be able to match the root type.
Functional weinees plz go and stay go

harmful.cat-v.org/software/c /I_did_it_for_you_all

Literally harmful

literally what redux does. And there are legions of web devs using this shit.
Apparently state is so frowned upon by functional fags that you need to relegate it to a gheto file to not to contaminate the code.

>The fact that OOP proponents have collectively decided to pull a Steve Jobs and pretend they invented modularization and abstraction.
this is my biggest gripe with OOP
whenever I talk to anyone (even professors) about the merits of OOP all they ever talk about is the merits of abstraction and encapsulation as if a) that's even what OOP is in the first place and b) it can't be done in other paradigms

Length of variable names really doesn't matter in 2018. Can't your IDE autocomplete? (If not, ...)

ZERO COST ENCAPSULATIONS

>or video games
>taking data from Point A to Point B
actually, recently video games have taken more the latter approach with relational designs and "ECS"

Modern frameworks don't suffer from the problems you've pointed out, your personal projects might however.

>Acts the same way given the same arguments
totally not stateless guise

>t. Pajeet that never tests his code.