강요할 필요는 없지만 절차적 형태에서 코드의 논리는 불필요한 제스처 없이 이미 표시되고 고용된 프로그래머의 각 제스처는 고용주에게 비용이 듭니다. 따라서 고용주가 바보가 아니라면 그는 OOP에 빠지지 않을 것이지만, 반면에 교활한 프로그래머는 OOP의 진행성에 대해 국수를 걸어 OOP의 이점을 활용하여 더 많은 것을 줄일 수 있습니다. 무식. :)
하아!
결국 Duc는 걷기에서 "불필요한 제스처가없는"논리도 볼 수 있지만 어떤 이유로 모든 사람이 교통 수단으로 가려고 노력합니다. 그것은 광기에옵니다. 그들은 차를 타고 피트니스 센터로 2km를 운전하여 그곳에서 러닝 머신에서 5km를 "감기"할 수 있습니다.
프로그래밍에 더 가깝습니다. DOS에서 비디오 버퍼에 대한 간단한 쓰기로 창이 생성됩니다. 그리고 Windows에서 가장 간단한 창을 만들려면 창 클래스를 등록하고, 만들고, 메시지 처리 루프를 시작해야 합니다. 하지만 어떤 이유로 모든 사람이 이러한 "추가 제스처"를 수행합니다.
그래서 여기도. OOP는 "진보성"이 아니라 이 기술이 제공하는 이점과 궁극적으로 고용주에게 더 저렴하기 때문에 선택됩니다. 절차적 스타일로 무언가를 작성하면 OOP 스타일로 작성된 것과 동일한 효율성으로 유지 관리할 수 없기 때문입니다.
좋은 예는 Peter Konov의 코드입니다. 한편으로는 상당히 정상적인 절차적 코드이지만 다른 한편으로는 이 코드로 작업하기 위해 개인적으로 그런 작업을 하는 시스템은 큰 일을 해도 돈을 받지 않습니다. 동시에 OOP 스타일로 작성된 SB는 유지 보수 및 수정에 매우 편리합니다. 표준 라이브러리 TS 템플릿의 개체 아키텍처는 Peter의 코드보다 훨씬 까다롭지만 이해하고 수정하는 것이 훨씬 쉽습니다.
'불필요한 제스처가 없는 절차적 스타일'이라는 이야기는 정말 복잡한 구조를 작성하고 특히 수정해야 하는 순간까지만입니다. 이것이 OOP가 널리 사용되는 이유입니다. 프로그래머에게는 더 쉽고 고객에게는 더 저렴합니다. 그러나 매우 간단한 작업을 수행하려면 "과도한 제스처"가 필요합니다. 이것이 가장 "단순"하다는 것뿐입니다. 아무도 필요하지 않고 모든 사람에게 "복잡한"이 필요합니다. 이는 OOP를 사용하여 수행하는 것이 더 좋습니다.
추신 그리고 나는 아직도 당신("당신")이 OOP 접근 수정자 없이는 어디에도 사용되어서는 안 되는 기능에 대한 접근을 제한할 것을 제안하는 방법을 이해하지 못합니까?
절차적 스타일로 무언가를 작성하면 OOP 스타일로 작성된 것과 동일한 효율성으로 유지 관리할 수 없기 때문입니다.
추신 그리고 나는 아직도 당신("당신")이 OOP 접근 수정자 없이는 어디에도 사용되어서는 안 되는 기능에 대한 접근을 제한할 것을 제안하는 방법을 이해하지 못합니까?
아니요. 모든 것이 정반대입니다.
OOPish 코드는 여러 가지 다른 트릭에 의해 논리가 숨겨져 있기 때문에 유지 관리 및 수정하기가 어렵습니다. 그러면 코드를 다시 작성하기가 더 쉽습니다. 결국 OOP의 목적은 논리를 숨기는 것인데, 글쎄, 그들은 그것을 숨겼고, 갑자기 공개해야 할 경우 추가 비용을 지불하는 서비스입니다.
함수 래퍼를 사용하면 내부 함수를 숨길 수 있지만 손이 가렵고 어쨌든 이 내부 함수를 망치고 싶다면 DLL의 별도 파일에 소스를 숨기고 가장 먼 디렉토리에 있는 파일을 숨길 수 있습니다 원하는 모든 것을 찾지 못했지만 특히 폭력적인 프로그래머를위한 옵션이 여전히있을 수 있습니다. :)
OOPish 코드는 여러 가지 다른 트릭에 의해 논리가 숨겨져 있기 때문에 유지 관리 및 수정하기가 어렵습니다. 그러면 코드를 다시 작성하기가 더 쉽습니다. 결국 OOP의 목적은 논리를 숨기는 것인데, 글쎄, 그들은 그것을 숨겼고, 갑자기 공개해야 할 경우 추가 비용을 지불하는 서비스입니다.
함수 래퍼를 사용하면 내부 기능을 숨길 수 있지만 손이 가렵고 어쨌든 이 내부 기능을 망치고 싶다면 DLL의 별도 파일에 소스를 숨기고 가장 먼 디렉토리에 있는 파일을 숨길 수 있습니다. 원하는 모든 것을 찾지 못했지만 특히 폭력적인 프로그래머를위한 옵션이 여전히있을 수 있습니다. :)
논리가 숨겨져 있으면 왜 "수정하기 어렵습니까"? 이에 대한 논리는 숨겨져 있으므로 수행할 수 없는 경우 수정할 수 없습니다.
무언가를 변경하고 싶었고 변경한 다음 작동하지 않는 이유를 이해하지 못하는 절차적 접근 방식일 뿐입니다(심지어 때로는 이해할 수 없는 오류가 발생하기도 함). 그리고 OOP 접근 방식에서 당신은 그것을 바꾸고 싶었습니다. 그리고 당신은 클래스의 내부에 접근할 수 없었습니다. 그리고 접근이 불가능하기 때문에 이유가 있었다는 의미이고, 거기에 뭔가 까다로운 부분이 있고, 사용을 위한 암묵적인 조건이 있습니다. 따라서 무언가를 변경하려면 이 동일한 클래스를 사용하고 이 클래스에서 자신의 클래스를 상속하고 필요한 것을 변경합니다. 상속인은 이미 보호된 메서드에 액세스할 수 있습니다.
게다가 상속을 받은 경우에도 - 상속인이라도 접근할 수 없는 private 메소드나 필드에 부딪힐 수 있고, 일단 이것이 완료되면 - 다시 말하지만, 이 필드는 자손에서도 변경될 의도가 아님을 의미합니다.
"DLLku에서 숨기기"에 대해 이야기하는 것 - 여기서 문제는 DLLku에서 한 번에 모든 것을 숨길 수 있다는 것입니다. 개체의 일부가 아닙니다. 그리고 접근 한정자는 개체의 일부만 숨기는 데 필요한 것입니다. 이를 위해 모든 것이 시작됩니다. 따라서 프로그램의 각 위치에 있는 프로그래머는 필요한 것에만 액세스할 수 있고 "위에서"는 액세스할 수 없습니다. 이렇게 하면 필요한 것이 아닌 실수로 변경할 것을 두려워하지 않아도 됩니다. , 그러나 수정에 유효한 부분을 변경할 수 있습니다. 그러면 DLL의 요점은 무엇입니까? DLL 코드를 연 다음 액세스하면 부분이 아니라 전체가 열립니다. 닫기 - 다시 모든 액세스가 닫힙니다.
private-protected-public 섹션을 사용하지 않고 절차적 방식으로 액세스를 제한하는 방법을 모르겠습니다. 그리고 이 제한은 저에게 많은 도움이 됩니다.
논리가 숨겨져 있으면 왜 "수정하기 어렵습니까"? 이에 대한 논리는 숨겨져 있으므로 수행할 수 없는 경우 수정할 수 없습니다.
무언가를 변경하고 싶었고 변경한 다음 작동하지 않는 이유를 이해하지 못하는 절차적 접근 방식일 뿐입니다(심지어 때로는 이해할 수 없는 오류가 발생하기도 함). 그리고 OOP 접근 방식에서 당신은 그것을 바꾸고 싶었습니다. 그리고 당신은 클래스의 내부에 접근할 수 없었습니다. 그리고 접근이 불가능하기 때문에 이유가 있었다는 뜻이고, 거기에 뭔가 까다로운 부분이 있고, 사용을 위한 암묵적인 조건이 있습니다. 따라서 무언가를 변경하려면 이 동일한 클래스를 사용하고 이 클래스에서 자신의 클래스를 상속하고 필요한 것을 변경합니다. 상속인은 이미 보호된 메서드에 액세스할 수 있습니다.
게다가 상속을 받은 경우에도 - 상속인이라도 접근할 수 없는 private 메소드나 필드에 부딪힐 수 있고, 일단 이것이 완료되면 - 다시 말하지만, 이 필드는 자손에서도 변경될 의도가 아님을 의미합니다.
"DLLku에서 숨기기"에 대해 이야기하는 것 - 여기서 문제는 DLLku에서 한 번에 모든 것을 숨길 수 있다는 것입니다. 개체의 일부가 아닙니다. 그리고 접근 한정자는 개체의 일부만 숨기는 데 필요한 것입니다. 이를 위해 모든 것이 시작됩니다. 따라서 프로그램의 각 위치에 있는 프로그래머는 필요한 것에만 액세스할 수 있고 "위에서"는 액세스할 수 없습니다. 이렇게 하면 필요한 것이 아닌 실수로 변경할 것을 두려워하지 않아도 됩니다. , 그러나 수정에 유효한 부분을 변경할 수 있습니다. 그러면 DLL의 요점은 무엇입니까? DLL 코드를 연 다음 액세스하면 부분이 아니라 전체가 열립니다. 닫기 - 다시 모든 액세스가 닫힙니다.
private-protected-public 섹션을 사용하지 않고 절차적 방식으로 액세스를 제한하는 방법을 모르겠습니다. 그리고 이 제한은 저에게 많은 도움이 됩니다.
예, 원칙적으로 OOP를 사용한 제스처의 수는 더 적을 수 없습니다. 이러한 모든 인터페이스는 종종 로직 자체를 작성하는 비용을 초과하는 추가 오버헤드 비용이기 때문입니다. 그리고 이것은 모든 기능에 이미 인터페이스가 있음에도 불구하고, 즉 본질적으로 의미가 없는 정원을 하나 더 울타리로 묶는 것이 제안됩니다.
동시에 인터페이스와 기능 모두에서 코드가 변경되면 하나가 다른 하나에 연결되기 때문에 훨씬 더 복잡해집니다. 즉, 가능한 버그 수와 노동 강도가 최소한 2차 증가합니다. ... 분명한 것 같습니다.
강요할 필요는 없지만 절차적 형태에서 코드의 논리는 불필요한 제스처 없이 이미 표시되고 고용된 프로그래머의 각 제스처는 고용주에게 비용이 듭니다. 따라서 고용주가 바보가 아니라면 그는 OOP에 빠지지 않을 것이지만, 반면에 교활한 프로그래머는 OOP의 진행성에 대해 국수를 걸어 OOP의 이점을 활용하여 더 많은 것을 줄일 수 있습니다. 무식. :)
하아!
결국 Duc는 걷기에서 "불필요한 제스처가없는"논리도 볼 수 있지만 어떤 이유로 모든 사람이 교통 수단으로 가려고 노력합니다. 그것은 광기에옵니다. 그들은 차를 타고 피트니스 센터로 2km를 운전하여 그곳에서 러닝 머신에서 5km를 "감기"할 수 있습니다.
프로그래밍에 더 가깝습니다. DOS에서 비디오 버퍼에 대한 간단한 쓰기로 창이 생성됩니다. 그리고 Windows에서 가장 간단한 창을 만들려면 창 클래스를 등록하고, 만들고, 메시지 처리 루프를 시작해야 합니다. 하지만 어떤 이유로 모든 사람이 이러한 "추가 제스처"를 수행합니다.
그래서 여기도. OOP는 "진보성"이 아니라 이 기술이 제공하는 이점과 궁극적으로 고용주에게 더 저렴하기 때문에 선택됩니다. 절차적 스타일로 무언가를 작성하면 OOP 스타일로 작성된 것과 동일한 효율성으로 유지 관리할 수 없기 때문입니다.
좋은 예는 Peter Konov의 코드입니다. 한편으로는 상당히 정상적인 절차적 코드이지만 다른 한편으로는 이 코드로 작업하기 위해 개인적으로 그런 작업을 하는 시스템은 큰 일을 해도 돈을 받지 않습니다. 동시에 OOP 스타일로 작성된 SB는 유지 보수 및 수정에 매우 편리합니다. 표준 라이브러리 TS 템플릿의 개체 아키텍처는 Peter의 코드보다 훨씬 까다롭지만 이해하고 수정하는 것이 훨씬 쉽습니다.
'불필요한 제스처가 없는 절차적 스타일'이라는 이야기는 정말 복잡한 구조를 작성하고 특히 수정해야 하는 순간까지만입니다. 이것이 OOP가 널리 사용되는 이유입니다. 프로그래머에게는 더 쉽고 고객에게는 더 저렴합니다. 그러나 매우 간단한 작업을 수행하려면 "과도한 제스처"가 필요합니다. 이것이 가장 "단순"하다는 것뿐입니다. 아무도 필요하지 않고 모든 사람에게 "복잡한"이 필요합니다. 이는 OOP를 사용하여 수행하는 것이 더 좋습니다.
추신 그리고 나는 아직도 당신("당신")이 OOP 접근 수정자 없이는 어디에도 사용되어서는 안 되는 기능에 대한 접근을 제한할 것을 제안하는 방법을 이해하지 못합니까?
George Merts :
절차적 스타일로 무언가를 작성하면 OOP 스타일로 작성된 것과 동일한 효율성으로 유지 관리할 수 없기 때문입니다.
추신 그리고 나는 아직도 당신("당신")이 OOP 접근 수정자 없이는 어디에도 사용되어서는 안 되는 기능에 대한 접근을 제한할 것을 제안하는 방법을 이해하지 못합니까?아니요. 모든 것이 정반대입니다.
OOPish 코드는 여러 가지 다른 트릭에 의해 논리가 숨겨져 있기 때문에 유지 관리 및 수정하기가 어렵습니다. 그러면 코드를 다시 작성하기가 더 쉽습니다. 결국 OOP의 목적은 논리를 숨기는 것인데, 글쎄, 그들은 그것을 숨겼고, 갑자기 공개해야 할 경우 추가 비용을 지불하는 서비스입니다.
함수 래퍼를 사용하면 내부 함수를 숨길 수 있지만 손이 가렵고 어쨌든 이 내부 함수를 망치고 싶다면 DLL의 별도 파일에 소스를 숨기고 가장 먼 디렉토리에 있는 파일을 숨길 수 있습니다 원하는 모든 것을 찾지 못했지만 특히 폭력적인 프로그래머를위한 옵션이 여전히있을 수 있습니다. :)
아니요. 모든 것이 정반대입니다.
OOPish 코드는 여러 가지 다른 트릭에 의해 논리가 숨겨져 있기 때문에 유지 관리 및 수정하기가 어렵습니다. 그러면 코드를 다시 작성하기가 더 쉽습니다. 결국 OOP의 목적은 논리를 숨기는 것인데, 글쎄, 그들은 그것을 숨겼고, 갑자기 공개해야 할 경우 추가 비용을 지불하는 서비스입니다.
함수 래퍼를 사용하면 내부 기능을 숨길 수 있지만 손이 가렵고 어쨌든 이 내부 기능을 망치고 싶다면 DLL의 별도 파일에 소스를 숨기고 가장 먼 디렉토리에 있는 파일을 숨길 수 있습니다. 원하는 모든 것을 찾지 못했지만 특히 폭력적인 프로그래머를위한 옵션이 여전히있을 수 있습니다. :)
논리가 숨겨져 있으면 왜 "수정하기 어렵습니까"? 이에 대한 논리는 숨겨져 있으므로 수행할 수 없는 경우 수정할 수 없습니다.
무언가를 변경하고 싶었고 변경한 다음 작동하지 않는 이유를 이해하지 못하는 절차적 접근 방식일 뿐입니다(심지어 때로는 이해할 수 없는 오류가 발생하기도 함). 그리고 OOP 접근 방식에서 당신은 그것을 바꾸고 싶었습니다. 그리고 당신은 클래스의 내부에 접근할 수 없었습니다. 그리고 접근이 불가능하기 때문에 이유가 있었다는 의미이고, 거기에 뭔가 까다로운 부분이 있고, 사용을 위한 암묵적인 조건이 있습니다. 따라서 무언가를 변경하려면 이 동일한 클래스를 사용하고 이 클래스에서 자신의 클래스를 상속하고 필요한 것을 변경합니다. 상속인은 이미 보호된 메서드에 액세스할 수 있습니다.
게다가 상속을 받은 경우에도 - 상속인이라도 접근할 수 없는 private 메소드나 필드에 부딪힐 수 있고, 일단 이것이 완료되면 - 다시 말하지만, 이 필드는 자손에서도 변경될 의도가 아님을 의미합니다.
"DLLku에서 숨기기"에 대해 이야기하는 것 - 여기서 문제는 DLLku에서 한 번에 모든 것을 숨길 수 있다는 것입니다. 개체의 일부가 아닙니다. 그리고 접근 한정자는 개체의 일부만 숨기는 데 필요한 것입니다. 이를 위해 모든 것이 시작됩니다. 따라서 프로그램의 각 위치에 있는 프로그래머는 필요한 것에만 액세스할 수 있고 "위에서"는 액세스할 수 없습니다. 이렇게 하면 필요한 것이 아닌 실수로 변경할 것을 두려워하지 않아도 됩니다. , 그러나 수정에 유효한 부분을 변경할 수 있습니다. 그러면 DLL의 요점은 무엇입니까? DLL 코드를 연 다음 액세스하면 부분이 아니라 전체가 열립니다. 닫기 - 다시 모든 액세스가 닫힙니다.
private-protected-public 섹션을 사용하지 않고 절차적 방식으로 액세스를 제한하는 방법을 모르겠습니다. 그리고 이 제한은 저에게 많은 도움이 됩니다.
논리가 숨겨져 있으면 왜 "수정하기 어렵습니까"? 이에 대한 논리는 숨겨져 있으므로 수행할 수 없는 경우 수정할 수 없습니다.
무언가를 변경하고 싶었고 변경한 다음 작동하지 않는 이유를 이해하지 못하는 절차적 접근 방식일 뿐입니다(심지어 때로는 이해할 수 없는 오류가 발생하기도 함). 그리고 OOP 접근 방식에서 당신은 그것을 바꾸고 싶었습니다. 그리고 당신은 클래스의 내부에 접근할 수 없었습니다. 그리고 접근이 불가능하기 때문에 이유가 있었다는 뜻이고, 거기에 뭔가 까다로운 부분이 있고, 사용을 위한 암묵적인 조건이 있습니다. 따라서 무언가를 변경하려면 이 동일한 클래스를 사용하고 이 클래스에서 자신의 클래스를 상속하고 필요한 것을 변경합니다. 상속인은 이미 보호된 메서드에 액세스할 수 있습니다.
게다가 상속을 받은 경우에도 - 상속인이라도 접근할 수 없는 private 메소드나 필드에 부딪힐 수 있고, 일단 이것이 완료되면 - 다시 말하지만, 이 필드는 자손에서도 변경될 의도가 아님을 의미합니다.
"DLLku에서 숨기기"에 대해 이야기하는 것 - 여기서 문제는 DLLku에서 한 번에 모든 것을 숨길 수 있다는 것입니다. 개체의 일부가 아닙니다. 그리고 접근 한정자는 개체의 일부만 숨기는 데 필요한 것입니다. 이를 위해 모든 것이 시작됩니다. 따라서 프로그램의 각 위치에 있는 프로그래머는 필요한 것에만 액세스할 수 있고 "위에서"는 액세스할 수 없습니다. 이렇게 하면 필요한 것이 아닌 실수로 변경할 것을 두려워하지 않아도 됩니다. , 그러나 수정에 유효한 부분을 변경할 수 있습니다. 그러면 DLL의 요점은 무엇입니까? DLL 코드를 연 다음 액세스하면 부분이 아니라 전체가 열립니다. 닫기 - 다시 모든 액세스가 닫힙니다.
private-protected-public 섹션을 사용하지 않고 절차적 방식으로 액세스를 제한하는 방법을 모르겠습니다. 그리고 이 제한은 저에게 많은 도움이 됩니다.
Georges, 당신은 다시 구슬을 던집니다))) 무의미합니다
Georges, 당신은 다시 구슬을 던집니다))) 무의미합니다
아마도.
하지만 당신이야, 아르바이트 카사노바... 그리고 난 아르바이트 교사야. "클라이언트가 손실되지 않았습니다"라고 표시됩니다. 따라서 설명을 계속합니다. "전문 변형"을 입력하십시오.
아마도.
하지만 당신이야, 아르바이트 카사노바... 그리고 난 아르바이트 교사야. "클라이언트가 손실되지 않았습니다"라고 표시됩니다. 따라서 설명을 계속합니다. "전문 변형"을 입력하십시오.
나는 가마솥과 함께 그것을 얻었다. 나는 동화를 생각해 내고 그것을 믿었습니다) 산타 클로스의 아이처럼 골리)
강요할 필요는 없지만 절차적 형태에서 코드의 논리가 불필요한 제스처 없이 이미 표시되고 고용된 프로그래머의 각 제스처는 고용주의 비용이 든다는 것이 분명합니다.
위 절차 코드의 제스처 수는 변경해야 하는 경우 더 많이 필요합니다.
함수(절차) 없이 코드를 작성할 수 있습니다. 그러나 시간이 지남에 따라 코딩은 "콘크리트 붓기"를 통해 작성되는 것을 중단했지만 "벽돌"에서 구축하기 시작했습니다. 여기에서 절차적 프로그래밍이 시작되었습니다.
OOP는 전체 작업을 더 간단한 구성 요소로 나누는 또 다른 단계입니다.
분업과 결과적으로 무언가 생산의 컨베이어 화는 산업 혁명을 일으켰고 인류의 산업화를 수반했습니다.
핸드메이드는 "절차 없이 코드를 작성하는 것"입니다.
파이프라인은 파이프라인의 많은 요소가 나머지 요소에 의존하는 "절차적 코딩"입니다. 저것들. 한 요소를 변경하려면 다른 요소를 변경해야 할 수 있습니다.
"OOP 프로그래밍"은 요소 간의 종속성이 감소된 파이프라인입니다. 저것들. 한 요소를 다른 요소로 교체할 수 있으며 파이프라인이 실패할 가능성이 적습니다. 모든 생산을 독립적인 부품으로 나누는 능력, 표준 도입 등 객체 지향 제조(프로그래밍 아님)입니다.
프로그래밍 자체는 생산의 특별한 경우입니다. OOP 접근 방식은 무엇이든 생성하는 원칙적인 접근 방식입니다. 따라서 프로그래밍에 대해 이야기하는 것은 매우 좁습니다. OOP는 프로그래밍에 나타나기 전에 성공적으로 적용되었습니다.
가마솥으로 얻었습니다. 나는 동화를 생각해 내고 그것을 믿었습니다) 산타 클로스의 아이처럼 골리)
네, 부러워요, 레흐!
꽤 진지하게. 글쎄, 약간의 예술적 과장에 대한 권리를 나에게 남겨주세요 ...
주어진 절차에서 신체 움직임의 수 ...
오! 잘했다.
전적으로 지지합니다.
위 절차 코드의 제스처 수는 변경해야 하는 경우 더 많이 필요합니다.
예, 원칙적으로 OOP를 사용한 제스처의 수는 더 적을 수 없습니다. 이러한 모든 인터페이스는 종종 로직 자체를 작성하는 비용을 초과하는 추가 오버헤드 비용이기 때문입니다. 그리고 이것은 모든 기능에 이미 인터페이스가 있음에도 불구하고, 즉 본질적으로 의미가 없는 정원을 하나 더 울타리로 묶는 것이 제안됩니다.
동시에 인터페이스와 기능 모두에서 코드가 변경되면 하나가 다른 하나에 연결되기 때문에 훨씬 더 복잡해집니다. 즉, 가능한 버그 수와 노동 강도가 최소한 2차 증가합니다. ... 분명한 것 같습니다.