예, 원칙적으로 OOP를 사용한 제스처의 수는 더 적을 수 없습니다. 이러한 모든 인터페이스는 종종 로직 자체를 작성하는 비용을 초과하는 추가 오버헤드 비용이기 때문입니다. 그리고 이것은 모든 기능에 이미 인터페이스가 있음에도 불구하고, 즉 본질적으로 의미가 없는 정원을 하나 더 울타리로 묶는 것이 제안됩니다.
동시에 인터페이스와 기능 모두에서 코드가 변경되면 하나가 다른 하나에 연결되기 때문에 훨씬 더 복잡해집니다. 즉, 가능한 버그 수와 노동 강도가 최소한 2차 증가합니다. ... 분명한 것 같습니다.
터미널은 코드와 관련된 클래스입니다. 얼마나 자주 터미널 코드에서 무엇인가를 변경해야 합니까? 이는 사용자에게 숨겨져 있고 공개 메소드(프로그램 구현을 위한 기능)만 제공됩니다.
예, 원칙적으로 OOP를 사용한 제스처의 수는 더 적을 수 없습니다. 이러한 모든 인터페이스는 종종 로직 자체를 작성하는 비용을 초과하는 추가 오버헤드 비용이기 때문입니다. 그리고 이것은 모든 기능에 이미 인터페이스가 있음에도 불구하고, 즉 본질적으로 의미가 없는 정원을 하나 더 울타리로 묶는 것이 제안됩니다.
동시에 인터페이스와 기능 모두에서 코드가 변경되면 하나가 다른 하나에 연결되기 때문에 훨씬 더 복잡해집니다. 즉, 가능한 버그 수와 노동 강도가 최소한 2차 증가합니다. ... 분명한 것 같습니다.
프로그래밍 자체는 생산의 특별한 경우입니다. OOP 접근 방식은 무엇이든 생성하는 원칙적인 접근 방식입니다. 따라서 프로그래밍에 대해 이야기하는 것은 매우 좁습니다. OOP는 프로그래밍에 나타나기 전에 성공적으로 적용되었습니다.
산업 형성의 역사는 파이프라이닝의 다음 단계로 객체 지향 MANUFACTURING에 왔습니다. 따라서 객체지향 프로그래밍에 대해 이야기하는 것은 좁은 관점입니다. 부츠의 OO 재봉에 대해 이야기하는 방법. 우리는 매우 특별한 경우로 소프트웨어 생성을 포함하여 모든 프로덕션 조직에 대한 알고리즘 접근 방식에 대해 이야기하고 있습니다.
OOP 프로덕션은 경쟁에서 기존 파이프라인보다 우수함을 입증했습니다. 당장 실행에 옮기는 것이 필요할 때 단기 생산 계획이 있습니다. 그리고 현재 많은 "잉여"가 놓여 있지만이 기초가 단순한 생산 규모 확장에 기여하는 장기적인 것이 있습니다. 다시 말하지만 이것은 프로그래밍에 관한 것이 아니라 프로덕션을 만드는 일반적인 접근 방식에 관한 것입니다.
예가 잘못되었습니다. 우리는 우리 프로그램 내의 인터페이스에 대해 이야기하고 있습니다 ...
왜 "틀리다"?
프로그램은 컴퓨터에서 실행되는 모든 소프트웨어와 어떻게 다릅니까?
결국 이것은 모든 사용자 프로그램에서와 동일한 일련의 명령 및 데이터 배열입니다. 그것이 잘못된 이유는 무엇입니까? 설정된 교환 프로토콜을 통하지 않고 소프트웨어의 한 부분이 소프트웨어의 다른 부분에 액세스할 수 없다는 것이 무엇입니까?
진지하게 프로그래밍하면 괜찮습니다. 조만간 액세스 권한을 차별화해야 할 필요성에 직면하게 될 것입니다.
저도 실제 모드에서 보호 모드로 전환하던 시절에 물리적 메모리 주소를 사용할 수 없다는 것이 정말 마음에 들지 않았습니다. 보호된 시스템 영역에서 내 영역으로 데이터를 복사하는 DMA 컨트롤러를 엉망으로 만들기까지 했습니다. 내가 어렸을 때 나는 분개했습니다 - 어때요, 직접 액세스 할 수 없습니다 - 이것은 거의 내 권리를 침해하는 것입니다 ... 그리고 프로그램에서 내가 액세스 할 수없는 것을 허용합니까 ???
경험을 쌓으면서 나는 액세스 권한의 차별화가 프로그래머 자신에게 이익이 된다고 한 번 이상 확신하게 되었습니다. 이렇게 하면 작성된 모듈에 오류가 발생하는 것을 여러 번 방지할 수 있기 때문입니다. 당신은 수업을 듣고 그것을 사용하고 싶지만 일부 데이터에 액세스 할 수 없습니다 ... 당신은 분노하지만 어떻습니까, 이해를 시작해야합니다 ... 그리고 oops ... 거기에 밝혀졌습니다. , 고려해야 할 순간이 있고 데이터에 직접 액세스할 수 없습니다. 이에 대한 "회전 교차로"가 있습니다. 시스템 아키텍처는 직접 연락하여 잘못된 데이터를 얻을 수 있습니다. 그러나 나는 할 수 있고 유효합니다. 모든 것은 시간의 순간에 달려 있습니다. 그리고 그러한 오류는 계산하기가 매우 어려울 것입니다.
여기서 가장 간단한 질문은 캐시의 데이터에 액세스하는 것입니다. 캐시된 데이터가 필요하고 직접 액세스하는 경우 올바른 데이터를 얻을 수 있습니까? 권한 제한이 없는 절차적 접근 방식에서는 액세스할 수 있는 시기, 액세스할 수 없는 시기, 데이터가 유효한 시기, 그렇지 않은 경우를 파악해야 합니다. OOP 접근 방식에서는 모든 것이 매우 간단하고 액세스 권한이 없습니다. 캐시 데이터의 경우 필요한 데이터를 반환 하는 함수만 호출 할 수 있으며 동시에 유효한지 확인하고 유효하지 않은 경우 유효한 데이터를 로드합니다. "더 어렵다"??? 이제 작성하고 1년 후에 이 캐시를 사용한다고 상상해 보십시오. 캐시를 업데이트하고 유효성을 결정하는 원칙을 완전히 잊어버렸을 때. OOP 접근 방식에서는 신경 쓰지 않습니다. 클래스 기능은 모든 것을 제공합니다. 그리고 기능적 접근 방식에서는 캐시가 업데이트되는 시기와 방법, 캐시에 있는 데이터가 유효한 경우와 그렇지 않은 경우를 자세히 기억해야 합니다.
예가 잘못되었습니다. 우리는 우리 프로그램 내의 인터페이스에 대해 이야기하고 있습니다 ...
더 정확한 것은 없습니다. 계층 구조입니다.
OOP 접근 방식의 프로그램 은 클래스의 공용 메서드를 보고 해당 구성 요소에 대해 생각하지 않고 사용합니다. 뿐만 아니라 언어의 표준 기능을 사용합니다. 프로그램을 변경할 때 클래스를 변경할 필요가 없습니다. 절차적 접근 방식으로 표준 언어 기능을 변경할 필요가 없는 것처럼.
예, 원칙적으로 OOP를 사용한 제스처의 수는 더 적을 수 없습니다. 이러한 모든 인터페이스는 종종 로직 자체를 작성하는 비용을 초과하는 추가 오버헤드 비용이기 때문입니다. 그리고 이것은 모든 기능에 이미 인터페이스가 있음에도 불구하고, 즉 본질적으로 의미가 없는 정원을 하나 더 울타리로 묶는 것이 제안됩니다.
동시에 인터페이스와 기능 모두에서 코드가 변경되면 하나가 다른 하나에 연결되기 때문에 훨씬 더 복잡해집니다. 즉, 가능한 버그 수와 노동 강도가 최소한 2차 증가합니다. ... 분명한 것 같습니다.
예, 원칙적으로 OOP를 사용한 제스처의 수는 더 적을 수 없습니다. 이러한 모든 인터페이스는 종종 로직 자체를 작성하는 비용을 초과하는 추가 오버헤드 비용이기 때문입니다. 그리고 이것은 모든 기능에 이미 인터페이스가 있음에도 불구하고, 즉 본질적으로 의미가 없는 정원을 하나 더 울타리로 묶는 것이 제안됩니다.
동시에 인터페이스와 기능 모두에서 코드가 변경되면 하나가 다른 하나에 연결되기 때문에 훨씬 더 복잡해집니다. 즉, 가능한 버그 수와 노동 강도가 최소한 2차 증가합니다. ... 분명한 것 같습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
마운드에서 OOP에 대해 이야기하기
fxsaber , 2018.01.14 11:35
프로그래밍 자체는 생산의 특별한 경우입니다. OOP 접근 방식은 무엇이든 생성하는 원칙적인 접근 방식입니다. 따라서 프로그래밍에 대해 이야기하는 것은 매우 좁습니다. OOP는 프로그래밍에 나타나기 전에 성공적으로 적용되었습니다.
산업 형성의 역사는 파이프라이닝의 다음 단계로 객체 지향 MANUFACTURING에 왔습니다. 따라서 객체지향 프로그래밍에 대해 이야기하는 것은 좁은 관점입니다. 부츠의 OO 재봉에 대해 이야기하는 방법. 우리는 매우 특별한 경우로 소프트웨어 생성을 포함하여 모든 프로덕션 조직에 대한 알고리즘 접근 방식에 대해 이야기하고 있습니다.
OOP 프로덕션은 경쟁에서 기존 파이프라인보다 우수함을 입증했습니다. 당장 실행에 옮기는 것이 필요할 때 단기 생산 계획이 있습니다. 그리고 현재 많은 "잉여"가 놓여 있지만이 기초가 단순한 생산 규모 확장에 기여하는 장기적인 것이 있습니다. 다시 말하지만 이것은 프로그래밍에 관한 것이 아니라 프로덕션을 만드는 일반적인 접근 방식에 관한 것입니다.
OOP 접근 방식은 현대 권력 기관에서도 추적할 수 있습니다.
터미널은 코드와 관련된 클래스입니다. 얼마나 자주 터미널 코드에서 무언가를 변경해야 합니까?
예가 잘못되었습니다. 우리는 우리 프로그램 내의 인터페이스에 대해 이야기하고 있습니다 ...
산업 형성의 역사는 파이프라이닝의 다음 단계로 객체 지향 MANUFACTURING에 왔습니다.
OO 프로그래밍에는 자체 데이터 처리 파이프라인도 있으며 OOP는 각 개별 파이프라인과 전체 프로덕션의 오버헤드만 증가시키는 또 다른 수준의 추상화를 도입합니다.
OO 프로그래밍에는 자체 데이터 처리 파이프라인도 있으며 OOP는 각 개별 파이프라인과 전체 프로덕션의 오버헤드만 증가시키는 또 다른 수준의 추상화를 도입합니다.
불행히도 당신은 멍청합니다. 당신은 산업의 역사와 이 역사의 한 단계로서 당신 주변에 있는 모든 물질(뿐만 아니라)에서 큰 역할을 한 OOP에 대해 들었습니다. 그리고 당신은 프로그래밍의 특별한 경우에 대해 계속 이야기하고 있습니다.
인간 발달의 역사에 대한 무지. 직계 후손의 기억에 흔적을 남기지 마십시오.
당신은 산업의 역사와 이 역사의 한 단계로서 당신 주변에 있는 모든 물질(뿐만 아니라)에서 큰 역할을 한 OOP에 대해 들었습니다.
OOP를 산업의 역사로 끌어들이려는 순진한 시도는 재미있지만 불행히도 문맹입니다.
예가 잘못되었습니다. 우리는 우리 프로그램 내의 인터페이스에 대해 이야기하고 있습니다 ...
왜 "틀리다"?
프로그램은 컴퓨터에서 실행되는 모든 소프트웨어와 어떻게 다릅니까?
결국 이것은 모든 사용자 프로그램에서와 동일한 일련의 명령 및 데이터 배열입니다. 그것이 잘못된 이유는 무엇입니까? 설정된 교환 프로토콜을 통하지 않고 소프트웨어의 한 부분이 소프트웨어의 다른 부분에 액세스할 수 없다는 것이 무엇입니까?
진지하게 프로그래밍하면 괜찮습니다. 조만간 액세스 권한을 차별화해야 할 필요성에 직면하게 될 것입니다.
저도 실제 모드에서 보호 모드로 전환하던 시절에 물리적 메모리 주소를 사용할 수 없다는 것이 정말 마음에 들지 않았습니다. 보호된 시스템 영역에서 내 영역으로 데이터를 복사하는 DMA 컨트롤러를 엉망으로 만들기까지 했습니다. 내가 어렸을 때 나는 분개했습니다 - 어때요, 직접 액세스 할 수 없습니다 - 이것은 거의 내 권리를 침해하는 것입니다 ... 그리고 프로그램에서 내가 액세스 할 수없는 것을 허용합니까 ???
경험을 쌓으면서 나는 액세스 권한의 차별화가 프로그래머 자신에게 이익이 된다고 한 번 이상 확신하게 되었습니다. 이렇게 하면 작성된 모듈에 오류가 발생하는 것을 여러 번 방지할 수 있기 때문입니다. 당신은 수업을 듣고 그것을 사용하고 싶지만 일부 데이터에 액세스 할 수 없습니다 ... 당신은 분노하지만 어떻습니까, 이해를 시작해야합니다 ... 그리고 oops ... 거기에 밝혀졌습니다. , 고려해야 할 순간이 있고 데이터에 직접 액세스할 수 없습니다. 이에 대한 "회전 교차로"가 있습니다. 시스템 아키텍처는 직접 연락하여 잘못된 데이터를 얻을 수 있습니다. 그러나 나는 할 수 있고 유효합니다. 모든 것은 시간의 순간에 달려 있습니다. 그리고 그러한 오류는 계산하기가 매우 어려울 것입니다.
여기서 가장 간단한 질문은 캐시의 데이터에 액세스하는 것입니다. 캐시된 데이터가 필요하고 직접 액세스하는 경우 올바른 데이터를 얻을 수 있습니까? 권한 제한이 없는 절차적 접근 방식에서는 액세스할 수 있는 시기, 액세스할 수 없는 시기, 데이터가 유효한 시기, 그렇지 않은 경우를 파악해야 합니다. OOP 접근 방식에서는 모든 것이 매우 간단하고 액세스 권한이 없습니다. 캐시 데이터의 경우 필요한 데이터를 반환 하는 함수만 호출 할 수 있으며 동시에 유효한지 확인하고 유효하지 않은 경우 유효한 데이터를 로드합니다. "더 어렵다"??? 이제 작성하고 1년 후에 이 캐시를 사용한다고 상상해 보십시오. 캐시를 업데이트하고 유효성을 결정하는 원칙을 완전히 잊어버렸을 때. OOP 접근 방식에서는 신경 쓰지 않습니다. 클래스 기능은 모든 것을 제공합니다. 그리고 기능적 접근 방식에서는 캐시가 업데이트되는 시기와 방법, 캐시에 있는 데이터가 유효한 경우와 그렇지 않은 경우를 자세히 기억해야 합니다.
예가 잘못되었습니다. 우리는 우리 프로그램 내의 인터페이스에 대해 이야기하고 있습니다 ...
터미널은 코드와 관련된 클래스입니다. 얼마나 자주 터미널 코드에서 무엇인가를 변경해야 합니까? 이는 사용자에게 숨겨져 있고 공개 메소드(프로그램 구현을 위한 기능)만 제공됩니다.
+++))))
터미널은 코드와 관련된 클래스입니다. 얼마나 자주 터미널 코드에서 무엇인가를 변경해야 합니까? 이는 사용자에게 숨겨져 있고 공개 메소드(프로그램 구현을 위한 기능)만 제공됩니다.
이 필요성은 정기적으로 나타납니다. 개발자가 이 작업을 수행하는 것이 바람직합니다.
간단한 예입니다. 어떤 이유로 개발자는 지표 차트에 수평 좌표 그리드를 제공할 필요가 없다고 생각했습니다. 그리고 물론, 그들은 이에 대한 적절한 방법을 제공하지 않았습니다.)