수업을 들을 곳도 없는데 어떻게 OOP를 사용할 수 있나요? 나는 단지 그것들이 필요하지 않습니다. 나는 구조가 필요하지 않습니다. 이것은 내 프로그램의 자체 개발로 정당화되지 않는 인위적인 분할입니다. 그것이 자기개발입니다. 달리 부를 수 없습니다.
그래서 이 과정에서 코드 블록 자체가 필요에 따라 분할되며, 이는 이를 개선하고 새로운 기능을 추가하는 과정에서 탄생합니다. 먼저 기능이 생성된 다음 점차적으로 큰 블록으로 결합되어 새로운 기능으로 다듬어지고 무성해집니다. 시간이 지남에 따라 이러한 블록이 떨어져서 새로운 블록이 나타납니다. 모든 것이 자연스럽게 일어납니다. 나는 새로운 기능을 획득하기 위해 새로운 기능을 "성장"시킨 다음 고품질 상태로 연마할 뿐입니다. 동시에 코드의 구조는 끊임없이 변화하고 변형됩니다. 나는 명확한 계획이 없으며 모든 것이 예측할 수없는 방향으로 발전합니다. 이 과정에서 뜻밖에도 저는 비약적인 도약의 기회를 찾습니다. 그리고 나는 이 점프를 한다.
이것이 내 프로그램이 발전하는 방식입니다. 팽창했다가 수축했다가 무너졌다가 변형되어 복원됩니다. 글로벌 재분배, 질적 도약이 있지만 장기적으로 안정적인 상태도 있습니다.
수업을 들을 곳도 없는데 어떻게 OOP를 사용할 수 있나요? 나는 단지 그것들이 필요하지 않습니다. 나는 구조가 필요하지 않습니다. 이것은 내 프로그램의 자체 개발로 정당화되지 않는 인위적인 분할입니다. 그것이 자기개발입니다. 달리 부를 수 없습니다.
그래서 이 과정에서 코드 블록 자체가 필요에 따라 분할되며, 이는 이를 개선하고 새로운 기능을 추가하는 과정에서 탄생합니다. 먼저 기능이 생성된 다음 점차적으로 큰 블록으로 결합되어 새로운 기능으로 다듬어지고 무성해집니다. 시간이 지남에 따라 이러한 블록이 무너지고 새로운 블록이 나타납니다. 모든 것이 자연스럽게 일어납니다. 나는 새로운 기능을 획득하기 위해 새로운 기능을 "성장"시킨 다음 고품질 상태로 연마할 뿐입니다. 동시에 코드의 구조는 끊임없이 변화하고 변형됩니다. 나는 명확한 계획이 없으며 모든 것이 예측할 수없는 방향으로 발전합니다. 이 과정에서 뜻밖에도 저는 비약적인 도약의 기회를 찾습니다. 그리고 나는 이 점프를 한다.
이것이 내 프로그램이 발전하는 방식입니다. 팽창했다가 수축했다가 무너졌다가 변형되어 복원됩니다. 글로벌 재분배, 질적 도약이 있지만 장기적으로 안정적인 상태도 있습니다.
이 과정에서 외국어로 된 추가 규칙과 구문은 느려질 뿐입니다.
처리해야 할 구조가 있지만 일주일을 보낼 가치가 있습니까? "나는 구조가 필요 없다"는 말은 정말 어리석은 말이다. 결론은 하나뿐입니다. 그것이 무엇인지 모릅니다.
나에게 OOP는 편리한 래퍼일 뿐이며 일부 문제에 대한 솔루션은 아닙니다. 그래서 토론은 여기서 끝났다.
일반적으로 모든 사람은 구조적 절차적 접근 방식을 사용하여 작업을 훨씬 빠르고 간결하게 해결할 수 있다는 데 동의하는 것 같습니다. 그리고 클래스로 래핑하는 것은 코딩 자체보다 더 많은 시간이 걸립니다. 때때로 당신은 너무 정신이 나가서 많은 수업을 쌓은 다음 생각합니다. 그리고 왜 그것이 모두 필요했는지 ...
글쎄요, "함수 포인터를 사용한 절차적 프로그래밍"에 대해 한 가지 더 말씀드리겠습니다. 왜 별도의 카테고리로 분류되어야 합니까? 내 생각에 함수 포인터는 어떻게 든 구조적 절차 스타일에 속합니다.
나에게 OOP는 편리한 래퍼일 뿐이며 일부 문제에 대한 솔루션은 아닙니다. 그래서 토론은 여기서 끝났다.
일반적으로 모든 사람은 구조적 절차적 접근 방식을 사용하여 작업을 훨씬 빠르고 간결하게 해결할 수 있다는 데 동의하는 것 같습니다. 그리고 클래스로 래핑하는 것은 코딩 자체보다 더 많은 시간이 걸립니다. 때때로 당신은 너무 정신이 나가서 많은 수업을 쌓은 다음 생각합니다. 그리고 왜 그것이 모두 필요했는지 ...
글쎄요, "함수 포인터를 사용한 절차적 프로그래밍"에 대해 한 가지 더 말씀드리겠습니다. 왜 별도의 카테고리로 분류되어야 합니까? 내 생각에 함수 포인터는 어떻게 든 구조적 절차 스타일에 속합니다.
다형성 은 아마도 함수 포인터를 제외하고는 절차적 수단에 의해 구현되지 않습니다. OOP는 분명히 다형성이며 절차적 프로그래밍에서 함수 포인터가 있다는 것은 사실이 아닙니다.
수업을 들을 곳도 없는데 어떻게 OOP를 사용할 수 있나요? 나는 단지 그것들이 필요하지 않습니다. 나는 구조가 필요하지 않습니다. 이것은 내 프로그램의 자체 개발로 정당화되지 않는 인위적인 분할입니다. 그것이 자기개발입니다. 달리 부를 수 없습니다.
그래서 이 과정에서 코드 블록 자체가 필요에 따라 분할되며, 이는 이를 개선하고 새로운 기능을 추가하는 과정에서 탄생합니다. 먼저 기능이 생성된 다음 점차적으로 큰 블록으로 결합되어 새로운 기능으로 다듬어지고 무성해집니다. 시간이 지남에 따라 이러한 블록이 떨어져서 새로운 블록이 나타납니다. 모든 것이 자연스럽게 일어납니다. 나는 새로운 기능을 획득하기 위해 새로운 기능을 "성장"시킨 다음 고품질 상태로 연마할 뿐입니다. 동시에 코드의 구조는 끊임없이 변화하고 변형됩니다. 나는 명확한 계획이 없으며 모든 것이 예측할 수없는 방향으로 발전합니다. 이 과정에서 뜻밖에도 저는 비약적인 도약의 기회를 찾습니다. 그리고 나는 이 점프를 한다.
이것이 내 프로그램이 발전하는 방식입니다. 팽창했다가 수축했다가 무너졌다가 변형되어 복원됩니다. 글로벌 재분배, 질적 도약이 있지만 장기적으로 안정적인 상태도 있습니다.
이 과정에서 외국어로 된 추가 규칙과 구문은 느려질 뿐입니다.
수업을 들을 곳도 없는데 어떻게 OOP를 사용할 수 있나요? 나는 단지 그것들이 필요하지 않습니다. 나는 구조가 필요하지 않습니다. 이것은 내 프로그램의 자체 개발로 정당화되지 않는 인위적인 분할입니다. 그것이 자기개발입니다. 달리 부를 수 없습니다.
그래서 이 과정에서 코드 블록 자체가 필요에 따라 분할되며, 이는 이를 개선하고 새로운 기능을 추가하는 과정에서 탄생합니다. 먼저 기능이 생성된 다음 점차적으로 큰 블록으로 결합되어 새로운 기능으로 다듬어지고 무성해집니다. 시간이 지남에 따라 이러한 블록이 무너지고 새로운 블록이 나타납니다. 모든 것이 자연스럽게 일어납니다. 나는 새로운 기능을 획득하기 위해 새로운 기능을 "성장"시킨 다음 고품질 상태로 연마할 뿐입니다. 동시에 코드의 구조는 끊임없이 변화하고 변형됩니다. 나는 명확한 계획이 없으며 모든 것이 예측할 수없는 방향으로 발전합니다. 이 과정에서 뜻밖에도 저는 비약적인 도약의 기회를 찾습니다. 그리고 나는 이 점프를 한다.
이것이 내 프로그램이 발전하는 방식입니다. 팽창했다가 수축했다가 무너졌다가 변형되어 복원됩니다. 글로벌 재분배, 질적 도약이 있지만 장기적으로 안정적인 상태도 있습니다.
이 과정에서 외국어로 된 추가 규칙과 구문은 느려질 뿐입니다.
처리해야 할 구조가 있지만 일주일을 보낼 가치가 있습니까? "나는 구조가 필요 없다"는 말은 정말 어리석은 말이다. 결론은 하나뿐입니다. 그것이 무엇인지 모릅니다.
절차적으로 최적으로 해결할 수 없는 문제가 있습니다.
"최적의 방법"이 의미하는 바에 따라)
나에게 OOP는 편리한 래퍼일 뿐이며 일부 문제에 대한 솔루션은 아닙니다. 그래서 토론은 여기서 끝났다.
일반적으로 모든 사람은 구조적 절차적 접근 방식을 사용하여 작업을 훨씬 빠르고 간결하게 해결할 수 있다는 데 동의하는 것 같습니다. 그리고 클래스로 래핑하는 것은 코딩 자체보다 더 많은 시간이 걸립니다. 때때로 당신은 너무 정신이 나가서 많은 수업을 쌓은 다음 생각합니다. 그리고 왜 그것이 모두 필요했는지 ...
글쎄요, "함수 포인터를 사용한 절차적 프로그래밍"에 대해 한 가지 더 말씀드리겠습니다. 왜 별도의 카테고리로 분류되어야 합니까? 내 생각에 함수 포인터는 어떻게 든 구조적 절차 스타일에 속합니다.
"최적의 방법"이 의미하는 바에 따라)
나에게 OOP는 편리한 래퍼일 뿐이며 일부 문제에 대한 솔루션은 아닙니다. 그래서 토론은 여기서 끝났다.
일반적으로 모든 사람은 구조적 절차적 접근 방식을 사용하여 작업을 훨씬 빠르고 간결하게 해결할 수 있다는 데 동의하는 것 같습니다. 그리고 클래스로 래핑하는 것은 코딩 자체보다 더 많은 시간이 걸립니다. 때때로 당신은 너무 정신이 나가서 많은 수업을 쌓은 다음 생각합니다. 그리고 왜 그것이 모두 필요했는지 ...
글쎄요, "함수 포인터를 사용한 절차적 프로그래밍"에 대해 한 가지 더 말씀드리겠습니다. 왜 별도의 카테고리로 분류되어야 합니까? 내 생각에 함수 포인터는 어떻게 든 구조적 절차 스타일에 속합니다.
다형성 은 아마도 함수 포인터를 제외하고는 절차적 수단에 의해 구현되지 않습니다. OOP는 분명히 다형성이며 절차적 프로그래밍에서 함수 포인터가 있다는 것은 사실이 아닙니다.
행에 있는 모든 것은 클래스로 래핑할 필요가 없습니다.
처리해야 할 구조가 있지만 일주일을 보낼 가치가 있습니까? "나는 구조가 필요 없다"는 말은 정말 어리석은 말이다. 결론은 하나뿐입니다. 그것이 무엇인지 모릅니다.
구조는 자명합니다. 다양한 유형의 명명된 변수 집합을 결합합니다. 내 프로그램의 주요 유형은 int입니다. double은 몇몇 장소에서만 사용됩니다. 하나의 특정 블록에만 있는 문자열입니다.
OOP 컨텍스트에서 구조가 필요한 이유는 무엇입니까?
커널에 속한 하나의 구조가 있습니다. 즉, 자체 내부의 핵 자체의 구조입니다. 그게 다야.
구조는 자명합니다. 다양한 유형의 명명된 변수 집합을 결합합니다. 내 프로그램의 주요 유형은 int입니다. double은 몇몇 장소에서만 사용됩니다. 하나의 특정 블록에만 있는 문자열입니다.
OOP 컨텍스트에서 구조가 필요한 이유는 무엇입니까?
커널에 속한 하나의 구조가 있습니다. 즉, 자체 내부의 핵 자체의 구조입니다. 그게 다야.
아마 3년은 자신을 위한 하나의 프로그램을 보는 것입니다.
가능하지만 기능의 효율성이 다릅니다. 여기에 지원에 대한 이야기는 없습니다. 너무 상대적입니다.
절차적으로 최적으로 해결할 수 없는 문제가 있습니다.
나는 OOP의 지지자이지만 사실 프로세서는 OOP의 존재에 대해 아무 것도 모르고 기계 코드를 실행할 수 있는 것뿐입니다. 컴퓨터 초창기에는 이것이 바로 기계 코드로 프로그램이 작성된 방식입니다.
그래서 여성 프로그래머가 많았다. 그런 일을 한 사람들은 급격히 술 취한 사람이되어 탑을 탔습니다.))
결국, 가장 중요한 것은 결정의 효율성이라는 데 동의할 것입니다.
구문의 힙과 규칙의 복잡성은 솔루션의 효율성을 유지하는 데 기여한 적이 없습니다. 코드 블록의 간결성, 보편성 및 가독성으로 표현되는 단순성과 간결성에 기여했습니다.
효과적인 솔루션이란 무엇을 의미합니까?
내 프로그래밍 규칙은 더 적은 코드, 더 적은 규칙, 더 적은 구문입니다...
나는 OOP의 팬이 아닙니다.
그러나 유지 관리, 확장성 및 타사의 사용 용이성 측면에서 TC(Karputov가 아니라 Peter)를 밀어붙이는 것은 석기 시대에 불과합니다.
나는 모든 프로그래머가 코드의 효율성과 다양성이 이 코드가 좋은 것을 의미하지 않는다는 것을 이해하기 위해 이상적으로는 4명 이상의 팀에서 작업해야 한다는 강한 의견을 가지고 있습니다.
나는 OOP의 지지자이지만 사실 프로세서는 OOP의 존재에 대해 아무 것도 모르고 기계 코드를 실행할 수 있는 것뿐입니다. 컴퓨터 초창기에는 이것이 바로 기계 코드로 프로그램이 작성된 방식입니다.
그래서 여성 프로그래머가 많았다. 그런 일을 한 사람들은 급격히 술 취한 사람이되어 탑을 탔습니다.))
그것의 무엇? 지금까지 한 가지 결론이 제시되었습니다. 새벽에 기계 코드로 많이 작성해야했습니다))