Object Oriented Programming

Not even once.

Other urls found in this thread:

yegor256.com/2016/09/20/oop-without-classes.html
youtube.com/watch?v=RdE-d_EhzmA
yegor256.com/2014/09/16/getters-and-setters-are-evil.html
yegor256.com/2017/12/19/srp-is-hoax.html
yegor256.com/2017/12/12/alan-kay-was-wrong.html
number-none.com/blow/john_carmack_on_inlined_code.html
youtube.com/watch?v=s-hdZZzMCac&t=19m24s
yegor256.com/2015/02/26/composable-decorators.html
yegor256.com/2015/10/01/vertical-horizontal-decorating.html
twitter.com/NSFWRedditGif

How would this work in functional programming?

refuel(Car)
drive(Car)
fuel
maxspeed

So what's the difference?

inheritance was a mistake

There's no difference. All programming paradigms are the same.

I'm still wrapping my head around pointer OBJECTS

*maxSpeed

What's wrong?

t. lazy babyboomer who doesn't want to learn more efficient programming structures

What is in "Car"? What type is it?

>functional
That's a misnomer. Functional programming is anything but functional.

said ur mum

>getters
>setters
>utility methods
>allocation attributes
You're not doing object-oriented programming, you're only doing procedural programming. Just because the language you're using calls those things "objects", doesn't mean it's "object-oriented".

The difference is in removing layers.
We work directly onto the variables themselves and abandon the get/set functions.
And now that our drive and refuel functions are outside of the scope of a class, we can have them work on arrays of objects in the function rather than having each object call its own refuel function in a loop.

So we've reduced abstraction, removed the need for factories and we've improved the data locality for each function improving performance.

Those are the modern OO approaches taught in most languages. You don't need to bring up the philosophy of message sending to make a point.

I think, and I just started learning so please correct me if I'm wrong, that in OOP you have to work within classes, and can set them to interact or not with each other under the same specifications. Basically, I believe it to be a hierarchy system that allows for optimization of certain functions.

Classes have nothing to do with OOP.
yegor256.com/2016/09/20/oop-without-classes.html

> not using a coulder

can someone explain how you would do this in C please?

What are the drawbacks, or advantages lost from the original model?

struct car
{
unsigned char fuel_percent;
unsigned char max_speed;
}
void set_speed(struct car *foo, unsigned char spd);
unsigned char get_speed(struct car *foo);
unsigned char get_fuel(struct car *foo);
void refuel(struct car *foo, struct fuel_source *src);
void drive(struct car *foo);

struct fuel_source tank;
struct car civic;

if(get_fuel(&civic) < 15)
refuel(&civic, &tank);
else
drive(&civic);

Code tags: at least I tried :^)

see .

typdef struct Car {
unsigned int max_speed;
unsigned int fuel;
};

void refuel(Car *car);
void drive(Car *car);

Car Suzuki[MAX_SUZUKI] = {};

What is stop a new developer from directly assigning the speed from the struct somewhere in change_gears.c?

yep thanks
so basically like in C++ but just without the method outside the struct/class. I don't get why people say C is not object oriented when I see this.

The advantages lost are probably in Inheritance.
If you really wanted a derived class to never make direct changes to fuel without consulting your getFuel() function (which could contain some conditional) there's that.

But inheritance seems to bring more problems in than in aims to solve anyway.

C++ isn't object-oriented either.

That's exactly what we want. We want to REMOVE get_fuel and set_speed functions.

If a new developer could directly change a variable then they could also write a function to change it within the class scope given they had access to the source file.

So you want your team smart and in the know, not compartmentalized.

Code review. What kind of q is that?
I can see you are on your second programming class in college?
C is not called object-oriented because it is pretty agnostic in its design. C++ is called objecr-oriented because most of its features revolve around the OOP paradigm.

Without giving meme answers, why exactly is OOP bad?

>most of its features revolve around the OOP paradigm
That is not true. Stroustrup never aimed at making it object-oriented, he was just trying to make C developers more disciplined when he designed C++.

I believe people like lower level languages for more control and speed, but the reason why OOP languages were created was because you can only write so much code before you get lost in the clutter.

>"The OO design concept initially proved valuable in the design of graphics systems, graphical user interfaces, and certain kinds of simulation. To the surprise and gradual disillusionment of many, it has proven difficult to demonstrate significant benefits of OO outside those areas."
t. Eric S. Raymond

Abstraction hell and performance deprivation.

You really could write an entire book on it.

What happens when you get a bug to fix that the car sometimes accelerates very quickly and sometimes very slowly because the different functions that manage the speed sometimes have not properly calculated acceleration. I.e. some of the functions use friction and weight while other functions use horsepower etc.

Third class.
The sort of hell I've seen from some of my lecturers is beyond anything I thought was even possible.
Things like having a 5000 line codebase take 30 seconds to compile while wading through header file after header file after header file after header file for templated math functions and virtual base classes that all clash with functions parameters because their inheritance tree doesn't match the argument grinds your testicles to dust.

It forces you to do everything in a more convoluted and retarded fashion than necessary.

Wouldn't you then try to make it simpler by pushing everything speed related into a single function?

Your speed is only along various axis as the final output, why do we need more?

OOP is deprecated. It has been superseded by OODD:
youtube.com/watch?v=RdE-d_EhzmA

I thought we get an added security +2 per every set/get function used?

Doesn't it help us secure variables and such?

yegor256.com/2014/09/16/getters-and-setters-are-evil.html

Isn't that pretty much what oop is except being all speed related things it's all car related things.

No, OOP is about encapsulation.
yegor256.com/2017/12/19/srp-is-hoax.html

That function is gonna become more and more complex as your program grows. That is not modular.

No, OOP is about message passing.

yegor256.com/2017/12/12/alan-kay-was-wrong.html

Well that's the next problem: Monolithic Classes.

You see huge classes every now and then, some hundreds of lines long at best.
And the member variables are just placed wherever in the class declaration. The data isn't split accordingly to accommodate for memory architectures and access patterns.

And then you have the problem of passing these huge classes into functions. What happens when this 'function' is being called how many times in a loop and this temporary class is being copied over and over again?

There's also something about the implicit this pointer in some languages that does something to the layout of each class, but I can't remember what it is.

Classes are indeed a cancer, but if you have that problem it's your own damn fault for doing very poor design and architecture.

Just read Clean Code. OOP isn't the death of programming.

>we directly access the memory instead of having predefined secure methods of accessing them

>Let's say, we have a point and a canvas:
Point p = new Point(x, y);
Canvas canvas = new Canvas();
>This is how messaging would look:
p.printTo(canvas);

>p.printTo(canvas);
wot.

But it does ease the view of your control flow.
I think it makes it more modular, because if you have an issue with speed you know exactly where to go.

The idea that a function can't be 1000 lines long is silly and restricting.

Carmack talks about it somewhere here.
number-none.com/blow/john_carmack_on_inlined_code.html

car Car = new car();

Yeah I would have thought the most logical way would be
[Code]
canvas.addPoint(p)
//Other code whatever
canvas.print()
[/Code]
Neither options the other offers seem me a good way to do it

I had a stroke please excuse

C++ was a mistake. That alone doesn't mean OOP as a paradigm is garbage though.

But what are the majority of get/set functions anyway? And some of their implementations are hidden in libraries.

So I want to increment speed but now I'm going through some sort of base Vehicle class with a setSpeed() function.

If the source isn't hidden from me, I can see what it's doing. And if it's a trivial assignment, then I don't need the function.
Now what happens when I can't see inside the function? Now maybe there's a sort in there or something or a huge switch statement and it's fucking things up.

Is it easier to acquire apples passed through 5 different farms and cleaning and packaging places or just pick your own?

What's Clean Code about?

Well that's the thing, Carmack writes software that is hardly maintained. He writes video games, not enterprise software that is constantly changing. His requirements are different, his main concern is performance.

Listen to what David West says here between 19:24 and 22:00:
youtube.com/watch?v=s-hdZZzMCac&t=19m24s

So the OOP way of simplifying speed management is using encapsulation with composable decorators. The advantage is that this makes your software maintainable.

I really like OOP.
OP on the other hand, is a faggot

Basically a guide on how to write clean OO code. From Amazon:

" Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code."

Well then we have the next problem: Message Handling.

What handles the messages?
Who sends the messages?
What receives the messages?
Is there an interface between them?
How do you validate the actual messages?

>std::unique_ptr car = std::make_unique

>points can print themselves to a canvas
neato

I think the print method may instance a new pdfcanvasprinter or pngcanvasprinter class which implements ICanvasPrinter

and the validations would be in stuff like addPoint, etc. So whatever is stored in say canvas.points is already validated and the points are within the boundary of the canvas etc.

All software is maintained. Video games are enterprise software.
The requirements may be different, but not all that different. Writing a customer database and an MMO player database aren't that different. You tell me if people would use online banking if each onscreen transaction took 40+ seconds.

Encapsulation is the opposite of maintenance, it's the idea that either your team shouldn't know about this or your library users don't need to know about this or change this or even be able to.

How the idea that obscuring can lead to maintainability is paradoxical.

>All software is maintained.
Okay, but not to the same degree.

>Video games are enterprise software.
No, they're not. If you don't know the differences, we shouldn't be having this discussion.

>Writing a customer database and an MMO player database aren't that different.
They are. A lot.

>You tell me if people would use online banking if each onscreen transaction took 40+ seconds.
Why would they take so long?

>Encapsulation is the opposite of maintenance, it's the idea that either your team shouldn't know about this or your library users don't need to know about this or change this or even be able to.
That is 100% not true. Who said anything about what the team knows or doesn't know? You sound confused.

>How the idea that obscuring can lead to maintainability is paradoxical.
yegor256.com/2015/02/26/composable-decorators.html

Encapsulation is meant for the people who aren't maintaining the encapsulated parts of the software. When I'm working on a project that has 6-figure SLOC counts I don't want to get bogged down in the details. Think of encapsulation as an 'API'

Untrue. Not knowing the Nitty gritty of each method or function does not mean you are a bad developer. The whole point of naming conventions, docstrings and documentation is to offload having to learn all that upfront and just look for what you need when you need it.
Also this

This is retarded. What kind of fucking idiot thinks
final String[] parts = new String.Split( new String.UpperCased( new String.Trimmed("hello, world!") ) );

is better than
final String txt = "hello, world!"; final String[] parts = txt.trim().toUpperCase().split(" ");

>You tell me if people would use online banking if each onscreen transaction took 40+ seconds.
You tell me if developers wanna work in a codebase with millions of lines of code. They don't. So the people better wait 40 seconds if they have to (they don't, you're exaggerating). Going back to this video here , listen to what he says between 30:14 and 33:35. Design ALWAYS comes first and performance always comes LAST. And if you think otherwise, you are literally retarded. Period.
It is though. You're just butthurt because you're hearing that for the first time now and you can't admit you've been ignorant all along.

>food analogy
While it may be more efficient to simply access something, the point of OOP is really to make things easier and more organized as all methods that interact with a said class are defined within that class. (I know that improper or unneeded OOP is trash) Yes, maybe some implementation of a function is garbage or obscured but you could have that same problem in any programming language. Maybe I just like polymorphism and private methods, or Strings not being something I have to fucking handle (fuck C). I just feel OOP allows me to divide-and-conquer and take a top-down approach to things that I find much easier to do in a non-OOP language.

struct car
{
float fuel;
float maxspeed;
}

getFuelCar(struct car * thisCar)
setSpeedCar(struct car * thisCar, float speed)
float getSpeedCar(struct car * thisCar);
etc

It's all to the same degree. Things everywhere get rewritten and optimized and cleaned up and so on.
I don't know what constitutes enterprise software but I'm sure scale is one defining factor. Some studios are massive. Some of their codebases are millions of lines long.

Anyway the point is your level of encapsulation. We're back into the theory of what might work well.

This is awful.
final Text text = new AllCapsText(
new TrimmedText(
new PrintableText(
new TextInFile(new File("/tmp/a.txt"))
)
)
);
String content = text.read();
That's garbage and you know it.

So how much encapsulation is too much then?
What's the limit? What do you abstract and what do you leave out? Do you always do it?

Even just the simple idea of plain inheritance can mess with people regardless of whether the data hiding is explicit.
I've had it before to me where an inheritance hierarchy is four or five classes deep and another class constructor messed with another variable in another class after I inherited from it because that other one's base class was related to that one.

probably a struct containing fuel and maxspeed variables, i'd assume.

>inheritance
You're confusing things, user. There's nearly no inheritance in that code. And no one here is defending inheritance.

I bet you don't even understand that code you're attacking.

But you want the details. You want the details to be visible and understandable at best.

We were just talking about setters before and the example of having a sort being thrown into what you assume to be a simple increment.

Now the program suddenly is running twice as slow because someone thought that you couldn't handle the details.

Strange how most major software is written in OOP languages. I guess 90% of developers are idiots who can't comprehend the amazing power of functional programming.

Have you worked on large software projects? I don't think you would say things "I want the details" if you had.

Performance comes first. That's the real outcome. I would link performance to output as well, as a literal statement, what the program can perform.

Design is inherently a wrapper around performance because it's meant to facilitate the performance, output and ease of development.

The design is to facilitate the performance.You write things that are RAM friendly, CPU friendly, cache friendly.
Design for the sake of design is folly.

Yes my senior project was 500 lines of code, and it wasn't bloated with comments.

So why do you privatize your functions?

Don't see why OOPfags can't be like and write maintainable software without massive bloat

>And now that our drive and refuel functions are outside of the scope of a class
we have a big bowl of spaghetti with separate branches for petrol, diesel and LPG that needs to be modified every time a new engine is introduced and have to be maintained by a person that knows the inner workings of every single engine type. We removed abstraction at the cost of readability, testability, extensibility, and maintainability.

>"The thing that is going to matter long term is the design. The performance is gonna change next year when you get a new computer. So why spend of all this time optimizing for the computer that's gonna be obsolete in six weeks? But if you do your design right then it moves on to the new computer just fine. And yes, you have to do some work to re-optimize performance, but that's really small."
t. David West, a renowned software engineer with a PhD and published books

>"durr performance is the real outcome design is folly"
t. random anonymous user of an online Manchurian watercolour painting imageboard

Excuse me if I'd rather believe the former than the latter.

The kind of retard that likes OOP.
>500 lines of code
I've written longer programs than that and I am a sophmore. Saying that encapsulation is the problem with OOP is utterly absurd. Creating black boxes that nobody else has to understand the implementation details of is how software development has always worked.

>Appeal to expert authority
My training tells me that you have a weak argument

I literally just juxtaposed my argument (which is West's argument from the video) to your argument that you used to reply to mine. They can be seen side-by-side. Mine is sensible. Yours not only didn't address anything that was exposed in the video, it also doesn't make any sense. So stay frustrated.

But that's in your head.
It's just an integer, you're bringing a physical problem into a representative domain when the reality is that those conditionals would be no different in an OOP sense.

What we're trying to avoid by taking the functions outside of the class is to remove the need for constructors and calling that function through x number of classes.

So I'll see an implementation where 100 cars a created by a factory and thrown into a list.
So every one of those cars called its own constructor (inherited or not, virtual or not) and the list is kept in line by a smart pointer. Or you can even make the GC comparison.

So each car is reference counted, runs its OWN refuel function AND is in a list.
Everyone should be doing the opposite.

>Yes my senior project was 500 lines of code, and it wasn't bloated with comments.
>500 lines of code
>large

I'm gonna use smalltalk objects in this example, since they're the base of objects in most other languages.
A small talk object can do 3 things:
1.receive messages
2.send messages while processing a received message
3.store references to other objects
>What handles the messages?
The object that receives the message interprets it and can adjust it's references to other objects or send messages to itself(to access a different method) or other objects(to access their methods)
>Who sends the messages?
an objects sends a message.
code that isn't explicitly defined in an class is placed into a method in the kernel object which runs it. The kernel object can then send messages to other objects who can then send further messages
>What receives the messages?
other objects. You'd specify a message like target.send(:symbol,[payload...]), which would send a message to the object target, target would check to see if it has a method called symbol, and would use payload as it's arguments
>Is there an interface between them?
only as much as is outlined above
>How do you validate the actual messages?
if target does not exist, the symbol is not a valid method in target, or if the payload contains incorrect arguments you get various errors.

Structs and function pointers in C do everything you should ever need to do.

Real OOP is just forcing all functions to be single dispatch generic functions, which is by definition inferior to any language with multiple dispatch.

I don't think that's not a good argument at all from West.
You're always programming for the hardware.

Let's say your well designed program just stops working on next years CPU or GPU line.
Can you still call it well designed even though it doesn't work? Maybe.

But the point is there's no silver bullet. No catch all.
Deep optimization is different. Different story.

>And yes, you have to do some work to re-optimize performance, but that's really small

So already we have West going against his point. The Design is for the performance.

Just use composites, dumbass!
yegor256.com/2015/10/01/vertical-horizontal-decorating.html

If you really on your programming language to protect you, you're going to be disappointed.

If you rely on your fellow developer to follow the guidelines you are definitely going to be disappointed

>Let's say your well designed program just stops working on next years CPU or GPU line.
That's the whole point. If the design sucks, there's nothing you can do about it, because it's unmaintainable.
>So already we have West going against his point.
No, that only reinforces his point. Would you rather be forced to perform major surgery instead of small changes? No? Thought so.

If you rely on anything you're a moron.