당신이 진정한 고수임을 보여주기 위해 다양한 코드를 작성할 수 있나요? 틀렸습니다. 진정한 마스터는 가장 중요한 프로그래밍 사고와 기술을 가지고 있습니다. 비록 그가 지금 알고 있는 모든 기술이 구식이라 할지라도 그는 여전히 새로운 기술을 빠르게 익히고 고품질 프로그램을 작성할 수 있습니다.
오늘날의 프레임워크와 인기 있는 언어는 수많은 실용적인 데이터 구조와 일부 고전적인 알고리즘을 캡슐화하여 매우 편리합니다. .NET을 사용하면 웹사이트를 간단히 드래그 앤 드롭할 수 있지만 백그라운드 작업은 데이터베이스 바인딩, 처리가 가능합니다. 데이터를 수집하고 업데이트하는 작업은 다소 반복적이고 지루할 수 있습니다. 나중에 Linq와 thinkPHP(PHP의 MVC)를 접하게 되었는데, 이런 비기술적인 코드를 너무 많이 작성해도 여전히 그런 느낌이 듭니다. 혼자서 작은 프로그램을 작성하는 것보다 훨씬 낫습니다. 또는 미니 게임이 즐거움으로 다가옵니다.
우리 데이터 구조 선생님이 "알고리즘은 예술이다"라고 말씀하셨던 기억이 나네요. 그러자 거의 모든 학급이 경멸의 반응을 보였고, 저는 그 당시에 그 영광스러운 회원 중 하나였습니다. 그래서 자료구조에 대해 정말 뼈저리게 배웠고 많이 후회했습니다.
알고리즘 책에는 지뢰 찾기와 같은 고전 게임인 지뢰 찾기가 언급되어 있습니다. 핵심 알고리즘 중 하나는 각 그리드 주위에 지뢰가 몇 개 있는지 계산하는 것입니다.
2년 동안 프로그래밍을 해 온 사람들이라면 이런 알고리즘이 금방 떠오를 것 같습니다. 2차원 배열을 사용하여 각 그리드의 정보를 저장한 다음(물론 광산은 즉시 할당됩니다) 배열을 순회하고 계산합니다. 8개 방향으로 1개 지뢰를 횡단할 때 그 주변의 결과를 현재 횡단한 배열 항목에 저장합니다. 물론 통계 프로세스는 함수 호출로 작성될 수 있습니다. 이것은 생각하기 가장 쉬운 알고리즘입니다.
나중에 저는 이것이 약간 낭비라고 생각했습니다. 왜냐하면 주변에 지뢰가 없는 많은 그리드가 지뢰가 있는지 확인하기 위해 8방향으로 스캔해야 했기 때문입니다. 저는 그것에 대해 생각하기 시작했고, 제가 세고 싶었던 것은 각 주변의 지뢰의 수였습니다. 물론 지뢰이므로 여전히 2차원 배열을 순회하지만 지뢰를 순회할 때만 값이 나오는 두 번째 알고리즘을 생각하기 시작했습니다. 광산 주변 8개 방향의 그리드에서 +1이 되므로 통계량이 대폭 감소되었습니다. 이는 역발상으로 간주되어야 한다.
리리와 함께 체스 프로그램을 만들다 보면 다음 단계에서 내 장군이 먹힐지, 원수가 먹히는 상황인지 판단하는 '일반' 알고리즘을 만나게 된다(체스 용어로는 장군이라 부른다). 물론 매우 간단한 알고리즘은 상대방의 현재 존재하고 공격하는 체스 말을 탐색하여 다음 단계에서 그의 장군을 죽일 수 있는지 확인하는 것입니다. 하지만 반대로 생각해 볼 수도 있습니다. 장군이 죽임을 당한 상태인지 판단하는 것이기 때문에, 바로 그에게서 시작해서 상대가 있는지, '폰', '차', '대포'가 있는지 판단합니다. " 그의 직선 범위 내에서 그리고 우리 주변의 주변을 판단하십시오. 일본 그리드의 반대편에 "말"이 있다고 생각하십니까? 문제를 반대로 생각하십시오.
프로그래밍의 느낌
프로그래밍에서 가장 중요한 것은 일종의 생각입니다. 프로그래밍의 진정한 즐거움은 프로그램을 제공하기 위한 알고리즘을 설계하는 것입니다. 물론 알고리즘은 그 영혼입니다. 활력있는 프로그램 기분이 좋지 않거나 프로그래밍이 지루하다면 그것은 프로그래밍을 위한 프로그래밍이 아니라 소위 기술, 소위 방법과 패턴을 연습하고 있기 때문입니다.
무술 훈련이 동작과 뗄래야 뗄 수 없는 것처럼 프로그래밍도 기술과 뗄래야 뗄 수 없습니다.
고급 무술가들은 종종 최고 수준의 쿵푸는 마음에 움직임이 없을 때라고 말합니다. 그리고 이런 움직임이 없다는 것은 아무 것도 할 수 없다는 뜻이 아니라 수백 가지 사상파의 힘을 모아서 수천 가지 움직임을 통합한 후에 생각과 움직임과 몸이 고도로 통일되어 있다는 것을 의미한다. 원하는 대로 사용할 수 있습니다. 모든 동작을 학습한다고 해서 이 상태에 도달하는 것은 불가능합니다. 동작 사이의 내부 연결에 대해 생각하는 방법을 진정으로 알고 이를 자신의 생각에 천천히 통합해야만 이 상태를 달성할 수 있습니다.
일부 노련한 프로그래머들은 프로그래밍에서 가장 금기시되는 것이 너무 좋지 않고 너무 많은 것이라고 가르칩니다.
더 많이 안다고 해서 마스터가 되는 것은 아니며, 적게 안다고 해서 초보자가 되는 것은 아닙니다. 프로그래밍은 생각에 중점을 두고 있으며, 이 생각이 이 기술에 얼마나 깊이 들어가는지를 결정합니다.
생각이란? 문제를 해결하는 아이디어, 계획하는 능력, 분석하는 능력, 문제 해결을 위한 아이디어를 빠르게 정리하는 능력입니다. 이는 알고리즘, 패턴 또는 프레임워크일 수 있습니다.
이러한 아이디어에는 수년 이상의 경험이 필요합니다.
이제 객체지향적 사고가 대중화되었습니다. C의 수많은 함수 라이브러리부터 지금은 수많은 클래스 라이브러리(또는 Java의 패키지)에 이르기까지 이 아이디어에 대한 피상적인 이해를 간략하게 설명하겠습니다. Java를 배우든 C++를 배우든 가장 중요한 것은 C++와 Java를 사용하여 문제를 생각하는 것입니다. 문제를 처리하기 위해 객체를 기본 요소로 사용합니다.
저번에 면접보러 갔을 때 면접관님이 객체지향 상속, 다형성, 캡슐화 기능에 대해 얘기해달라고 하더군요.
저는 이 세 가지 특징을 분석하여 제가 작성한 간단한 탱크 전투 프로그램에 대해 그에게 말했습니다.
상속: 이 개념은 이해하기 매우 쉽습니다. 하위 클래스는 크기, 상태, 이동, 충돌 결정과 같은 기본 탱크 특성 및 방법을 구현하는 탱크의 기본 클래스와 같은 상위 클래스의 모든 공통 멤버를 상속합니다. 팬텀 탱크(Red Alert)와 같은 고유한 탱크는 나중에 탱크를 설계해야 하며 문제를 해결하려면 상위 클래스를 상속하고 팬텀 메서드를 추가하기만 하면 됩니다. 상속의 장점도 분명합니다. 탱크에 공통적인 특성과 방법은 대부분 기본 클래스에 기록됩니다. 향후에 새로운 유형의 탱크를 설계하려면 대부분의 코드를 제거하고 이를 상속하기만 하면 됩니다. . 따라서 상속은 가장 간단하고 실용적입니다.
다형성: 좁은 의미에서는 부모 클래스 메서드의 오버로딩으로 이해될 수 있으므로 동일한 메서드가 다른 매개변수 목록을 갖게 됩니다. 내 생각에 다형성은 객체지향의 핵심이다. 내 탱크 프로그램에는 제어 규칙 클래스가 있는데 이 클래스에는 매개변수가 필요한 메소드가 있다. 이 매개변수는 탱크 클래스일 수도 있고 총알 클래스일 수도 있다. 물론, move() 메서드를 호출해야 합니다. 물론 다음과 같은 강력한 오버로딩 기능을 사용할 수 있습니다. someFun (tank mObj) {….}; }; mObj 매개변수의 유형을 변경한 것 외에는 아무것도 변경되지 않은 것 같습니다. 그러나 그것은 문제를 해결했습니다. 이 비정상적인 메서드의 구현이 10,000줄이라면 하나의 오버로드는 20,000줄이 됩니다. 나중에 비행기 클래스에도 이동 메소드가 있으면 다시 로드해야 합니다. 상속 + 인터페이스를 사용하는 것이 훨씬 간단합니다. ImoveObj라는 인터페이스를 작성하고 그 안에 이동 메서드를 정의하면 됩니다. 이 인터페이스는 탱크, 총알 및 항공기 클래스에서 상속됩니다. }; 나중에 mObj 매개변수 역할을 할 수 있는 클래스가 아무리 추가되더라도 ImoveObj 인터페이스만 상속하면 됩니다. (팩토리 패턴을 사용해보신 분들은 너무 흔하다고 느끼시겠지만 사실 이것도 다형성에 대한 기본적인 이해이기도 합니다.)
캡슐화: 클래스를 사용하려면 사용법만 알면 이해하기 쉽습니다. 이 클래스의 메소드. 이 메소드의 구체적인 구현을 알 필요가 없습니다. 인터페이스는 개발자의 디자인 사양이며 개발자는 인터페이스에 있는 것들을 구현합니다. 인터페이스는 또한 클래스 사용자에게 이 클래스가 구현하는 메서드를 알려주는 사용자 지침이기도 합니다.
모두 간단한 기본이지만, 이것들을 완전히 이해하고 나면 주입, 역산, 매핑 등을 공부하는 것이 그리 어렵지 않을 것입니다.
객체 지향 외에도 인터페이스 지향, 측면 지향(Aspect) 등이 있습니다. 어떤 아이디어를 사용하여 프로그래밍하든 핵심은 함수만큼 작기 때문에 알고리즘과 뗄 수 없습니다. 연산.
프로그래밍에서 가장 중요한 것은 생각이고, 기술이 능력을 결정하고, 생각이 능력의 깊이를 결정합니다.