$ _POST, $ _GET, v.v có vi phạm nguyên tắc đóng gói không?

Sử dụng toàn cầu làm cho mã của bạn khó kiểm tra do đó dễ bị lỗi hơn, không an toàn và không thể đoán trước. Đó là lý do tại sao chúng ta truyền các biến mà chúng ta muốn bên trong một hàm / đối tượng. Vì vậy, câu hỏi của tôi rất đơn giản:

$ _POST, $ _GET, v.v có vi phạm nguyên tắc đóng gói không?

Tôi nghĩ rằng, để duy trì quyền kiểm soát các biến đó theo cách OO, một giải pháp lý tưởng sẽ là thêm một số dòng như thế này vào mã:

// Convert the $_GET array to an object
$get = json_decode(json_encode($_GET), FALSE);  // stackoverflow.com/a/1869147
// Stop it from being included from anywhere
unset($_GET);

// Small example of what could be done later on
$DB = new PDO(/* ... */);
$Person = new Person($DB, $get->id);

Tôi chưa thấy điều này ở bất cứ đâu, thậm chí không có hướng dẫn cũng như khuyến nghị. Ngoài ra, chúng ta có thể thấy rõ cách mã ở trên dễ kiểm tra hơn nhiều so với mã bao gồm $Person = new Person($DB, $_GET['id']);hoặc thậm chí (xấu xí) $Person = new Person($DB);khi bạn có thể sử dụng một $getđối tượng giả .

Là mã ở trên đúng hướng hay tôi đang thiếu một cái gì đó?

EDIT: Sau một số cuộc điều tra ( khung Zend và Cake PHP ) như Alexander Kuzmin đề xuất, có vẻ như đó là điều đúng đắn. Chúng có thể quá lớn đối với tôi để đào sâu vào mã ATM, nhưng tôi sẽ ghi nhớ nó.

Tôi không chắc chắn lý do tại sao bạn áp dụng json_decodeđể $_GETchuyển đổi nó thành một mảng MẠNH; $_GETđã là một mảng.

Sử dụng siêu toàn cầu ( $_GET, $_POSTv.v.) là vi phạm nguyên tắc đóng gói. Nhưng đã có một dòng được vẽ trong đó bạn ngừng đóng gói mọi thứ. Dữ liệu yêu cầu là một ứng cử viên tốt cho việc đóng gói, nhưng đừng bị hút xuống hố thỏ khi cố gắng gói gọn tất cả mọi thứ .

Hầu hết các khung công tác thường bao bọc các siêu toàn cầu của PHP vào một số dạng đối tượng yêu cầu. Làm điều này sau đó giúp dễ dàng giả hơn cho các bài kiểm tra, vv Cách tiếp cận đơn giản nhất sẽ là:

<?php
class Request
{
    public $get;
    public $post;
    public $session;
    public $cookie;

    public function __construct($get, $post, $session, $cookie)
    {
        $this->get = $get;
        $this->post = $post;
        $this->session = $session;
        $this->cookie = $cookie;
    }
}

$request = new Request($_GET, $_POST, $_SESSION, $_COOKIE);

Nó đơn giản và thô sơ, nhưng thực hiện công việc. Bạn cũng nên lọc dữ liệu vào thời điểm này, để bảo vệ chống lại việc tiêm XSS.

Nhưng nó được bọc trong một Requestvật thể. Đối Requesttượng có bốn mảng và các mảng này có thể dễ dàng bị chế giễu:

$get = array(
    'foo' => 'bar'
);
$post = array();
$session = array(
    'user' => 1
);
$cookie = array();

$request = new Request($get, $post, $session, $cookie);

Sử dụng superglobals $_{POST,GET,SERVER}hoặc bất cứ điều gì chắc chắn vi phạm đóng gói.

Vấn đề này phát triển khi bạn muốn tạo "yêu cầu cục bộ" trong phía máy chủ của ứng dụng của bạn như nhiều khung công tác hiện nay.

Tôi không quen làm việc với các khung công tác, nhưng điều tôi thường làm là tạo một cặp Yêu cầu / Phản hồi khi bắt đầu xử lý. Yêu cầu chứa các giá trị các tham số toàn cầu này.

Nếu tôi muốn tạo một yêu cầu con phía máy chủ, tôi có hai tùy chọn: sử dụng bối cảnh hiện tại hoặc tạo một bối cảnh hoàn toàn mới. Vì vậy, tôi nghĩ rằng bạn không nên bỏ qua các biến siêu đối xứng này vì CÓ THỂ bạn muốn sử dụng lại chúng. Ngoài ra, vì lý do này, tôi không đồng ý rằng yêu cầu params phải là singletons.

Bằng cách chỉ chứa các giá trị, không tham chiếu đến các siêu lớp này, một thay đổi trong một đối tượng Yêu cầu sẽ không bao giờ ảnh hưởng đến một đối tượng khác, do đó, vấn đề với trạng thái toàn cầu được giải quyết.

Vì vậy, về cơ bản, tôi có hai lựa chọn:

// Using global context
$request = new Request(array(
    'post' => $_POST,
    'get' => $_GET
));

// or creating a new context

$request = new Request(array(
    'post' => ['someKey' => 'someValue'],
    'get' => ['queryParam' => 'queryValue'],
));

POST- và GET-vars được gửi đến máy chủ với số lượng lớn và php phải hiểu ý nghĩa của chúng. Theo một cách nào đó, thật hợp lý khi có sẵn chúng trên toàn cầu, vì vậy nhà phát triển có thể chọn nơi xử lý chúng.

Nhiều khung (như CakePHP chẳng hạn) đọc các Tham số và sau đó đặt tất cả chúng trong một số mảng, đối tượng hoặc cấu trúc tương tự. Sau đó, chúng được xử lý như mọi dữ liệu khác và được truyền cho tất cả các phương thức cần chúng.

Đóng gói là một nguyên tắc tốt khi có cơ hội bạn có thể cần nhiều phiên bản của một cái gì đó. Nhưng chỉ có một bộ thông số cho một trang web. Nếu họ ở trong một lớp thay vì các biến toàn cục, họ có thể sẽ là người độc thân. Không có sự cải thiện đáng kể nào từ các biến toàn cầu sang các lớp đơn, đó chỉ là một cú pháp khác nhau để truy cập chúng. Chúng vẫn vốn là các đối tượng toàn cầu, nó chỉ cồng kềnh hơn vì bạn phải xử lý cá thể lớp và vượt qua nó.

Do các tham số này được truy cập rất thường xuyên, nên các nhà thiết kế PHP đã đưa ra quyết định làm cho chúng dễ truy cập, thay vì tuân thủ các nguyên tắc thiết kế cứng nhắc. Đó là một ý tưởng tốt để làm cho các hoạt động phổ biến nhất trở nên thuận tiện, nếu không các lập trình viên sẽ nguyền rủa bạn vì đã khiến họ gõ lại giống nhau, điều dài mỗi lần.