마운드에서 OOP에 대해 이야기하기 - 페이지 19

[---]

Volchansky, 그리고 또 다른 holivar 테마 "내가 고토 가 필요합니까?"

[Alexey Volchanskiy]

Andrei :
베릴로그

글쎄, 당신은 그것을 잡았습니다)) 그는 또한 전자 회로 개발을위한 것입니다.

[Alexey Volchanskiy]

o_o :

Volchansky, 그리고 또 다른 holivar 테마 "내가 고토 가 필요합니까?"

당신이 부정적인 감정을 가지고 있다는 것을 올바르게 이해하고 있습니까? 왜요?

[fxsaber]

Комбинатор :

무슨 상관이야?

당신은 당신의 진술을 주장해야 합니다(OOP attoy) - Google에 가서 "OOP"와 몇 가지 부정적인 특성을 입력하고 대홍수와 같은 기사를 읽지 않고 포럼에 던집니다.

사실인지 아닌지는 중요하지 않습니다. 적용 여부는 중요하지 않습니다. 당신처럼 세심한 사람이 읽고 확인하는 것이 귀찮다면 다른 기사를 던질 수도 있습니다.

나는 OOP를 처음 접하기 때문에 OOP의 심각한 마이너스를 깨닫지 못했을 가능성이 높다는 것을 인정합니다. 그리고 그는 기사를 최상위 기사로 가져갔습니다. 왜냐하면. 나는 habr이 심각한 프로그래밍 리소스라고 생각했습니다. 그렇지 않을 수도 있지만 저는 프로그래머도 아닙니다.

결과적으로 어떤 이유로 사회의 일부(개인) 사이에서 안정적이고 거의 공격적이며 완고한 거부가 발생하는지에 대한 사회학적(또는 심리학적) 연구를 수행해야 할 것입니다.

[Alexey Volchanskiy]

George Merts :

그래서 여성들은 나를 좋아하지 않습니다 ... 그리고 더 많은 ... 일반적인 일입니다, Alexei, 그들은 모두 동물이며 모든 사람이 그들을 훈련시킬 수는 없으므로 많은 부러워하는 사람들이 있습니다.

그러나 당신은 더 나은 나에게 말해 - 당신의 코스는 어디입니까? 저도 한번 보겠습니다...

예, 당신은 그를 필요로하지 않습니다, 그는 개인에서 버렸습니다

[TheXpert]

fxsaber :

OOP의 심각한 마이너스는 복잡한 것이 설계 하기 어렵다는 것입니다. 완벽하게 효율적으로 작동하고 목발 없이 서로 잘 맞는 아키텍처를 만드는 것은 매우 어렵습니다. 그래서 실제 리팩토링의 관행은 매우 일반적입니다. 디자인 경험이 적을수록 더 많은 일을 할 수 있습니다. 사실은 OOP에서 정상적으로 설계된 객체 모델의 구조가 실제 객체와 거의 관련이 없다는 것입니다.

또한, 이미 특정 언어의 특정 패러다임 지원에 의존하므로 "좋음/나쁨", "적용 가능/적용 불가"에 대해 이야기할 수 있습니다.

예를 들어 위에서 언급한 바나나 고릴라는 OOP 문제가 아니라 종속성을 추적하지 않고 패키지 관리자를 무심코 사용하는 문제입니다. 특히 지금 웹상에서

[Koldun Zloy]

fxsaber :

기사 가 거짓말을 하고 있다!

이 말씀을 읽고 많은 의문이 들었습니다. 나는 내 머리가 지저분하지 않은지 확인하기 위해 재빨리 달려갔다.

나는 기사의 저자가 변경할 것을 제안한 라인을 강조 표시했습니다. 그들의 교체는 결과에 영향을 미치지 않습니다. 나는 그 기사를 더 이상 읽지 않았다. 아마도이 작성자의 넌센스는 댓글에서 즉시 지적되었을 것입니다.

기사는 거짓말을 하지 않습니다. 가상 기능이 있으므로 모든 것이 작성자가 작성하는 대로 작동합니다.

그러나 이것을 OOP에 대한 심각한 논쟁으로 보지 않기를 바랍니다.

기본 클래스에 대한 변경 사항은 원하는 만큼 커질 수 있으며 파생 클래스의 작동 방식에 영향을 미치지 않을 것으로 기대하는 것은 어리석은 일입니다.

[fxsaber]

Koldun Zloy :

기사는 거짓말을 하지 않습니다. 가상 기능이 있으므로 모든 것이 작성자가 작성하는 대로 작동합니다.

그러나 이것을 OOP에 대한 심각한 논쟁으로 보지 않기를 바랍니다.

기본 클래스에 대한 변경 사항은 원하는 만큼 커질 수 있으며 파생 클래스의 작동 방식에 영향을 미치지 않을 것으로 기대하는 것은 어리석은 일입니다.

가상이면 모든 것이 논리적이고 작성자는 가상 기능의 질문과 작업에 무능합니다.

게다가 독립을 해야 한다면 이렇게 해야 했다.

 virtual void Array::addAll( const int &elements[] )
{
   for ( int i = 0 ; i < ArraySize (elements); i++)
//      this.a.add(elements[i]);
     Array:: add(elements[i]);
}

그러나 초보자에게는 예제 자체가 좋다고 생각합니다. 당신이하고있는 일을 이해해야합니다.

[fxsaber]

Комбинатор :

OOP의 심각한 마이너스는 복잡한 것이 설계하기 어렵다는 것입니다. 완벽하게 효율적으로 작동하고 목발 없이 서로 잘 맞는 아키텍처를 만드는 것은 매우 어렵습니다. 그래서 실제 리팩토링의 관행은 매우 일반적입니다. 디자인 경험이 적을수록 더 많은 일을 할 수 있습니다. 사실은 OOP에서 정상적으로 설계된 객체 모델의 구조가 실제 객체와 거의 관련이 없다는 것입니다.

또한, 이미 특정 언어의 특정 패러다임 지원에 의존하므로 "좋음/나쁨", "적용 가능/적용 불가"에 대해 이야기할 수 있습니다.

예를 들어 위에서 언급한 바나나 고릴라는 OOP 문제가 아니라 종속성을 추적하지 않고 패키지 관리자를 무심코 사용하는 문제입니다. 특히 지금 웹상에서

예, 아키텍처가 성공적으로 선택되지 않은 상황을 여러 번 겪었습니다. 때로는 편집하는 것보다 처음부터 다시 작성하는 것이 더 쉬웠습니다.

절차적 코딩에서는 코드를 작성할 때 거의 항상 프로그램의 아키텍처에 대해 생각할 수 있습니다. 유연성과 자유로움은 완벽하지만 쓰레기는 거대하기 때문이다.

OOP에서는 보드에 코드의 첫 번째 줄을 작성하기 전에 전체 아키텍처를 그리는 것이 바람직합니다. 준비가 되면 코드가 매우 쉽게 작성됩니다. 글쎄요, 성공적인 아키텍처도 있다면(여기서는 경험과 개인 능력만 도움이 됩니다), 프로젝트 에 대해 모든 것을 이미 잊어버렸더라도 마찬가지로 쉽게 마무리/확장되고 있습니다.

[Andrei01]

Alexey Volchanskiy :

글쎄, 당신은 그것을 잡았습니다)) 그는 또한 전자 회로 개발을위한 것입니다.

뿐만 아니라.