Questions on OOP in MQL5 - page 56

New comment
 
Aleksey Mavrin:

You've already told me so many times that I'm a fool and don't understand anything, that I'm proud of my composure, that I haven't sent you a well-deserved fuck)

Basically - a nested class makes public methods for private fields optional, that's the encapsulation violation you're writing about. Any other arguments?

You demonstrate your stupidity so steadily that I'd rather send you there deservedly.

A nested class doesn't do what you write about it. And the task of the Guardian pattern can be solved without a nested class and unnecessary public methods.

Let me remind you: here is an example with a nested class and public methods.

 
Dmitry Fedoseev:

You demonstrate your stupidity so steadily that I'd rather send you there deservedly.

A nested class does not do what you write about it. And the Guardian pattern problem can be solved without a nested class and without unnecessary public methods.

Let's figure out who goes in the end))

What doesn't a nested class do?

You wrote that "encapsulation is broken because public methods are created for private fields".

A nested class has access to private fields without requiring public methods to be created.

s.s. You're a regular here judging by the ranking. But you have to learn how to communicate and dialog. But you don't need that in your life.

 
Aleksey Mavrin:

Let's work out who goes in the end.)

What doesn't the nested class do?

You wrote that "encapsulation is broken because public methods are created for private fields".

A nested class has access to private fields without requiring public methods to be created.

s.s. You're a regular here judging by the ranking. But you have to learn how to communicate and dialog. But you do not need it in life.

Let me remind: here is an example with a nested class and public methods (i.e. the nested class didn't help to get rid of the need to create public methods at all).

The nested class is just a matter of class visibility, not object visibility. The nested class, merely, does not allow to create an object of this class, outside of the class in which it is described. Therefore, you will have to go.

 
Aleksey Mavrin:

Exactly - the right structure. For this purpose, it is worth considering all possible variants of this very structure, analyze their pros and cons in a given task (taking into account the requirements of extensibility and maintenance, etc.) and choose the best one.

And the notorious patterns themselves (whatever exactly they are meant to be) are not even a variant of the structure here but just a reference point for the brain. It's like "If the problem fits the description of the problem of pattern X, it means it can be solved by applying pattern X", but you can also solve it in a heap of other ways.

And in general, those 27 basic patterns were born as a kind of hint for programmers on typical problems how to solve them following the OOP principles. If there is no task to follow the principles, as Dmitry has with structures, no patterns are needed.

Thank you, good post

You are different from the rest of the panel ;)

 
Dmitry Fedoseev:

Let me remind you: here is an example with a nested class and public methods (i.e. the nested class didn't help get rid of the need to create public methods at all).

A nested class is just a matter of class visibility, not object visibility. The nested class, merely , does not allow to create an object of this class, outside of the class in which it is described. So you have to go.

No )) stupidity )) A nested class has access to ALL PRIVATE fields of the class it is nested in. (You don't know that? Well, there's nothing to talk about.

And that's not counting the nonsense that you wrote that the entire object must be copied for the Shot...)) It turns out ... won't mind if you don't come back soon))

 
Igor Makanu:

Thanks, good post.

You're different from the rest of the discussion ;)

Igor, thank you too, and on a kind word) and that you create interesting topics for constructive mutual discussion ;)

 
Aleksey Mavrin:

No )) it's nonsense )) A nested class has access to ALL PRIVATE fields of the class it is nested in. (You don't know that? Then there's nothing to talk about.

And that's not counting the nonsense that you wrote that the entire object must be copied for the Shot...)) It turns out ... won't mind if you don't come back soon))

And what do you call a nested class?

I didn't write anything about Snapshot here at all.

  
class C1{
   protected:
      int x;
      class C2{
         protected:
         public:
         C2(){
            x=1;
         }
      };      
   public:
};

Where is the access to x from C2?

Again, a nested class is only a matter of class visibility to create an object. An object of class C2 can only be created inside class C1. That's it. That's the only difference from writing a type:

class C1{
   protected:
      int x;
   public:
};

class C2{
   protected:
   public:
   C2(){
      x=1;
   }
};


But surely you call something else a nested class? Tell us what.

 
ahah )
 
TheXpert:
ahah )

You didn't know either?

1...495051525354555657585960616263...96
New comment