아니요, 요점은 다릅니다. 프로그램의 논리에 따라 먹어야 하는 바나나가 있는데, 야자수와 검은 흙을 함께 거름 비료로 삼켜야 합니다.
음 ... 아니.
야자수, 검은 흙, 비료, 원숭이가 보이지 않습니다. 이 모든 것이 캡슐화되어 있으며 액세스할 수 없습니다.
같은 말에 대해! 이것은 기능적 접근 방식일 뿐입니다. 바나나를 얻으려면 이 모든 것을 분명히 끌어야 합니다. OOP에서는 컴파일러가 알아서 해줍니다. 당신은 - 합의된 인터페이스를 통해 "바나나"를 얻었지만 그것이 어디서 왔는지는 모릅니다. 적절한 액세스 권한이 있는지 확인할 수 있습니다.
같은 방식으로 OOP 칩(필요한 것만 사용할 수 있어야 함)이 이 경우 바나나입니다. 야자비료 원숭이는 없습니다. 할 수 없습니다. 그것들은 존재하지만(그렇지 않으면 바나나는 어디에서 왔는지), 이에 대한 액세스 권한이 없으며 모든 열망으로 실수로 야자수를 자르거나 눈물을 흘리는 바로 그 원숭이를 죽일 수 없습니다. 당신을 위한 바나나.
나는 이 두 기사의 저자들이 평생 동안 자신의 일을 해온 사람들에 대해 깊은 불행을 느끼고 있다고 생각합니다. 따라서 불행히도 종종 발생합니다. 그들은 프로그래머가 아니라 작가가 되어야 했습니다. 그들이 PLO에 대한 공격을 통해 사랑받지 못하는 대의에 대한 증오를 표명 한 것은 분명합니다. 아마도 그것들은 순전히 인간적으로 이해될 수 있을 것입니다. :)) 결국, 그들의 기술과 사랑에 빠진 진정한 프로그래머만이 OOP 패러다임을 진정으로 이해할 수 있습니다.
Nikolai Semko : 결국 자신의 기술과 사랑에 빠진 진정한 프로그래머만이 OOP 패러다임을 진정으로 이해할 수 있습니다.
필요하지 않습니다.
이전 페이지에서 Renat는 "그를 실제 프로젝트 에 투입"한다고 아주 올바르게 언급했습니다. 그는 그것을 채울 것입니다. 그리고 그는 모든 단점을 보상하는 것 이상의 OOP의 모든 장점을 빨리 확신하게 될 것입니다. 나는 여기 OOP의 비평가 중 누구도 다소 복잡한 프로젝트를 작성하는 데 관여하지 않았다고 장담합니다. 그들의 의견을 설명하는 것은 무엇입니까?
"자동차는 오버헤드 자원이 많이 필요하고, 피할 수 없고, 이 고철 더미를 끊임없이 휴대해야 하므로 도보로 걷는 것이 훨씬 정확합니다." 그리고 실제로, 다음 거리로 가는 것은 오히려 어리석은 일입니다. 그러나 다른 도시로 이동해야 하는 경우 "걷기"에 대해 진지하게 이야기하는 사람은 거의 없습니다.
이전 페이지의 Renat는 "그를 실제 프로젝트에 투입"한다고 아주 올바르게 언급했습니다. 그는 그것을 채울 것입니다. 그리고 그는 모든 단점을 보상하는 것 이상의 OOP의 모든 장점을 빨리 확신하게 될 것입니다. 나는 여기 OOP의 비평가 중 누구도 다소 복잡한 프로젝트를 작성하는 데 관여하지 않았다고 장담합니다. 그들의 의견을 설명하는 것은 무엇입니까?
"자동차는 오버헤드 자원이 많이 필요하고, 피할 수 없고, 이 고철 더미를 끊임없이 휴대해야 하므로 도보로 걷는 것이 훨씬 정확합니다." 그리고 실제로, 다음 거리로 가는 것은 오히려 어리석은 일입니다. 그러나 다른 도시로 이동해야 하는 경우 "걷기"에 대해 진지하게 이야기하는 사람은 거의 없습니다.
삼촌은 대부분의 학문적 환경과 마찬가지로 이론가이자 발라볼입니다. 그리고 그가 교수(제목이 부풀려진 지 오래다)이자 책의 저자인 것은 중요하지 않습니다.
이 뒤죽박죽 엉뚱한 말은 오랫동안 존재해 왔으며 소프트웨어 제품의 복잡성이 기하급수적으로 증가하는 것을 완전히 무시합니다. 30-20-10년 전에 일어난 일은 현재 프로젝트의 규모와 복잡성과 결코 비교할 수 없습니다. 그리고 그들은 여전히 샌드박스에서 노는 것을 선호하여 모델로 축소합니다.
그를 심어 자원, 경제 및 경쟁력있는 요구 사항을 포함하여 많은 요구 사항이 있는 실제 제품을 만들 수 있습니다. 그는 즉시 자신의 추론과 병합하여 가능한 모든 것을 실패합니다. 오히려 해법을 찾는 단계에서 어린이 주장 자리에서 쫓겨나기도 한다.
세계는 수많은 은탄을 시도했지만 모두 사용할 수 없는 것으로 밝혀져 오랫동안 폐기되었습니다. 복잡성이 지속적으로 증가하고 라이브러리(및 oop가 있음) 및 프레임워크(및 oop가 있음)가 계속해서 증가하므로 어떻게든 복잡성을 제어할 수 있습니다.
그리고 복잡성의 증가에서 벗어날 수 없습니다. 지식의 질에 대한 요구 사항을 따라갈 수없는 문맹 개발자는 훨씬 더 어려울 것입니다.
점점 낮아지고 있는 프로그래머의 수준에 맞추기 위해 더 간단한 언어를 만들려는 시도가 더 많이 있을 것입니다. 점점 더 많은 소프트웨어 회사가 단순히 잘못된 기술을 믿고 경쟁에서 지고 아무것도 없는 자신을 발견하게 될 것입니다. 그들의 경쟁자들은 제품 결과의 관점에서 더 무겁지만 더 효율적인 기술을 사용할 것입니다.
오랫동안 소프트웨어 회사에 대한 투자는 치명적인 일이었습니다. 사망률과 실패는 놀랍고 더 나빠질 것입니다.
왜요? 예, 이것은 기술자가 아닌 경제적 요구 사항이 많은 비즈니스이기 때문입니다. 라이브 및 상설 소프트웨어 회사의 80%는 마케팅 및 영업으로 구성됩니다. 그리고 잘못 선택된 기술(여기서는 대다수가 단순성보다 우선권을 가짐)은 후속 판매를 쉽게 죽입니다. 결승에서 더 열심히 달려서 더 좋은 결과를 얻은 선수들이 항상 있기 때문이다.
이제 최대 수십만 라인의 마이크로 프로젝트에 대해 설명합니다. 이것은 한 사람의 머리에 맞고 그에게 통제의 환상을 유지할 수있는 기회가 있기 때문에 무엇이든 할 수 있습니다. 확장을 시도할 때 - 고통, 실망 및 죽음.
결과:
프로젝트의 복잡성이 증가하고 있으며 계속 증가할 것입니다.
많은 새로운 아이디어와 접근 방식이 결과를 제공하지 않고 죽을 것입니다.
소프트웨어의 대부분은 작성되었으며 oop, hard 및 고뇌로 작성됩니다.
소프트웨어 스타트업에 대한 투자는 실패 비율이 증가할 것입니다. 교수가 할 일이 없는 사업이다.
알고리즘 거래에서 언어와 플랫폼에 관계없이 하나의 거래 플랫폼 내에서 대규모 프로젝트 는 없었고 앞으로도 없을 것입니다.
최대 - 반자동.
모든 언어로 된 반자동 장치 형태의 하나 이상의 큰 프로젝트? 가장 어려운 것은 스캘핑 드라이브입니다. 그러나 그들은 결코 거대하지 않았습니다. 그리고 대중적인 성격이 없다면 왜 큰 것을 귀찮게합니까? 시장에서 무언가를 수집하는 것이 한 쪽 무릎을 꿇는 것이 더 쉽습니다.
호전적인 무지 - 얼마나 정확하고 유능한가. 제 사전에 추가하겠습니다. :))
아니요, 요점은 다릅니다. 프로그램의 논리에 따라 먹어야 하는 바나나가 있는데, 야자수와 검은 흙을 함께 거름 비료로 삼켜야 합니다.
음 ... 아니.
야자수, 검은 흙, 비료, 원숭이가 보이지 않습니다. 이 모든 것이 캡슐화되어 있으며 액세스할 수 없습니다.
같은 말에 대해! 이것은 기능적 접근 방식일 뿐입니다. 바나나를 얻으려면 이 모든 것을 분명히 끌어야 합니다. OOP에서는 컴파일러가 알아서 해줍니다. 당신은 - 합의된 인터페이스를 통해 "바나나"를 얻었지만 그것이 어디서 왔는지는 모릅니다. 적절한 액세스 권한이 있는지 확인할 수 있습니다.
같은 방식으로 OOP 칩(필요한 것만 사용할 수 있어야 함)이 이 경우 바나나입니다. 야자비료 원숭이는 없습니다. 할 수 없습니다. 그것들은 존재하지만(그렇지 않으면 바나나는 어디에서 왔는지), 이에 대한 액세스 권한이 없으며 모든 열망으로 실수로 야자수를 자르거나 눈물을 흘리는 바로 그 원숭이를 죽일 수 없습니다. 당신을 위한 바나나.
평범한 사람들에게 괴로움은 마조히스트들에게 기쁨이다.. :)
OOP는 고유한 규칙이 있는 집이라고 상상할 수 있습니다. 누구에게나 공통적인 것이 있습니다. 이것들은 테이블 의자, 포크, 스푼 등입니다. 하지만 이 집의 주민들도 구할 수 없는 것들이 있습니다. 예를 들어 개인 물품, 금고 등이 있습니다.
금고의 소유자는 이 금고에 대한 액세스 권한을 부여할 수 있습니다. 낯선 사람은 허락 없이 이 집에 들어갈 권리가 없습니다.
학급의 도움으로 이 집에 대해 설명할 수 있습니다. 각각의 특정 기능 과 함께 그 안에 무엇이 있는지 설명할 수 있습니다. 그리고 집 자체가 오브제입니다.
OOP는 우리의 삶과 같습니다. 그것은 사람처럼 보이며 두 부분으로 구성됩니다. 그것을 설명하고 통제하는 영혼과 대상인 육체입니다.
OOP는 무정부 상태가 아니라 원하는 대로 하는 규율입니다.
결국 자신의 기술과 사랑에 빠진 진정한 프로그래머만이 OOP 패러다임을 진정으로 이해할 수 있습니다.
필요하지 않습니다.
이전 페이지에서 Renat는 "그를 실제 프로젝트 에 투입"한다고 아주 올바르게 언급했습니다. 그는 그것을 채울 것입니다. 그리고 그는 모든 단점을 보상하는 것 이상의 OOP의 모든 장점을 빨리 확신하게 될 것입니다. 나는 여기 OOP의 비평가 중 누구도 다소 복잡한 프로젝트를 작성하는 데 관여하지 않았다고 장담합니다. 그들의 의견을 설명하는 것은 무엇입니까?
"자동차는 오버헤드 자원이 많이 필요하고, 피할 수 없고, 이 고철 더미를 끊임없이 휴대해야 하므로 도보로 걷는 것이 훨씬 정확합니다." 그리고 실제로, 다음 거리로 가는 것은 오히려 어리석은 일입니다. 그러나 다른 도시로 이동해야 하는 경우 "걷기"에 대해 진지하게 이야기하는 사람은 거의 없습니다.
그래서 여기도.
필요하지 않습니다.
이전 페이지의 Renat는 "그를 실제 프로젝트에 투입"한다고 아주 올바르게 언급했습니다. 그는 그것을 채울 것입니다. 그리고 그는 모든 단점을 보상하는 것 이상의 OOP의 모든 장점을 빨리 확신하게 될 것입니다. 나는 여기 OOP의 비평가 중 누구도 다소 복잡한 프로젝트를 작성하는 데 관여하지 않았다고 장담합니다. 그들의 의견을 설명하는 것은 무엇입니까?
"자동차는 오버헤드 자원이 많이 필요하고, 피할 수 없고, 이 고철 더미를 끊임없이 휴대해야 하므로 도보로 걷는 것이 훨씬 정확합니다." 그리고 실제로, 다음 거리로 가는 것은 오히려 어리석은 일입니다. 그러나 다른 도시로 이동해야 하는 경우 "걷기"에 대해 진지하게 이야기하는 사람은 거의 없습니다.
그래서 여기도.
이제 최대 수십만 라인의 마이크로 프로젝트 에 대해 설명합니다. 이것은 한 사람의 머리에 맞고 그에게 통제의 환상을 유지할 수있는 기회가 있기 때문에 무엇이든 할 수 있습니다. 확장하려고 할 때 - 고통, 실망 및 죽음.
OOP가 없는 10K 라인 의 프로젝트도 상상하기 어렵습니다. 아마 그들 중 소수가있을 것입니다.
삼촌은 대부분의 학문적 환경과 마찬가지로 이론가이자 발라볼입니다. 그리고 그가 교수(제목이 부풀려진 지 오래다)이자 책의 저자인 것은 중요하지 않습니다.
이 뒤죽박죽 엉뚱한 말은 오랫동안 존재해 왔으며 소프트웨어 제품의 복잡성이 기하급수적으로 증가하는 것을 완전히 무시합니다. 30-20-10년 전에 일어난 일은 현재 프로젝트의 규모와 복잡성과 결코 비교할 수 없습니다. 그리고 그들은 여전히 샌드박스에서 노는 것을 선호하여 모델로 축소합니다.
그를 심어 자원, 경제 및 경쟁력있는 요구 사항을 포함하여 많은 요구 사항이 있는 실제 제품을 만들 수 있습니다. 그는 즉시 자신의 추론과 병합하여 가능한 모든 것을 실패합니다. 오히려 해법을 찾는 단계에서 어린이 주장 자리에서 쫓겨나기도 한다.
세계는 수많은 은탄을 시도했지만 모두 사용할 수 없는 것으로 밝혀져 오랫동안 폐기되었습니다. 복잡성이 지속적으로 증가하고 라이브러리(및 oop가 있음) 및 프레임워크(및 oop가 있음)가 계속해서 증가하므로 어떻게든 복잡성을 제어할 수 있습니다.
그리고 복잡성의 증가에서 벗어날 수 없습니다. 지식의 질에 대한 요구 사항을 따라갈 수없는 문맹 개발자는 훨씬 더 어려울 것입니다.
점점 낮아지고 있는 프로그래머의 수준에 맞추기 위해 더 간단한 언어를 만들려는 시도가 더 많이 있을 것입니다. 점점 더 많은 소프트웨어 회사가 단순히 잘못된 기술을 믿고 경쟁에서 지고 아무것도 없는 자신을 발견하게 될 것입니다. 그들의 경쟁자들은 제품 결과의 관점에서 더 무겁지만 더 효율적인 기술을 사용할 것입니다.
오랫동안 소프트웨어 회사에 대한 투자는 치명적인 일이었습니다. 사망률과 실패는 놀랍고 더 나빠질 것입니다.
왜요? 예, 이것은 기술자가 아닌 경제적 요구 사항이 많은 비즈니스이기 때문입니다. 라이브 및 상설 소프트웨어 회사의 80%는 마케팅 및 영업으로 구성됩니다. 그리고 잘못 선택된 기술(여기서는 대다수가 단순성보다 우선권을 가짐)은 후속 판매를 쉽게 죽입니다. 결승에서 더 열심히 달려서 더 좋은 결과를 얻은 선수들이 항상 있기 때문이다.
이제 최대 수십만 라인의 마이크로 프로젝트에 대해 설명합니다. 이것은 한 사람의 머리에 맞고 그에게 통제의 환상을 유지할 수있는 기회가 있기 때문에 무엇이든 할 수 있습니다. 확장을 시도할 때 - 고통, 실망 및 죽음.
결과:
이 모든 것이 말로만 좋고 아름답습니다 ....
OOP에서 크고 흥미로운 프로젝트 를 만들려면 이 작업을 수행할 수 있어야 합니다.
1 - 여기 ML에 가지 않는 방법을 아는 사람, 언어는 몇 가지 플랫폼으로 제한되며 이미 비즈니스에 있는 전문가(이미 다른 언어로 된 프로젝트가 있음)입니다...
2 - 그리고 방법을 모르는 사람들은 OOP와 원숭이 같은 다른 것들을 비틀고 아무것도 낳지 않을 것입니다..
네, 물론 금융시장을 좋아하는 팬도 몇 명 있긴 하지만, 진지한 일을 하고 이것으로 생계를 꾸리기에는 너무 적습니다... 주요 관심사는...
나 뭐야 레나트 5산 10년이 다되가 10년이 장난아님..
그리고 OOP에서 프로그래밍에 대한 합리적인 교육이 없습니다 ...
내가 쓴 주제는 무엇입니까? OOP에 대해 그리고 그것은 무엇에 빠졌습니까? 독감까지...
Renat에 대한 질문입니다. µl에 대한 대규모 프로젝트를 프로그래밍하는 사람들은 어디서 어떻게 해야 합니까???
µl당 큰 프로젝트를 프로그래밍하는 사람들은 어떻게 또는 어디에서 왔는지???
알고리즘 거래에서 언어와 플랫폼에 관계없이 하나의 거래 플랫폼 내에서 대규모 프로젝트 는 없었고 앞으로도 없을 것입니다.
최대 - 반자동.
모든 언어로 된 반자동 장치 형태의 하나 이상의 큰 프로젝트? 가장 어려운 것은 스캘핑 드라이브입니다. 그러나 그들은 결코 거대하지 않았습니다. 그리고 대중적인 성격이 없다면 왜 큰 것을 귀찮게합니까? 시장에서 무언가를 수집하는 것이 한 쪽 무릎을 꿇는 것이 더 쉽습니다.