몇 년 전 PHP5가 프로세스 지향 언어에서 객체 지향 언어로 바뀌면서 다양한 기술 포럼에서 큰 반향을 일으켰습니다. 많은 사람들이 PHP가 스스로 멸망할 것이라고 주장했지만, 대부분의 사람들은 사태가 진정되었습니다. 사람들은 이를 지원하지 않았다가 지원하게 되었습니다. PHP는 4.0 시대에 농담으로 아이들의 장난감으로 불렸던 것에서 Java와 C에 이어 세 번째로 큰 언어가 되었습니다. 전체 토론에 참여하면서 저는 객체 지향에 대해 완전히 이해했다고 생각했고 점차 객체 지향 프로그래밍을 완전히 채택하기 시작했습니다. 2008년 이후에는 zend 프레임워크에서만 프로그램을 작성하기 시작했습니다.
그래서 앞으로는 프로젝트를 선택할 때 기술에만 의존하기보다는 좀 더 적합한 아키텍처를 선택할 수 있도록 PHP 프로그래밍에 대한 이해를 다시 정리하기로 했습니다. 벽돌을 만드는 모든 분들을 환영합니다.
1. 기능의 역할
오늘은 컴퓨터 전공이 아닌 친구라도 중국에서는 기본적으로 컴퓨터 언어를 배웠을 텐데요. 다행히 C일 수도 있습니다. Branch문과 루프문은 필수입니다. 함수를 잘 배우지 못한다면 아마 방심해서 합격할 것입니다. 세상에 기능 같은 것이 없더라도 프로그램은 여전히 모든 기능을 완료할 수 있습니다(안타깝습니다. 지난 몇 달 동안 그런 프로젝트를 본 적이 있습니다).
그렇다면 우리에게 필요한 기능은 무엇인가요? 수많은 교과서에서 재사용을 위한 것이라고 말합니다. 네, 함수를 작성한 후 다음에 같은 함수를 사용하면 다시 작성할 필요 없이 바로 호출하면 됩니다. 이것이 함수 발명의 본래 의도이자 기본 기능입니다. 하지만 덜 일반적으로 사용되는 기능이 예상된다면 해당 기능을 사용하면 안 될까요? 아니요, 프로세스 지향 프로그래밍을 채택하더라도 여전히 함수를 최대한 많이 사용하고, 함수를 최대한 세분화하고, 각 함수에 대해 독립적인 함수를 작성해야 합니다. 함수형 프로그래밍을 사용하면 다음과 같은 확실한 이점이 있습니다.
명확한 논리. 아무리 복잡한 함수라도 여러 개의 단일 함수로 세분화되고 세분화되면 각 단일 함수의 논리는 걱정할 필요 없이 논리에 따라 쉽게 작성할 수 있습니다. >
테스트가 쉽습니다. 함수를 사용하여 프로그램을 작성하면 실제로 프로그램이 자연스럽게 중단됩니다. 어떤 코드에 오류가 있는지 빨리 알 수 있습니다. 모든 프로그래머는 코드를 테스트하는 데 소요되는 시간이 일반적으로 코드 작성에 소요되는 시간의 두 배, 심지어 세 배라는 것을 알아야 합니다.
가독성이 좋습니다. 프로그램을 일정 기간 작성한 후 고객이 이를 사용하거나 기능을 변경해야 할 경우 문제를 발견하게 되며, 프로그래머는 자신이 작성한 코드조차 명확하게 기억하지 못할 수 있으며, 주로 함수로 작성된 프로그램을 읽을 경우, 메인 프로그램은 기본적으로 개요이며, 메인 프로그램의 컨텍스트를 따라 해당 기능을 빠르게 찾을 수 있습니다.
재사용이 용이합니다. 일반적으로 함수는 완료되면 테스트를 거쳐야 하며, 그 시점에서 더 주의를 기울이면 함수 설명에 따라 언제든지 함수를 호출할 수 있습니다. 세부 사항에주의를 기울이십시오.
빠르게 수정되었습니다. 때로는 일부 기능 수정을 피할 수 없습니다. 여러 프로그램에서 동일한 기능 함수를 호출할 때 이 함수를 수정하면 모든 것이 동시에 변경되므로 더 이상 하나씩 수정할 필요가 없습니다.
위의 장점 때문에 프로세스 지향 프로그래밍에 함수를 사용하는 것은 모든 사람이 인정하는 방법입니다. 어떤 포럼에서도 이에 대해 질문하는 사람을 본 적이 없습니다.
2. 코드 주석
많은 사람들의 습관과는 다르게 댓글이 많은 것을 좋아하며, phpdocument 표준을 준수하는 주석입니다. 이렇게 저나 제 동료들이 zend studio나 netbeans 같은 전문 에디터로 코드를 열고 첫글자를 입력하면 제가 작성한 함수와 메소드가 자동으로 뜨면서 함수의 함수를 보실 수 있습니다. , 사용법 및 중국어로 설명된 매개변수입니다. 모든 프로그래머는 가능한 한 많은 코드 주석을 갖고 싶어하지만 많은 사람들이 직접 주석을 작성하는 경우는 거의 없습니다. 포럼과 QQ 그룹에서 일부 주석을 배웠고 이것이 아마도 게으름으로 인한 것이 아니라는 것을 알았습니다. 실업과 기본적인 자신감 부족으로 인해 자신의 지위 안정을 보장하기 위해 다른 사람이 인수하기 어려울 것으로 예상됩니다.
마지막으로 객체지향 프로그래밍의 기본 방법에 대해 이야기해 보겠습니다. 클래스에서는 변수 속성과 메서드라는 함수를 호출합니다. 외국인들은 항상 새로운 개념을 제안할 때마다 이렇게 이름을 붙이는 것을 좋아합니다. 문제는 우리가 속성과 메서드를 언급할 때 항상 변수와 함수에 관해 이야기하는 사람들보다 우리가 더 지식이 풍부해 보였다는 것입니다. 물론 본질적으로 그들은 똑같은 것입니다.
클래스를 사용하는 이유는 무엇입니까? 개인적인 이해에 따르면 이는 주로 변수의 범위 때문입니다. 전역 변수의 보안은 C 언어 입문 튜토리얼에서 언급한 바 있습니다. 취약점과 해커에 취약할 뿐만 아니라, 자신의 코드를 작성할 때 동일한 이름 때문에 다양한 기대를 갖게 되는 경우가 더 많습니다. 전역 변수입니다. 문제 없습니다. 매개 변수와 함께 각 변수를 전달하면 번거로울 것입니다. Netbeans와 같은 훌륭한 프로그래밍 도구 덕분에 실제로 이러한 변수를 수동으로 입력할 필요가 없으며 단지 불만스러운 표정으로 바라볼 뿐입니다. 분명히 대부분의 함수나 최소한 함수들의 집합에서 사용하는 변수이지만, 값을 반복해서 전달해야 한다는 것은 늘 불편함을 느끼게 됩니다. 그래서 클래스가 있는데, PHP5.0 이후에는 클래스에서 속성(변수)과 메소드(함수)의 범위를 자세하게 정의할 수 있습니다.
동시에 클래스 사용의 또 다른 기본 이점은 기능을 그룹화할 수 있다는 것입니다. 함수가 충분하면 찾기가 어려울 것입니다. 다른 함수에 의해서만 호출되고 사용자가 직접 호출할 필요가 없는 메소드는 동료가 실수로 호출하는 것을 방지하기 위해 간단히 비공개로 설정할 수 있습니다. 이러한 방식으로 공용 함수 라이브러리는 여러 클래스로 완전히 분해됩니다.
클래스의 기본 기능은 보편적인 가치를 지닌 경우가 많습니다. 자체 속성 값이 있는 함수 그룹을 걱정하지 않고 한 프로젝트에서 다른 프로젝트로 클래스를 복사할 수 있습니다. 범위는 이를 수행할 수 없습니다.
여기서 명확히 해야 할 한 가지 문제는 많은 사람들이 함수 라이브러리를 여러 함수로 나누면 프로그램 속도가 빨라질 것이라고 잘못 믿고 있다는 것입니다. 각 페이지는 자신이 사용하는 함수만 호출한다는 것입니다. 해당 함수 라이브러리나 클래스의 파일 용량이 작을수록 당연히 속도는 빨라집니다. 실제로 실제 상황은 그 반대입니다. 컴퓨터를 사용할 때 WORD 파일을 처음 열면 속도가 느려질 수 있지만, 잠시 후 두 번째로 열면 속도가 훨씬 빨라집니다. 이는 WORD 파일과 WORD 소프트웨어 자체가 메모리에 캐시되어 있기 때문입니다. 마찬가지로, 함수 라이브러리의 크기에 관계없이 페이지가 처음 호출될 때 캐시되며, 동시에 페이지에 원래 포함되어 있으면 자연스럽게 다시 여는 속도가 훨씬 빨라집니다. 함수 라이브러리를 분해한 후 여러 파일을 포함해야 하고 파일 검색이 로드하는 것보다 더 많은 시간이 소요됩니다. 따라서 캐시 없이 페이지를 열더라도 함수 라이브러리를 분해하면 프로그램의 실행 속도가 느려집니다. , 클래스 인스턴스화에도 일정 시간이 걸립니다. 물론 오늘날의 컴퓨터 하드웨어에서는 이러한 속도 손실이 전혀 무시할 수 있는 정도입니다. 따라서 하드웨어의 개발도 객체지향 프로그래밍이 인기를 얻는 기반 중 하나입니다.
따라서 프로세스 지향 프로그램에서는 여전히 클래스를 사용합니다. 물론 프로세스 지향 프로그램에서는 클래스가 세 가지 상황에서만 필요합니다.
함수 라이브러리가 사람들을 현기증나게 만들 정도로 프로젝트가 큽니다.
우리가 작성한 특정 함수가 보편적이라는 것을 알게 되면
우리는 클래스 또는 오픈 소스 클래스 전에 작성한 함수를 호출합니다. 다른 사람이 온라인에 게시했습니다.
간단한 클래스를 사용해도 웹사이트가 객체지향적이라고 주장할 수 없습니다. 이 게시물의 제목 뒤에 "(1부)"를 추가했습니다. 즉, 이 기사의 나머지 부분에서는 물론 프로세스 지향 프로세스에 사용할 수 있는 기술에 대해서만 설명하겠습니다. 객체 지향에도 적합합니다. 다음 포스팅에서는 객체지향에 대한 나의 이해를 표현하겠습니다.
4. 템플릿
한 번도 사용해본 적이 없더라도 그 유명한 스마티는 한번쯤은 들어보셨을 겁니다. 처음 xoops를 통해 알게 됐어요. 당시에는 간단한 게시판만 하고 있었기 때문에 SMARTY를 배우는 데는 많은 노력이 필요했습니다. 그때 발견한 최고의 SMARTY 온라인 튜토리얼이 빅브라더의 스마트티 튜토리얼이었던 것으로 기억합니다. 얼마 후 조이 인터내셔널 빌리지의 형제들이 협력하여 스마트티 문서 전체를 번역하기로 결정했습니다. 포기하세요, 왜냐하면 저는 {$x}와 사이에 차이가 없다고 주장하기 때문입니다. 소위 템플릿인 include로 몇 글자를 절약할 수 있습니다. 나는 그렇게 큰 것을 사용합니다. 그것은 꽤 가치가 없습니다. 음, 제가 사용한 간단한 PHP 템플릿 사용법에 대한 설명은 다음과 같습니다. 아, 지금도 가끔 사용합니다:
文件demo.php： 48 49 view plaincopy to clipboardprint? 50 <?php 51 $userName='张三'; 52 include_once 'templates/demo.phtml'; 53 ?> 54 <?php 55 $userName='张三'; 56 include_once 'templates/demo.phtml'; 57 ?> 58 文件demo.phtml: 59 60 view plaincopy to clipboardprint? 61 <html> 62 ...... 63 <body> 64 你好，<?php echo $userName;?> 65 </body> 66 </html> 67 <html> 68 ...... 69 <body> 70 你好，<?php echo $userName;?> 71 </body> 72 </html>
보세요, 어떤 기술도 사용하지 않고, 그냥 템플릿 아닌가요? 한동안 포럼에서 스마티에 대한 논의가 있을 때마다 내 아이디어를 홍보하고 싶었지만, 아쉽게도 재작년까지만 해도 cakephp가 중국에 소개됐다. 그 후 Zend는 PHP를 기본 템플릿으로 사용하는 자체 프레임워크를 출시했습니다. 같은 해에 smarty는 더 이상 PHP의 핵심 하위 프로젝트로 개발되지 않았습니다. http://smarty.php.net에서 확인할 수 있습니다. 알림:
76
77 Smarty는 더 이상 PHP 프로젝트의 하위 프로젝트가 아니며 이후 자체 도메인으로 이동했습니다. www.smarty.net
78
79 따라서 페이지와 프로그램을 분리하는 것은 반드시 필요합니다. 하지만 스마티로 대표되는 템플릿 기술은 오픈소스 프로그램이나 셀프를 만들지 않는 이상 필요하지 않습니다. -서비스 웹 사이트 구축에는 템플릿의 보안을 제어할 방법이 없으며, 그렇지 않으면 템플릿을 전혀 사용할 필요가 없습니다.
80
81 5. 정적 페이지 생성 VS 캐싱 + 의사 정적
82
83 처음 PHP로 웹사이트를 구축하기 시작했을 때 9466이라는 A CMS 시스템을 사용했는데, 그 안에 들어있는 정적 HTML 생성 기술이 저를 놀라게 했습니다. 비록 당시 버전은 아직 기능적으로 부족한 부분이 많았지만, 여전히 수정하고 익히기 위해 많은 노력을 기울였고, 수정 사항이 게시되었습니다. 온라인에서 놀라운 점은 제가 방금 "9466 slime 수정 버전"을 검색했는데 실제로 다운로드를 제공하는 웹사이트가 많이 있다는 것입니다. 2006년에 제가 한 회사의 웹사이트를 만들었고 URL은 http://www.nbssdz .com입니다. 이번에는 처음부터 CMS를 작성하고 정적 페이지를 생성하는 기술도 사용했습니다. 그러나 이제 저는 더 이상 이 기술을 사용하지 않습니다. joomla, phpwind, discuz 및 zend 프레임워크와 같은 오픈 소스 프로그램은 의사 정적이라는 또 다른 기술 시연을 제공합니다.
84
85 정적 페이지를 생성하면 두 가지 이점이 있습니다. 하나는 웹사이트 액세스 속도를 높이고 서버 부하를 줄이는 것입니다. 다른 하나는 검색 엔진을 최적화하고 검색 엔진에 더 많은 페이지를 포함시킬 수 있다는 것입니다. 이 사이트의. 정적 페이지의 단점은 물론 "정적"이라는 것입니다. 말도 안되는 소리처럼 들리지만, 다양한 사용자 권한에 따라 다른 콘텐츠를 표시하는 등 정적 페이지에서는 많은 동적 기능을 구현할 수 없습니다. 따라서 이제 의사 정적(pseudo-static)이 대중화되고 있습니다. 이름에서 알 수 있듯이 의사 정적 기능은 검색 엔진에 포함되도록 동적 페이지에 대한 정적 URL을 위조하는 것입니다. 내 웹사이트 http://www.10000j.com은 zend 프레임워크를 기반으로 작성되었으므로 자연스럽게 의사 정적 기능을 갖습니다. 물론, 기본적으로 URL 디렉토리 형식은 너무 깊어서 포함하기에 적합하지 않습니다. 내 다른 웹사이트 작업은 다음과 같습니다. http://czj.kiloweb.cn 디렉토리 형식은 사용자 정의가 매우 유연하다는 것을 알 수 있습니다. 물론, 의사 정적 페이지의 서버 로드는 정적 페이지보다 높을 뿐만 아니라 일반 동적 페이지보다 높기 때문에 웹 사이트 응답 속도를 향상하려면 캐싱을 유연하게 사용해야 합니다. 응답속도 측면에서는 장점이 없습니다.
86
87 따라서 기능 요구 사항이 거의 없는 기존 콘텐츠 게시 카테고리와 서버 과부하가 있는 웹 사이트의 경우 정적 페이지 생성 기술을 사용할 수 있으며 권한 및 클릭 계산 기능이 있는 웹 사이트의 경우에도 여전히 사용할 수 있습니다. 장기간 유지관리가 필요한 웹사이트, 자주 추가되는 기능, 심지어 독립 서버가 필요한 웹사이트의 경우에는 의사정적(Pseudo-Static) 기술을 사용해야 합니다. 결국 일부 기능은 정적 페이지에서 실현될 수 없습니다. 일부 기능이 이를 달성하기 위한 "방법 찾기"(예: ajax 및 iframe을 통해)가 가능하더라도 "방법 찾기"에 드는 시간 비용이 너무 높습니다.
88
89 6. Ajax
90
91 Ajax는 흥미로운 기술이지만 AJAX의 불편한 점은 웹 사이트의 코드 양이 너무 많다는 것입니다. 크게 증가했습니다. 최근 프로젝트에서는 페이지가 gb2312를 사용했고 제가 사용했던 jquery 프레임워크의 load() 함수는 utf8만 지원했기 때문에 iframe을 사용해야 했고 그러다가 알게 되었습니다. 음, 사용하고 나니 이게 좀 마술적이네요. 수년 동안 iframe을 사용하고 거의 2년 동안 jquery를 사용한 후에 iframe이 실제로 나쁘지 않고 훨씬 적은 코드를 작성할 수 있다는 것을 알게 되었습니다. 지난 1년여 동안 저는 상사를 우울하게 만드는 많은 일을 하기 위해 jquery를 사용했습니다. 고객이 한 번도 요청한 적이 없는 몇 가지 특수 효과를 만들었습니다. 단지 기술적으로 더 눈부셔서 많은 시간을 낭비하고 jquery를 이해하지 못하는 사람들을 만들게 만듭니다. 아티스트와 상사가 직접 수정할 방법이 없습니다. 그래서 제가 말씀드리고 싶은 것은 ajax는 아주 좋은 것이고, jquery는 일류 ajax 프레임워크입니다. 필요해요, 아까 말한 걸 묻기보다 시간이란 필요가 있으면 써야 하고, 필요가 없으면 만들어내면 되는 거잖아요.
92
93 7. xml 및 json
94
95 포럼을 자주 방문하면 인기 있는 기술의 개발 동향을 항상 확인할 수 있다는 장점이 있습니다. 예를 들어 재작년 어느 날 갑자기 많은 사람들이 XML 대신 json을 사용하여 제안하기 시작했습니다. 나는 이 제안을 두 손으로 지지한다. json을 사용하면 액세스 속도가 향상될 뿐만 아니라 개발 효율성도 크게 향상됩니다. json_encode()
96 , json_decode()는 두 개의 간단한 함수로 쉽게 PHP 배열과 json을 직접 변환할 수 있으며 이는 simplexml 및 dom보다 훨씬 편리합니다. 따라서 대부분의 경우 Google의 사이트맵이나 RSS를 만들지 않고 단지 jquery에 값을 전달하기만 하면 됩니다. xml을 사용할 필요는 없습니다.
위 내용은 PHP 프로그래밍 방법에 대한 재고(1부) 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지를 참고해주세요. (www.php.cn)!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
