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

새 코멘트
 
Dmitry Fedoseev :

아마도 이것은 모든 미결 주문과 모든 매개변수를 배열에 로드하는 합리적인 접근 방식이 아닙니다.


아마도 코드에 두 개의 이익 및 손절매 매개변수가 필요한 경우 주기를 두 번 실행하는 데 에너지가 소모됩니다.

이것은 보편적 인 코드이며, 초과 속도를 높이기 위해 마지막에서 잘라낼 수 있습니다 ...

 
Vladimir Pastushak :

단순화

그래서 나는 OOP를 싫어한다. 아무것도 이해할 수 없습니다. 댓글이 없습니다. 결국 무엇을해야합니까?
 
Реter Konow :
그래서 OOP를 싫어합니다. 아무것도 이해할 수 없습니다. 댓글이 없습니다. 결국 무엇을해야합니까?

이제 막 배우기 시작할까요?

 
Реter Konow :
그래서 OOP를 싫어합니다. 아무것도 이해할 수 없습니다. 댓글이 없습니다. 결국 무엇을해야합니까?

문제는 당신이 이해하지 못하지만 모든 주문이 포함 된 배열 구조를 가지고 있으며 어디서나 쉽게 호출된다는 것입니다. 동시에 무거운 사이클을 한 번만 운전합니다 ...

 
Dmitry Fedoseev :

이제 막 배우기 시작할까요?

루프에 있는 함수의 값으로 배열을 채웁니다 . 문제는 클래스 래퍼가 왜 필요한가 하는 것입니다. 기능을 통해 얻을 수 있습니다.
 
Реter Konow :
루프에 있는 함수의 값으로 배열을 채웁니다 . 문제는 클래스 래퍼가 왜 필요한가 하는 것입니다. 기능을 통해 얻을 수 있습니다.

함수 호출이 적을수록 코드가 빨라집니다.

 
Реter Konow :
루프에 있는 함수의 값으로 배열을 채웁니다 . 문제는 클래스 래퍼가 왜 필요한가 하는 것입니다. 기능을 통해 얻을 수 있습니다.

구조에 있어 매우 편리합니다. 배열을 여러 개 필요로 하고 개별적으로 크기를 조정할 필요가 없습니다. 이 예는 OOP의 장점을 보여주지 않고 모든 사람이 개인적으로 더 편리한 것을 할 뿐입니다.

 
Vladimir Pastushak :

문제는 당신이 이해하지 못하지만 모든 주문이 포함 된 배열 구조를 가지고 있으며 어디서나 쉽게 호출된다는 것입니다. 동시에 무거운 사이클을 한 번만 운전합니다 ...

내가 이해하지 못하는 이유를 이해합니다. 이것은 내 코드가 아니며 일부일 뿐입니다. 그러나 당신도 이해하지 못하는 것 같습니다 - 아니면 내가 틀렸습니까?
 
Dmitry Fedoseev :

여러분, 토론자 여러분, OOP를 이해하지 못한다면 이렇게 합시다. 그러면 OOP에 대한 절차적 프로그래밍이 아니라 함수 포인터가 있는 절차적 프로그래밍과 함수 포인터가 없는 절차적 프로그래밍에 대해 논합시다.

아니요, 당신의 모범은 아주 좋습니다.

절차적 프로그래밍에 관한 것이 아닙니다.

프로그램 품질에 대한 훨씬 더 중요한 기준이 있습니다. 바로 코드의 가시성입니다.

당신이 내린 결정은 끔찍합니다. 어떤 의미 있는 기능이 발생하는지 명확하지 않습니다. 나는 일반적인 스위치를 작성하고 각 호출에 대해 논평할 것입니다. 이것은 올바른 코드입니다.

귀하의 예에서 나는 OOP가 해로운 것이라고 결론지었습니다.

 
Vladimir Pastushak :

함수 호출이 적을수록 코드가 빨라집니다.

이것이 내가 큰 일반 코드 블록을 만드는 것을 좋아하는 이유입니다.
123456789101112131415...48
새 코멘트