PHP 프로그래밍 방법 재고(2부)
- 黄舟원래의
- 2016-12-21 10:51:441147검색
이틀 동안 미루다가 오늘 밤 드디어 다음 장을 쓸 시간이 생겼습니다. 하지만 컴퓨터를 마주하면 어디서부터 시작해야 할지 모르겠습니다. 아마도 ZEND FRAMEWORK를 따르기만 하면 됩니다. 물론 핵심은 파악하겠지만, 이 글에서는 zend 프레임워크에 대한 소개 매뉴얼이 아니라 객체지향 프로그래밍에 대한 나의 이해를 설명하기 위한 예시로 zend 프레임워크를 사용한다는 점을 기억하세요. 튜토리얼이지만 객체 지향에 대한 나의 이해입니다.
02 1. 통합 항목 파일
03 많은 사람들이 보기에 PHP는 여전히 "완전히" 객체 지향이라고 볼 수 없습니다. 그 이유는 객체 지향이 모든 프로그램을 의미해야 하기 때문입니다. 객체화되어야 하며 PHP도 항목 파일을 남깁니다. 그러나 이런 학문적 논쟁은 사실 우리와는 아무 상관이 없습니다. index.php를 제외한 모든 프로그램은 완전한 객체 지향 애플리케이션으로 클래스 형식으로 작성되어야 한다는 점만 알아두면 됩니다.
04 zend 프레임워크에서는 rewrite 기술을 사용합니다. Rewrite는 pseudo-static 기능을 사용하여 검색 엔진에 포함되도록 할 뿐만 아니라 보안 위험을 피하기 위해 인덱스된 PHP 파일이 직접 실행되는 것을 금지합니다. Joomla에서는 프로세스 지향 프로젝트의 경우에도 discuz와 phpwind 모두 재작성 옵션을 제공하므로 많은 zf 초보자가 실용적이거나 재작성을 사용하지 않을 수 있습니다. 전혀 구성하지 않으면 링크의 URL 주소만 다릅니다. 사실 어떤 정보도 이에 대해 언급하지 않는 것이 이상합니다. 실제로 우리는 재작성을 걱정할 필요 없이 IIS와 PHP를 지원하는 대부분의 가상 호스트에서 zend 프레임워크를 사용할 수 있습니다.
05 물론 저는 개인적으로 재작성 기술을 강력히 지지합니다. 저에게 이 기술은 최소한 세 가지 이점을 제공합니다. 1. 의사 정적 방법을 사용하여 검색 엔진 색인 생성을 늘립니다. 2. 중요한 파일을 보호합니다. 3. PHP를 사용하여 이미지 파일을 생성할 때 URL 주소와 실제 이미지 주소 형식은 완전히 동일합니다.
06 따라서 좋은 객체지향 프로그램은 항목 파일을 통합하고 다시 쓰기 기능을 사용하여 다른 비표준 PHP 파일의 사용을 제한해야 합니다.
07 2. MVC 모드
08 MVC는 매우 고전적인 프로그래밍 방식입니다. 순전히 실행 효율성만 추구한다면 프로그램 페이지당 하나의 파일이 가장 효율적이라고 이 글의 이전 글에서 이미 언급했습니다. 하지만 인력에는 한계가 있기 때문에 파일을 여러 조각으로 자르고 일정한 규칙에 따라 분류해야 합니다. PHP를 오랫동안 해오셨다면 온갖 종류의 자르기와 파일 분류 방법을 보셨을 것입니다. 그 중에서 패턴으로 승화되어 주류로 받아들여지는 유일한 방법은 MVC입니다.
09 프로그램과 페이지가 분리되는 것, 즉 뷰가 독립적이라는 것이 일반적으로 받아들여진다면, 컨트롤러와 모델을 분리해야 하는지에 대해서는 여전히 많은 사람들이 서로 다른 의견을 가지고 있습니다. 처음에는 작은 프로젝트가 그렇게 특별할 필요는 없다고 생각했지만 곧 모델의 장점을 발견했습니다. 모델은 프로세스 지향 프로젝트의 함수 라이브러리와 대체로 유사합니다. 함수 라이브러리의 이점은 이전 기사의 시작 부분에서 이미 언급한 바와 같습니다. , MODEL은 이러한 기능을 통합한 분류일 뿐입니다. 모델과 함수 라이브러리의 주요 차이점은 일반적으로 데이터 테이블마다 모델을 구축하므로 각 모델에 메서드가 너무 많지 않고 메서드 이름도 통일될 수 있다는 점입니다. 예를 들어 함수 라이브러리에서 기사 삭제는 delArticle(), 사진 삭제는 delPicture(), 사용자 삭제는 delUser()라고 하며, 모델별로 구분한 후에는 모두 del이라고 부르는 것이 훨씬 깔끔하지 않을까요? ()?
10 따라서 프로젝트 규모에 관계없이 데이터베이스를 사용하는 한 항상 MODEL을 사용할 가치가 있습니다.
11 논의할 가치가 있는 질문은 이론적으로 모델이 데이터 처리만 담당하고 출력 표시는 담당하지 않는다는 것입니다. 이전 프로젝트 중 일부에서는 프레임워크의 관점에서 출력도 배치되었습니다. 어시스턴트. 하지만 최근에는 모델에서 직접 목록과 디렉토리 트리를 생성하는 방법을 확립했습니다. 뷰 어시스턴트에 비해 시간이 절약되고 단점도 발견되지 않았으므로 문제가 없을 때까지 계속하겠습니다. 모델의 약간의 출력: 문자열을 생성하고 이를 컨트롤러의 관련 호출 명령에 반환합니다. 지금 생각해보면 제가 잘못 이해한 것일 수도 있습니다. 어쩌면 정보에 언급된 MODEL은 출력을 담당하지 않고 페이지 직접 표시와 에코 없이 문자열 생성만 요구하는 것일 수도 있습니다. 애초에 허용되는 것일 수도 있습니다.
12 3. phpunit 테스트 프레임워크
13 프로세스 지향 프로그래밍에서는 많은 사람들이 필요할 때 함수를 작성한 다음, 함수가 호출되어야 하는 곳에서 테스트를 위해 함수를 직접 호출합니다. 어쩌면 저처럼 많은 사람들이 어느 날 갑자기 다양한 외부 요인에 의한 감염을 참을 수 없다는 사실을 깨닫고, 이러한 테스트를 하기 위해 test.php를 새로 만들게 되었고, 그러다가 점차 테스트 횟수가 늘어나면서 test.php가 바뀌게 되었습니다. test 폴더에 모든 기능에 대한 테스트를 저장합니다. 이것은 phpunit의 프로토타입입니다. 전체 프로그래밍 과정에서 테스트는 많은 시간을 차지하며 phpunit은 이러한 테스트를 저장하므로 나중에 클래스와 메서드를 수정할 때 많은 테스트 시간을 절약할 수 있습니다.
14 4. 클래스 추상화 및 상속
15 내 코드에서는 상속이 항상 발생하지만 추상화가 거의 없습니다. 추상화와 인터페이스는 우리가 프로그램을 작성하는 데 필수 정의 요구 사항을 가지므로 공동 작업자가 적은 프로그래머에게는 별 의미가 없는 것 같습니다. 그러나 우리나 다음 프로그래머가 나중에 그 결과를 맛보게 되는 것은 바로 프로그래밍 과정의 자유로움과 느슨함 때문입니다. 앞서 이 글을 쓰는 것은 나의 이전 경험을 반성하는 과정이라고 서두에서 언급한 바 있는데, 여기서 말하고 싶은 것은 이전에 작성한 코드에는 추상화나 인터페이스가 거의 없었다는 점이다. 이 점을 보완하여 속성과 메서드의 이름을 통일했습니다.
16 5. 디자인 패턴
17 지금까지 총 23개의 디자인 패턴을 정리했는데 그 중 등록 모드, 팩토리 모드, 싱글톤 모드를 더 많이 사용해봤습니다. 디자인 패턴은 이전 객체 지향 프로그래밍 방법을 요약한 것입니다. 다행히 zend 프레임워크로 프로그래밍할 때 기술적 세부 사항에 대해 너무 많이 알지 않고도 직접 사용할 수 있습니다. 예를 들어 등록 클래스 zend_register가 등록 모드로 사용됩니다. zend_form은 데코레이션 모드를 광범위하게 사용하고 리플렉션 API와 같은 기술도 합리적으로 사용됩니다. 물론, 반대로 zend 프레임워크를 배우는 난이도도 높아졌습니다. 기술을 배울 때 우리는 그것이 무엇인지 아는 것만으로는 만족하지 않고 왜 그런지 알고 싶어합니다. 그리고 이러한 모드는 분명히 ZEND에서 다루지 않습니다. 프레임워크 마스터하기 어려운 이유는 디자인 패턴 등 관련 지식에 대한 깊은 이해가 부족하기 때문인 경우가 많습니다.
18 6. 프레임워크
19 많은 사람들은 zend 프레임워크에 문의하는 것보다 작은 경량 프레임워크를 배우는 것을 선호합니다. 사실 나 자신도 zend 프레임워크를 배우고 적용하는 데 많은 고통을 겪었고 많은 시간을 낭비했다. 마침내 나는 프레임워크가 우리의 원래 프로그래밍 사고 방식을 바꾸었다는 것을 깨달았습니다. 습관을 고수하고 프레임워크를 우리에게 맞게 변경하는 대신 매뉴얼 및 입문 가이드에 명시된 대로 프레임워크를 사용해야 합니다. 절반의 노력으로 결과를 얻었고 얻은 것보다 더 많은 것을 잃었습니다. 예를 들어, 저는 최근에 다음과 같은 기능을 가진 웹사이트를 작성했습니다:
20 1. 포럼 제출 영역에 모든 기사의 카테고리 목록과 기사 내용을 표시합니다.
21 2. 목록을 표시합니다. 저자의 친구들이 제출한 모든 기사 중
22 3. Google 사이트맵을 자동으로 생성합니다.
23 기능은 사실 꽤 적지만, 디자인 페이지까지 포함하면 이 웹사이트를 zend 프레임워크 기반으로 완성하는 데만 이틀이 걸렸습니다. (그리고 꼬박 이틀도 걸리지 않았습니다.) 따라서 중량급 프레임워크로 알려져 있지만 zend 프레임워크는 실제로 소규모 프로젝트 개발에 적합합니다. zend 프레임워크가 너무 크다고 생각한다면, 그렇게 많은 기능 라이브러리를 사용할 필요 없이 자신이 마스터한 라이브러리를 사용하면 됩니다. zend 프레임워크의 문제점은 기능이 너무 많고 하나의 프로젝트에서 모든 기능을 마스터하는 것이 불가능하다는 것입니다. 따라서 단계별로 수행하는 것을 잊지 마십시오.
24 물론 실제로 프레임워크를 전혀 사용하지 않고 MVC 방식을 기반으로 객체지향 프로그램을 작성할 수도 있습니다. 따라서 이러한 경량 프레임워크의 존재 의미를 이해할 수 없습니다. . 프레임워크가 단지 MVC 패턴의 설계자일 뿐이라면, 스마트함에 대한 혼란처럼 우리가 직접 작성해 보는 것은 어떨까요?
25 예를 들어 다음과 같이 작성할 수 있습니다.
26 index.php
27
28 view plaincopy toclipboardprint? >29 < ;?php
30 $controller=$ _GET['controller']
31 require_once 'controller/'.$controller.'.php'
32 < ;?php
33 $controller=$ _GET['controller']
34 require_once 'controller/'.$controller.'.php'
35
36 Controller.php
37
38 일반 복사를 클립보드 인쇄로 보기
39
40 require_once 'some_model.php';
41 $model=new Some_Model();
42 $string=$model->getString;
43 require_once 'templates/templte.phtml';
44
45 require_once 'some_model.php';
46 $model=new Some_Model();
47 $string=$model->getString;
48 require_once 'templates/templte.phtml';
49
50 some_model.php
51 일반 사본을 클립보드 인쇄로 보시겠습니까?
52
53 class Some_Model 확장 PDO{
54 공용 함수 getString(){
55 $string='안녕하세요! ';
56 $string을 반환합니다.
57 }
58 }
59
60 class Some_Model 확장 PDO{
61 공용 함수 getString( ){
62 $string='hello world!';
63 $string을 반환합니다.
64 }
65 }
66
67 template.phtml
68
69 일반 사본 보기 클립보드 인쇄?
70
71 ......
72
73
74
75
76
77 ......
78
79
80
81
82
83
84 这样，MVC模式的face向对象程序就成功创建了吧?
8 5 当然，这个只是我随手打的예를 들어, 저는 "PHP 高级程序设计：模式, 框架与测试", 里级自级框架的演示, 比我这个要好得多。所以，我感觉那些轻weight级框架，似乎Zend 프레임워크는 서로 다르며, 실제로는 매우 큰 문제입니다.据库类、分页类、缓存类、文件上传类.......여기에는 应사용중용到，而下一个应사용중간就往往因为功能要求不同、원작자停止更新甚至是记得原来的下载地址、或是自己写的类想法有了变化중신再写一个等等理由，而更换成了另一个类。每个类看似不大school习成本高不，加到一起就不容小视了。而采用zend Framework框架，哪怕只用它来做类库，总不至于那么快就淘汰掉，而且大公象心，总能更让人用着放心。
86 所以，side向对象的程序，我以后还是会基于zend Framework来写。
87 以上是我对PHP语言face向对象编程的一些看法，才疏school浅，权做抛砖引玉，请大家指正。
以上就是PHP编程方式의 새로운 버전(下)의 内容, 更多更关内容请关注PHP中文网（www.php.cn）！