이식 가능한 솔루션을 만들면 특정 작업에 적용할 때 반드시 어느 부분에서 중복됩니다. 더 보편적으로 만들려고 하면 할수록 중복 꼬리가 길어집니다. 이 이중화가 인코더와 제품의 수명을 나중에 복잡하게 만들지 않도록 제때 멈출 가치가 있습니다.
이 모든 것을 조합하는 방법, 왜 OOP로 전환하려고 합니까? 바로 이 OOP에 대한 찬사로 많은 기능을 수집하고 카탈로그화할 수 있다고 기록되어 있습니다. 이전에는 많은 기능이 있는 파일이 있었습니다. .. 다 정리할까 생각했는데, 혹시라도 별도의 옵션이 필요한 경우를 대비해서 라이브러리 디렉토리의 의미가 사라지고...
중복성을 피하기 위해 99%의 경우 여전히 모든 코드를 수동으로 작성해야 하는 것으로 나타났습니다... 처음부터 ...
글쎄, 나는 누군가가 더 나은 것을 알고 있다고 생각했습니다 ....
어디에도 없습니다. 더 빨리 필요하면 고문의 전체 알고리즘에 대해 생각할 필요가 있습니다. 각 틱 에서 두 개의 하단, 두 개의 상단을 찾는 필요성을 없앨 수 있습니다.
어디에도 없습니다. 더 빨리 필요하면 고문의 전체 알고리즘에 대해 생각할 필요가 있습니다. 각 틱에서 두 개의 하단, 두 개의 상단을 찾는 필요성을 없앨 수 있습니다.
변형에서 데이터는 동일합니다. 즉, 첫 번째 및 두 번째 상위 주문은 동일한 티켓을 갖게 됩니다.
빨리 미안...
내가 그랬어
보편적인 것을 하려고 하는 것보다 이러한 작업에 특별히 맞춰진 다양한 작업에 대한 기능을 수집하는 것이 좋습니다.
100%
이식 가능한 솔루션을 만들면 특정 작업에 적용할 때 반드시 어느 부분에서 중복됩니다. 더 보편적으로 만들려고 하면 할수록 중복 꼬리가 길어집니다. 이 이중화가 인코더와 제품의 수명을 나중에 복잡하게 만들지 않도록 제때 멈출 가치가 있습니다.
내가 그랬어
제대로 작동하는지 확인하셨나요?
100%
이식 가능한 솔루션을 만들면 특정 작업에 적용할 때 반드시 어느 부분에서 중복됩니다. 더 보편적으로 만들려고 하면 할수록 중복 꼬리가 길어집니다. 이 이중화가 인코더와 제품의 수명을 나중에 복잡하게 만들지 않도록 제때 멈출 가치가 있습니다.
이 모든 것을 조합하는 방법, 왜 OOP로 전환하려고 합니까? 바로 이 OOP에 대한 찬사로 많은 기능을 수집하고 카탈로그화할 수 있다고 기록되어 있습니다. 이전에는 많은 기능이 있는 파일이 있었습니다. .. 다 정리할까 생각했는데, 혹시라도 별도의 옵션이 필요한 경우를 대비해서 라이브러리 디렉토리의 의미가 사라지고...
중복성을 피하기 위해 99%의 경우 여전히 모든 코드를 수동으로 작성해야 하는 것으로 나타났습니다... 처음부터 ...
예))) ...
네. 표준.
그것이 내가 이 스레드를 만들면서 얻고자 했던 것입니다. 모두 감사합니다!
내가 아니라 OTC가 아닙니다. 테스터 또는 데모 계정의 주문에 대해 테스트하십시오. 얼핏 보면 틀릴 수도 있습니다.