OOP 대 절차 프로그래밍 - 페이지 21

 
Реter Konow :

사용자가 외부 테이블에서 후행을 활성화한다고 말했습니다. 따라서 하나의 후행만 포함할 수 있습니다. 그런 다음 if 대신 switch를 사용할 수 있습니다.


그리고 누가 그것을 읽을까요? 여기서 뭐해?

 
Реter Konow :

따라서 결정의 메커니즘을 설명하십시오. 구체적으로 기술했습니다. 그리고 이해할 수 없는 사실을 알게 됩니다. 당신의 결정이 더 효과적이라는 말만. 어떤 조건에서 더 효과적입니까? 내가 설명한 것들과 함께, 당신의 솔루션이 switch 문보다 더 효율적이라고 주장한다면?

일화에 관해서라면, 당신은 당신의 주장을 증명할 때보다 분명히 더 말이 많습니다 ...

당신은 다음을 분명히 보여주었습니다.

1. 당신은 읽을 수 없습니다

2. 당신은 당신이 논쟁하고 있는 것이 무엇인지 이해하지 못합니다. 가장 흥미로운 것은 무엇입니까? 모르는 것에 대해 논쟁합니다.

 
Dmitry Fedoseev :

그리고 누가 그것을 읽을까요? 여기서 뭐해?

요컨대 모든 것이 명확합니다.


당신이 할 수 있다는 모든 증거는 어구, 무례함, 일화 및 이해할 수 없는 것들에 대한 언급의 일관성 없는 스니펫입니다...

 
Реter Konow :
요컨대 모든 것이 명확합니다.


당신이 할 수 있는 모든 증거는 일관성 없는 문구 조각, 무례함, 일화 및 이해할 수 없는 것들에 대한 언급입니다...


그런 다음 게시물을 다시 읽으십시오.

 
Реter Konow :


모든 것은 이미 당신에게 설명되었습니다)) 나는 당신 의 언어로 다시 시도 할 것입니다. 분명히, 큰 프로젝트를 만나지 않으면 의미를 이해하기가 더 어렵습니다. 더 편리한 경우 의견을 말하십시오. 당신을 위한

 
Nikolay Ivanov :

모든 것은 이미 당신에게 설명되었습니다)) 나는 당신의 언어로 다시 시도 할 것입니다. 분명히, 큰 프로젝트를 접해보지 않은 경우 의미를 이해하는 것이 더 어렵습니다. 더 편리한 경우 의견을 보내십시오. 당신을 위한

그렇다면 본질적으로 증명할 수 없는 것을 증명하려고 할 필요가 없습니다. 절차적 스타일에 비해 OOP의 장점을 증명하는 것은 불가능하지만 OOP 없이도 가능하고 어떤 문제도 해결하는 것이 가능하다는 것을 증명하는 것은 가능합니다. 내가 주장하는 것을 증명할 수 있고 나머지는 나에게 아무것도 증명할 수 없지만 그들은 주장합니다 ...

OOP의 원래 의미는 개발자의 생각을 구조화하는 것뿐입니다. 이 구조화는 마치 플레이 스크립트인 것처럼 프로그램의 논리를 보고 구축하는 데 도움이 됩니다. 이것은 기계와 완전히 통합되어 마스터할 수 있는 추가 기회입니다.

나는 그것에 대해 반대할 것이 없지만 프로그램이 있는 바로 그 메커니즘의 효율성을 높이는 것과는 아무 관련이 없습니다.

이것이 내가 이 모든 커뮤니케이션을 통해 이해한 주요 내용입니다.

좋은 생각을 해주셔서 감사합니다.

 
Реter Konow :

그렇다면 본질적으로 증명할 수 없는 것을 증명하려고 할 필요가 없습니다. 절차적 스타일에 비해 OOP의 장점을 입증하는 것은 불가능하지만, OOP 없이도 할 수 있고 어떤 문제도 해결하는 것이 가능하다는 것을 증명하는 것은 가능합니다. 내가 주장하는 것을 증명할 수 있고 나머지는 나에게 아무것도 증명할 수 없지만 그들은 주장합니다 ...

OOP의 원래 의미는 개발자의 생각을 구조화하는 것뿐입니다. 이 구조화는 마치 플레이 스크립트인 것처럼 프로그램의 논리를 보고 구축하는 데 도움이 됩니다. 이것은 기계와 완전히 통합되어 마스터할 수 있는 추가 기회입니다.

나는 그것에 대해 반대할 것이 없지만 프로그램이 있는 바로 그 메커니즘의 효율성을 높이는 것과는 아무 관련이 없습니다.

이것이 내가 이 모든 커뮤니케이션을 통해 이해한 주요 내용입니다.

좋은 생각을 해주신 모든 분들께 감사드립니다.



당신은 당신이 논쟁하는 것을 이해하지 못하기 때문에 모든 것이 이미 입증되었다는 것을 알 수 없습니다. 당신은 우스꽝 스럽습니다. 빌어 먹을 뱀 gorynych에게 소리 지르지 마십시오.

 
Dmitry Fedoseev :

당신은 당신이 논쟁하는 것을 이해하지 못하기 때문에 모든 것이 이미 입증되었다는 것을 알 수 없습니다. 당신은 우스꽝 스럽습니다. 빌어 먹을 뱀 gorynych에게 소리 지르지 마십시오.

자신을 모욕하지 마십시오. 당신은 내 눈에 빠진다.
 
Реter Konow :

그렇다면 본질적으로 증명할 수 없는 것을 증명하려고 할 필요가 없습니다. 절차적 스타일에 비해 OOP의 장점을 증명하는 것은 불가능하지만 OOP 없이도 가능하고 어떤 문제도 해결하는 것이 가능하다는 것을 증명하는 것은 가능합니다. 내가 주장하는 것을 증명할 수 있고 나머지는 나에게 아무것도 증명할 수 없지만 그들은 주장합니다 ...


모든 현대 시스템이 OOP를 사용한다는 사실이 우월성의 증거가 아닙니까? 당신은 아직 이해할 준비가되지 않았습니다. 간단한 질문을하고 복잡한 답변을 수락 할 수 없습니다 .. 그리고 당신은 대답이 없다고 생각합니다 .. 글쎄, 이것은 옳지 않습니다 ..

OOP의 원래 의미는 개발자의 생각을 구조화하는 것뿐입니다. 이 구조화는 마치 플레이 스크립트인 것처럼 프로그램의 논리를 보고 구축하는 데 도움이 됩니다. 이것은 기계와 완전히 통합되어 마스터할 수 있는 추가 기회입니다.


생각이 변하고 있다는 사실은 그렇습니다. 처음에는 그렇게 보이지만 무엇을 위한 것입니까? 그러나 프로젝트 가 수천 줄의 코드가 되면 보상을 받기 시작합니다.)) 왜 그리고 무엇에 대한 것인지 이해합니다)


나는 그것에 대해 반대하는 것이 없지만 프로그램이 있는 바로 그 메커니즘의 효율성을 향상시키는 것과는 아무 관련이 없습니다.

프로젝트가 지원되고 업데이트되면 확장이 어렵고 비용이 많이 들고 다른 프로젝트는 빠르고 쉬우면 첫 번째 프로젝트가 죽습니다. 이것은 자연 선택입니다.

 
Dmitry Fedoseev :

농담:

Ilya Muromets는 뱀 Gorynych와 함께 싸웠습니다. 하루가 가고 이틀이 가다가 갑자기 산과 그 안에 있는 동굴을 봅니다.
동굴을 들여다보며 외쳤다.
- 뱀 고리니치, 나와라, 우리는 싸울 것이다!
그리고 대답은 침묵입니다. 그는 다시:
- 뱀 고리니치, 나와라, 우리는 싸울 것이다!
고요. 그는 세 번째로:
- 뱀 고리니치, 나와라, 우리는 싸울 것이다!
그리고 산 뒤에서 머리가 나타납니다.
- 글쎄, 싸워, 그렇게 싸워, 그런데 왜 소리를 지르지?


이 주제와 유사)) 오래 전에 Popular Mechanics 잡지를 구독했는데 유머 페이지가 있었습니다.

일단 레오는 전쟁에 나섰습니다. 글쎄, 그것은 모두 헛소리입니다. 여우를 만납니다. 폭스, 누카 빨리, 짐승의 왕은 누구?

레오, 당신은 물론입니다!

만족, 진행

토끼를 만났어, 같은 결과

코끼리를 만났습니다. 그리고 코끼리는 뜨거웠고 그는 파리에서 몸통을 흔들었고 사자는 트위들디 속으로 날아갔습니다.

그리고 친구들이여, 그가 덤불 속에 앉아 떠나는 코끼리에게 뭐라고 말했는지 아십니까?

- 그리고 답을 모르면 화내지 않는다))