/prog/ - Programming

>>1911
>Hello /prog/, I need some advices about object oriented programming, why is it better than procedural?
>better

Different tools, different jobs, etc, etc, etc.


The basic principle of OOP is to make code more "modular" by coupling data structures with code to operate on them (so-called "objects").

What makes this special is that you don't have to understand the internals of an object in order to work with it - only the methods it exposes.

This gives you two advantages:
1.) You can arbitrarily change one part of the program without worrying about breaking anything else (often, you won't even have to recompile the rest of your code)

2.) You can write very generic code that works with lots of different kinds of objects


Of course, this is only true for well-designed OO code; if your design is shit, then you'll still have all of the problems that OOP is supposed to solve.



>but I can't let go the idea that procedural is more understandable, what can I do about it?
I find that drawing diagrams helps.

But the main thing is: keep practising.

>>1912
Pretty much this.

I'm still not fond of repackaging old shit to use again, but I had a prof that made us work with shitty classes to learn OOP. I'm a lot better with it now.

>>1911
>OOP is a fag?
No, you got that wrong, it spells "OP", not "OOP".

>>1919
Excellent example of what OO programmers call "Polymorphic Dispatch."

On the subject of OOP, could anyone recommend a fun project to work on that would be well suited to an OOP approach?

>>1946
A dungeon crawler or an RPG of some sort. To be fair, OOP gets a lot of shit but video games on their current form would be impossible to program without it.

Can you imagine something like Minecraft written in a imperative language?

>>1947
>would be impossible to program without it
Not even close. Literally any language of any paradigm can be used to write a video game.

I suspect the only reason OOP is so prominent in the gaming industry is because of C++.


>Can you imagine something like Minecraft written in a imperative language?
Minecraft is written in an imperative language.

See:
https://en.wikipedia.org/wiki/Java_%28programming_language%29
https://en.wikipedia.org/wiki/Imperative_programming

>>1911
As >>1912 said, OOP is good for designing interfaces which hide the details of implementation through encapsulation. The tight coupling between data and code makes each class self managing, in theory. Although OOP certainly has a place in software engineering, it is often misused and its ideology of "generic programming" taken to the extreme. Writing needlessly complex inheritance relationships only to "generalize" builds cruft around the core solution of the program. Instead of making your solution more general, make it more specific! Being able to assume how and why your code is used makes each instruction have a clear purpose, thereby giving way for optimization opportunities. By contrast, having to juggle between remembering what state each monolithic object was in is a big strain on the developer who is looking to decrease complexity, not add to it.
Take a look at Data Oriented Design: http://dataorienteddesign.com/dodmain/

>>1964
To quote http://pivotallabs.com/all-evidence-points-to-oop-being-bullshit/
>State is not your friend, state is your enemy. Changes to state make programs harder to reason about, harder to test and harder to debug. Stateful programs are harder to parallelize, and this is important in a world moving towards more units, more cores and more work. OOP languages encourage mutability, non determinism and complexity.

>>1965
>le state is evil maymay
Even the developers of Scala admit every program needs state to some extent to be useful. Without state you will only end up making an overcomplicated slow mess.

>>1966
Of course state is needed, but sometimes it can be represented in a more deterministic way. For example, consider this simulation code which updates dynamic objects:

for(each object) {
    if(object has the "need update" flag set) {
         obj.simulate(deltaTime);
    }
}

Obviously this is a trivial example, but if you had tens of thousands of these objects and many state flags, the cost of loading the cache with _potentially_useless_ information is extremely bad for performance. One potential solution could be to organise the objects which need an update at the end of the array, and simply loop over that range. This way, the state of the data ("need update" flag) is _assumed,_ and is not continually checked:

for(each "need update" object) {
    obj.simulate(deltaTime);
}

You get the point, of course

>>1976
True, but you still need sort your objects according to its "flag",Which is fine if only done occasionally but it is a lot worse if it needs to be done every update.


It is stupid to say "x is bad" since it depends on what you're trying to achieve. Even experienced programmers say this shit.

much OOP code is just useless bloaty layers of abstraction but if you use it properly or if you use well-written frameworks you'll see the beauty of it.

>>2015
Pretty much this.

It can be used well, but very few people actually do it. 90% of code I've seen is sadly bloaty shit - almost as if they don't know what they're doing. As such, I've just come to hate it.