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

 
Alexey Volchanskiy :

선구적인 코딱지 없이 명확하게 질문에 답변

1. 개인적으로 어떤 병렬화 기술을 사용하셨습니까? 일반적인 삐걱 거리는 소리가 아니라 기술 및 언어의 특정 이름입니다.

1.1 OOP 버전이 어디에서 실패했습니까?

----------

추신: 하루 이상 OOP 과정을 진행했는데 진행자가 이 시간 동안 10명을 차단하고 약 200개의 어리석은 게시물을 문질렀다고 썼습니다! 그는 여기에서 40-50명의 사람들이 동시에 영구적으로 당신을 읽고 있으며, 그 주제가 필요하다고 말합니다. 메뉴를 만들어야 합니다. 언제든지 도와드리겠습니다.

베릴로그
 
George Merts :

OOP 접근 방식 - 사람은 개발을 단순화해야 하며 가장 중요한 것은 시스템 지원입니다.

"OO 언어의 문제는 그들이 전체 환경을 그들과 함께 끌고 간다는 것입니다. 당신은 단지 바나나를 원했지만 결과는 그 바나나와 모든 정글을 들고 부팅하는 고릴라 입니다."

Прощай, объектно-ориентированное программирование
Прощай, объектно-ориентированное программирование
  • 2005.08.16
  • habrahabr.ru
Я в течение десятилетий программировал на объектно-ориентированных языках. Первым из них стал С++, затем был Smalltalk, и наконец .NET и Java. Я фанатично использовал преимущества наследования, инкапсуляции и полиморфизма, этих трёх столпов парадигмы объектно-ориентированного программирования. Мне очень хотелось воспользоваться обещанным...
 
Andrei :

"OO 언어의 문제는 그들이 전체 환경을 그들과 함께 끌고 간다는 것입니다. 당신은 단지 바나나를 원했지만 결과는 그 바나나와 모든 정글을 들고 부팅하는 고릴라 입니다."

괜찮은. 좋은 비유!

그냥 문제인가요? 그 반대, OOP의 장점!

"그냥 바나나"이기 때문에 발생하지 않습니다. 바나나의 경우 - 야자수가 있어야 하고, 야자수의 경우 - 영양 배지가 필요하며, 그런데 이 야자수를 타고 이 바나나를 얻을 고릴라가 필요합니다.

내 생각에는 아무 생각도 안 하고 이 바나나를 가지고 먹어서 참 좋은 것 같다.

추신

기사를 읽었습니다. 모든 것이 올바르게 설명되어 있지만 이러한 모든 주장이 저에게 확신을 줍니다. OOP는 FP보다 훨씬 우수한 우수한 기술입니다. 단지 그것을 사용할 때 AF에서 따를 필요가 없는 몇 가지 규칙을 따라야 한다는 것입니다. 그러나 이것이 OOP를 포기할 이유가 전혀 아닙니다. 제 생각에는 기사의 모든 주장 - 정반대로 OOP의 장점을 증명하고 "칼 사용 - 조심해야 함을 기억하십시오"라고 경고합니다.

기계 제품 대신 전기 제품을 사용하는 것 - 이전에는 필요하지 않은 몇 가지 규칙도 따릅니다 - 이것이 사실입니다. 그러나 이것이 가전 제품을 포기할 이유는 아닙니다!

 

대화는 나에게 한 시리즈의 한 장면을 생각나게 합니다.

--------------------------------------

전 아내는 전 남편을 회의에 호출합니다.

BJ: 우리 딸이 임신했다고 상상할 수 있니! 그리고 그녀는 겨우 19살이고 대학에 입학하려면 공부해야 합니다!!!

비엠: 무슨 소리야!!! 그리고 누구에게서 알려지지 않았습니까?

BJ: 왜 알려지지 않았습니까? 그것은 알려져 있습니다 ... 오, 무엇이 될 것인가, 무엇이 될 것인가 ...

BM: 이 악당이 숨어서 아이를 알아보지 못하는 겁니까?

BJ: 아니요, 그는 숨어 있지 않습니다. 그리고 상상할 수 있습니까, 우리 딸이 그와 결혼할 것입니다!!! 이제 어떻게해야합니까, 그녀는 방금 학교를 마쳤습니다 !!!

비엠: .... ???

BZ: 글쎄, 왜 침묵해, 왜 침묵해!!! 이해하지 못합니까 ?!!! 우리딸 임신!!! 그리고 결혼!!! 이해하다 ?!!!

BM: 어... 알겠습니다... 하지만... 문제가 있는 것 같지는 않습니다... 당신은 임신을 하고 18세에 나와 결혼하고 그녀를 낳았습니다... 그리고 끔찍한 일은 일어나지 않았습니다...

--------------------------------------

그래서 여기에 있습니다-그들은 OOP의 거대한 단점과 문제를 나에게 증명합니다. 나는 문제를 고려하지 않고 오히려 장점을 고려합니다 ...

칼을 조심하는 것이 단점이고 OOP의 단점이 장점보다 크다는 것을 알 수 있는데 어떻게 그러한 깨달음에 이를 수 있겠습니까?

 

그건 그렇고, 이것은 "선진"국가의 인구 통계 학적 상황에 대한 이유 중 하나입니다. 먼저 배우지 않고 삶을 정리하고 모기지를 갚고 .. 아무도 만지지 않는 경우 어떤 어린이에게도 관심이 없습니다.

 
George Merts :

"그냥 바나나"이기 때문에 발생하지 않습니다. 바나나의 경우 - 야자수가 있어야 하고, 야자수의 경우 - 영양 배지가 필요하며, 그런데 이 야자수를 타고 이 바나나를 얻을 고릴라가 필요합니다.

내 생각에는 아무 생각도 안 하고 이 바나나를 가지고 먹어서 참 좋은 것 같다.

아니요, 요점은 다릅니다. 프로그램의 논리에 따라 꼭 먹어야 하는 바나나가 있는데, 야자수와 검은 흙을 함께 거름 비료로 삼켜야 합니다.

 
Andrei :

"OO 언어의 문제는 그들이 전체 환경을 그들과 함께 끌고 간다는 것입니다. 당신은 단지 바나나를 원했지만 결과는 그 바나나와 모든 정글을 들고 부팅하는 고릴라 입니다."

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

기본 클래스의 소유자는 명시된 대로 작동합니다. 그리고 모든 자동 테스트를 통과합니다. 그러나 소유자는 파생 클래스에 주의를 기울이지 않습니다. 그리고 파생 클래스의 소유자는 매우 실망했습니다. 이제 ArrayCount 의 addAll() 은 부모의 addAll() 을 호출합니다. 이 addAll() 은 이미 파생 클래스에 의해 보류된 add() 내부적으로 호출합니다 . 결과는 파생 클래스의 add()가 호출될 때마다 카운터가 증가 하고 파생 클래스의 addAll() 에 의해 추가된 요소 수만큼 다시 증가 한다는 것입니다. 즉, 요소는 두 번 계산됩니다 .

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

 class ArrayList
{
public :
   void add( int )
  {
     Print ( __FUNCSIG__ );
  }  
};

class Array
{
private :
  ArrayList a;

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

class ArrayCount : public Array
{
public :
   int count;

  ArrayCount() : count( 0 )
  {
  }

   void add( int element )
  {
    Array::add(element);
    
    ++ this .count;
  }
    
   void addAll( const int &elements[] )
  {
    Array::addAll(elements);
    count += ArraySize (elements);
  }
};

void OnStart ()
{  
   int Tmp[ 5 ];
 
  ArrayCount Count;
 
  Count.addAll(Tmp);
   Print (Count.count);
}

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

Прощай, объектно-ориентированное программирование
Прощай, объектно-ориентированное программирование
  • 2005.08.16
  • habrahabr.ru
Я в течение десятилетий программировал на объектно-ориентированных языках. Первым из них стал С++, затем был Smalltalk, и наконец .NET и Java. Я фанатично использовал преимущества наследования, инкапсуляции и полиморфизма, этих трёх столпов парадигмы объектно-ориентированного программирования. Мне очень хотелось воспользоваться обещанным...
 
George Merts :

괜찮은. 좋은 비유!

그냥 문제인가요? 그 반대, OOP의 장점!

평범한 사람들에게 괴로움은 마조히스트들에게 기쁨이다.. :)

 
fxsaber :

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

무슨 상관이야?

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

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

 
Я — функциональщик. Прекрасно себя чувствую. Это ты от ООП такой раздражительный.