Talking about the PLO in the lounge - page 19

New comment
 

Volchanski, and you can also write yourself a chorus topic called "Do you need goto?"

 
Andrei:
Verilog

Well, that's quite a grip you've got there.) It's for designing electronic circuits.

 
o_o:

Volchansky, and write yourself another hullabaloo topic "Do you need goto?"


Am I correct in assuming you have negative feelings? Why is that?

 
Комбинатор:

What difference does it make?

You need to argue your claim (OOP sucks) - go to Google, type in "OOP" and a couple of negative qualities, take an article and without reading it, throw it on the forum.

True or not true - it doesn't matter. It doesn't matter if I am or am not. If there are attentive people like you who will bother to read and check it, we can throw another article in the same way.

I'm a beginner in OOP, so I admit with high probability that I haven't realized some serious disadvantage of OOP. I took this article as a top one because I thought it looked like a serious programming resource. Perhaps it's not so but I'm not a programmer either.

As a result, you should probably conduct a sociological (or psychological) study of why a part of society (an individual) develops an almost aggressive and persistent aversion to certain things.
 
George Merts:

Well, I'm not liked by chicks either... And many more... The usual thing, Alexey, they're all animals, not everyone manages to train them, so you'll have plenty of envious men.

But you'd better tell me - where's your course? I'll have a look too...


You don't need it, I sent it to you in person.

 
fxsaber:

A serious disadvantage of OOP is that something complex is difficult to design, i.e. it is very difficult to make an architecture that works well and fits together without crutches, so refactoring is very, very common. The less experience you have in design, the more hell you can make of it. The point is that in OOP the structure of a normally designed object model often has little in common with real objects (as we imagine them)

Then it depends on the support of certain paradigms by certain languages, so that we can talk about "good/bad", "applicable/unapplicable"

For example above mentioned gorilla with banana is not an OOP problem, it is a problem of mindless use of package managers without dependency tracking. Especially on the web these days

 
fxsaber:

The article lies!

When I read this statement, I became very doubtful. I quickly rolled it over to check that I wasn't messed up in the head:

I highlighted the lines that the author of the article suggests changing. The result is not affected by replacing them. I did not read the rest of the article. Most likely, it was pointed out to this nonsense of the author in the comments.


The article doesn't lie. There are virtual functions there, so it all works the way the author says.

But I hope you don't take it as a serious argument against OOP.

Changes in a base class can be as big as you want, and expecting them not to affect the work of derived classes is just silly.

 
Koldun Zloy:

The article does not lie. There are virtual functions there, so everything works the way the author writes.

But I hope you don't think this is a serious argument against OOP.

Changes to the base class can be as big as you like, and expecting them not to affect the work of derived classes is just silly.

If virtual, it makes sense and the author is simply incompetent in the issues and challenges of virtual functions.

Moreover, if he had to get independence, he should have done

virtual void Array::addAll( const int &elements[] )
{
  for (int i = 0; i < ArraySize(elements); i++)
//      this.a.add(elements[i]);
    Array:: add(elements[i]);
}
But I find the example a good one for beginners. You need to understand what you are doing.
 
Комбинатор:

A serious disadvantage of OOP is that something complex is difficult to design, i.e. it is very difficult to make an architecture that works well and fits together without crutches, so refactoring is very, very common. The less experience you have in design, the more hell you can make of it. The point is that in OOP the structure of a normally designed object model often has little in common with real objects (as we imagine them)

Then it depends on the support of certain paradigms by certain languages, so that we can talk about "good/bad", "applicable/inapplicable"

For example above mentioned gorilla with banana is not an OOP problem, it is a problem of mindless use of package managers without dependency tracking. Especially in the web these days.

Yes, I've encountered a few situations where the architecture was poorly chosen. Sometimes it was easier to rewrite from scratch rather than edit.

In procedural coding you can almost always make up the architecture of a program while writing the code. Because the freedom and flexibility are total, but the crapshoot is huge.

In OOP, on the other hand, it is advisable to write the entire architecture on the board BEFORE writing the first line of code. When you are ready, it is very easy to write the code. And if the architecture is successful (only experience and individual skills help here), it is just as easy to refine/extend, even if you have already forgotten all about the project.

 
Alexey Volchanskiy:

Well, that's quite a grip you've got there.) It's for designing electronic circuits.

Not only that.
1...121314151617181920212223
New comment