So sánh sự khác nhau giữa các file php năm 2024

Question

Java là một trong những ngôn ngữ lập trình hướng đối tượng. Nó được sử dụng trong phát triển phần mềm, trang web, game hay ứng dụng trên các thiết bị di động.

Nội dung chính Show

2. PHP là gì?
3. Những điểm khác biệt chính giữa Java và PHP
4. Nên chọn Java hay PHP thì tốt hơn?
Tránh kiểm tra kiểu dữ liệu (phần 2)
Xóa dead code
Đối tượng và kiến trúc dữ liệu
Sử dụng đối tượng đóng gói
Tạo đối tượng có chứa thuộc tính hoặc phương thức private/protected
Ưu tiên thành phần hơn kế thừa
Tránh viết fluent interfaces
Nguyên lý trách nhiệm duy nhất (SRP)
Nguyên lý Đóng/Mở (OCP)
Nguyên lý thay thế Liskov (LSP)
Nguyên lý phân tách interface (ISP)
Nguyên lý đảo ngược dependencies (DIP)
Nguyên lý đừng lặp lại chính mình (DRY)

Java được khởi đầu bởi James Gosling và bạn đồng nghiệp ở Sun MicroSystem năm 1991. Ban đầu Java được tạo ra nhằm mục đích viết phần mềm cho các sản phẩm gia dụng, và có tên là Oak. Java được phát hành năm 1994, đến năm 2010 được Oracle- một công ty công nghệ máy tính đa quốc gia của Mỹ mua lại từ Sun MicroSystem.

Với phương châm từ lúc ra đời là “viết một lần, chạy mọi nơi”. Java đã chứng minh được tôn chỉ của mình và dẫn đầu là ngôn ngữ lập trình được dùng nhiều nhất thế giới trong nhiều năm liền. Trên toàn cầu hiện nay có rất nhiều ngôn ngữ lập trình hướng đối tượng như: Python, C#, …. trong đó, có không ít là phát triển từ Java, Điển hình C# chính là một ngôn ngữ cải tiến từ Java.

2. PHP là gì?

PHP (viết tắt của cụm từ Personal Home Page) là ngôn ngữ lập trình kịch bản (scripting language) - một nhánh của lập trình, mã nguồn mở được dùng phổ biến để ra tạo các ứng dụng web chạy trên máy chủ.

PHP được tạo ra bởi Rasmus Lerdorf vào năm 1994, sau đó được hoàn thiện hơn bởi nhóm chuyên gia nghiên cứu PHP.

PHP có thể kết nối những website có giao diện bằng HTML với nhau để chạy trên hệ thống máy chủ. Do có cấu trúc đơn giản, dễ học, ngôn ngữ PHP trở thành ngôn ngữ lập trình web căn bản, phù hợp với những người bắt đầu tìm hiểu về lập trình website. Giờ đây PHP ngày càng được áp dụng nhiều và trở thành một trong những ngôn ngữ lập trình phổ biến nhất hiện nay.

3. Những điểm khác biệt chính giữa Java và PHP

Ngôn ngữ lập trình thường được chia ra làm 2 loại là ngôn ngữ thông dịch và ngôn ngữ biên dịch. Thông dịch (Interpreter) : Nó dịch từng lệnh rồi chạy từng lệnh, lần sau muốn chạy lại thì phải dịch lại.

Biên dịch (Compiler): Code sau khi được biên dịch sẽ tạo ra 1 file thường là .exe, và file .exe này có thể đem sử dụng lại không cần biên dịch nữa.

Java thuộc loại ngôn ngữ vừa thông dịch vừa phiên dịch. Điều này cho phép nó chạy trên bất kỳ hệ điều hành nào. Còn PHP thuộc ngôn ngữ thông dịch, tập trung vào sự đơn giản và năng xuất.

Java là ngôn ngữ lập trình hướng đối tượng. Vì vậy, toàn bộ kiến trúc được xác định rõ ràng. Còn PHP không tuân thủ theo khái niệm này, nó đơn giản chỉ là một loại ngôn ngữ kịch bản không có ràng buộc nào để tuân thủ theo kiến trúc được xác định.

Java rất dễ dàng để giao tiếp với mọi API - phương thức kết nối giữa thư viện và ứng dụng, Java được yêu thích hơn cho bất kỳ sự phát triển công cụ tự động hóa nào trong tương lai. Trong khi PHP có một số hạn chế trong khái niệm về các lệnh gọi API, nhưng việc gọi API cũng có thể thông qua PHP ở những phiên bản cao cấp.

Java có khái niệm như Interface, repetitive classes, abstract class, hoặc các method concept từ ngày đầu tiên.Trong khi PHP không có loại khái niệm này, nhưng phiên bản nâng cao của PHP có giới thiệu đến, tuy nhiên là vẫn không có nhiều tiến bộ như Java.

Trong tốc độ tải trang, trong trường hợp có một số mã lệnh logic phức tạp thì Java sẽ mất ít thời gian hơn so với PHP. Phần lớn tốc độ tải trang của PHP sẽ cao hơn vì PHP không có tải công cụ nặng như JSP.

4. Nên chọn Java hay PHP thì tốt hơn?

Cả Java hay PHP sẽ đều có những điểm mạnh riêng trong lập trình, cả hai đều có cách tiếp cận khác nhau. Hãy lắng nghe bản thân của bạn xem con đường tương lai bạn sẽ chọn là gì. Bạn thích tham gia vào những công ty hay dự án như thế nào từ đó đưa ra quyết định.

Ví dụ nếu bạn muốn làm những trang web không yêu cầu cao về bảo mật, tính logic, phức tạp thấp thì nên theo PHP và ngược lại. Hoặc nếu bạn muốn lập trình các web hoặc ứng dụng nào đó cần sử dụng đến API hoặc giao tiếp với bên thứ ba thì nên theo học Java.

PHP là một ngôn ngữ không ràng buộc kiểu dữ liệu, nghĩa hàm có thể nhận bất kỳ kiểu nào. Thỉnh thoảng thì chúng ta bị ảnh hưởng bởi sự tự do này và nó trở thành điều kiện để phải kiểm tra kiểu dữ liệu trong hàm. Có nhiều cách để tránh phải làm việc đó.

Điều đầu tiên cần làm là tạo ra những API nhất quán.

Chưa tốt:

function travelToTexas($vehicle): void {

if ($vehicle instanceof Bicycle) {  
    $vehicle->pedalTo(new Location('texas'));  
} elseif ($vehicle instanceof Car) {  
    $vehicle->driveTo(new Location('texas'));  
}

}

Tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

Tránh kiểm tra kiểu dữ liệu (phần 2)

Nếu bạn đang làm việc với các kiểu dữ liệu nguyên thủy như strings, integers, và arrays, và sử dụng PHP 7+ và bạn không thể sử dụng tính đa hình nhưng bạn vẫn cảm thấy cần kiểm tra kiểu dữ liệu, hãy xem hoặc strict mode. Nó cung cấp cho bạn kiểu static trên PHP standard. Vấn đề thông thường khi kiểm tra kiểu dữ liệu là sẽ khiến code khó đọc nên tóm lại mất nhiều hơn là được.

Hãy giữ PHP nguyên thủy, viết tests cho tốt, và code reviews cẩn thận là được. Nếu không thì chỉ còn cách định nghĩa theo kiểu nghiêm ngặt(strict type declaration) hoặc dùng strict mode.

Chưa tốt:

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

Tốt:

function combine(int $val1, int $val2): int {

return $val1 + $val2;

}

Xóa dead code

Dead code thì cũng củ chuối giống như duplicate code. Không có lý do gì để giữ chúng. Nếu đoạn code nào đó không được gọi, hãy xóa đi! Sau này cần thì chỉ cần tìm lại phiên bản trước bằng git là được.

Chưa tốt:

function oldRequestModule(string $url): void {

// ...

} function newRequestModule(string $url): void {

// ...

} $request = newRequestModule($requestUrl); inventoryTracker('apples', $request, 'www.inventory-awesome.io');

Tốt:

function requestModule(string $url): void {

// ...

} $request = requestModule($requestUrl); inventoryTracker('apples', $request, 'www.inventory-awesome.io');

Đối tượng và kiến trúc dữ liệu

Sử dụng đối tượng đóng gói

Trong PHP bạn có thể khai

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

7,

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

8 và

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

9 cho phương thức và thuộc tính. Hãy sử dụng chúng để kiểm soát được sự thay đổi thuộc tính trong object.

Khi bạn muốn nhiều hơn là chỉ nhận được thuộc tính của object, thì ưu điểm là ta không cần phải tìm kiếm và thay đổi quyền mỗi khi truy cập vào object.
Giúp tạo validation đơn giản mỗi khi thực hiện function combine(int $val1, int $val2): int {
```
return $val1 + $val2;  
```
} 0.
Đóng gói các thành phần bên trong.
Dễ dàng ghi log và xử lý lỗi khi get và set.
Kế thừa lớp, bạn có thể ghi đè những phương thức mặc định.
Bạn có thể lazy load các thuộc tính của object, giả sử nó được lấy từ máy chủ chẳng hạn.

Thêm vào đó, đây là một phần của nguyên tắc .

Chưa tốt:

class BankAccount {

public $balance = 1000;

} $bankAccount = new BankAccount(); // Buy shoes... $bankAccount->balance -= 100;

Tốt:

class BankAccount {

private $balance;
public function __construct(int $balance = 1000)  
{  
  $this->balance = $balance;  
}
public function withdraw(int $amount): void  
{  
    if ($amount > $this->balance) {  
        throw new Exception('Amount greater than available balance.');  
    }
    $this->balance -= $amount;  
}
public function deposit(int $amount): void  
{  
    $this->balance += $amount;  
}
public function getBalance(): int  
{  
    return $this->balance;  
}

} $bankAccount = new BankAccount(); // Buy shoes... $bankAccount->withdraw($shoesPrice); // Get balance $balance = $bankAccount->getBalance();

Tạo đối tượng có chứa thuộc tính hoặc phương thức private/protected

* Phương thức và thuộc tính
function combine($val1, $val2): int {
```
   if (!is_numeric($val1) || !is_numeric($val2)) {  
       throw new Exception('Must be of type Number');  
   }  
   return $val1 + $val2;  
```
} 7 khá nguy hiểm, bởi vì vài dòng code phía bên ngoài có thể dễ dàng thay đổi chúng và bạn không thể kiểm soát được nó bị thay đổi những gì. Thay đổi trong một lớp thì nguy hiểm cho tất cả các người dùng của lớp đó.
- function combine($val1, $val2): int {
```
   if (!is_numeric($val1) || !is_numeric($val2)) {  
       throw new Exception('Must be of type Number');  
   }  
   return $val1 + $val2;  
```
  } 8 cũng nguy hiểm không kém, bởi vì chúng được cấp quyền ở tất cả các lớp con. Điều này có nghĩa là sự khác nhau giữa public và protected chỉ là cơ chế truy cập, nhưng tính đóng gói đảm bảo vẫn giữ nguyên. Sửa đổi trong lớp thì rất nguy hiểm cho các lớp con.
function combine($val1, $val2): int {
```
if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}  
return $val1 + $val2;  
```
} 9 sửa đổi đảm bảo rằng code sửa đổi chỉ nguy hiểm trong lớp đó (bạn sẽ được an toàn khi sửa và không có hiệu ứng Jenga).

Do đó, hãy mặc định sử dụng

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

9 và

function combine(int $val1, int $val2): int {

return $val1 + $val2;

}

5 khi bạn cần cung cấp sự truy cập cho các class bên ngoài.

Đọc thêm tại blog post được viết bởi Fabien Potencier.

Chưa tốt:

class Employee {

public $name;
public function __construct(string $name)  
{  
    $this->name = $name;  
}

} $employee = new Employee('John Doe'); echo 'Employee name: '.$employee->name; // Employee name: John Doe

Tốt:

class Employee {

private $name;
public function __construct(string $name)  
{  
    $this->name = $name;  
}
public function getName(): string  
{  
    return $this->name;  
}

} $employee = new Employee('John Doe'); echo 'Employee name: '.$employee->getName(); // Employee name: John Doe

Lớp

Ưu tiên thành phần hơn kế thừa

Như đã nói trong Design Patterns nổi tiếng của Gang of Four, bạn nên ưu tiên sử dụng “kiểu thành phần” hơn là “kiểu kế thừa”. Có nhiều lý do để sử dụng kiểu kế thừa và cũng có nhiều nguyên nhân để sử dụng kiểu thành phần. Điểm chính của sự tối đa hóa này là nếu bạn thích theo kiểu kế thừa, hãy thử suy nghĩ “kiểu thành phần” có thể giúp giải quyết vấn đề tốt hơn không. Vì có một vài trường hợp nó sẽ tốt hơn.

Có thể bạn sẽ tự hỏi, “khi nào thì nên dùng kế thừa?” Nó tùy thuộc vào từng vấn đề, khi nào thì kiểu kế thừa tốt hơn kiểu thành phần:

Kiểu kế thừa đó đại diện cho một mối quan hệ “is-a” (Ví dụ: Người->Động vật) chứ không phải mối quan hệ “has-a” (Người dùng->Thông tin người dùng).
Bạn cần sử dụng lại code từ lớp cha (Người có thể di chuyển như động vật).
Bạn muốn khi sửa đổi lớp cha thì tất cả lớp có liên quan sẽ thay đổi dễ dàng. (Thay đổi lượng calo của tất cả động vật khi chúng di chuyển).

Chưa tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

0

Tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

1

Tránh viết fluent interfaces

Fluent interface là một API hướng đối tượng có mục đích cải thiện tính dễ đọc của source code bằng cách sử dụng Method chaining.

Trong một số ngữ cảnh, thường là khi xây dựng object nơi mà pattern này giảm tính rườm rà của code (ví dụ PHPUnit Mock Builder hoặc Doctrine Query Builder), sẽ gây ra một số thiệt hại như sau:

Phá vỡ Encapsulation
Phá vỡ Decorators
Khó tạo mock hơn trong test suite
Khiến cho khó đọc “sự khác nhau giữa các file” hơn khi commit code

Để biết thêm thông tin chi tiết, vui lòng đọc bài viết được viết bởi Marco Pivetta.

Chưa tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

2

Tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

3

SOLID

SOLID là từ viết tắt được đưa ra bởi Michael Feathers cho 5 nguyên lý đầu tiên của Robert Martin, 5 nguyên tắc cơ bản của lập trình hướng đối tượng.

S: Nguyên lý trách nhiệm duy nhất (SRP)
O: Nguyên lý Đóng/Mở (OCP)
L: Nguyên lý thay thế Liskov (LSP)
I: Nguyên lý phân tách interface (ISP)
D: Nguyên lý đảo ngược dependencies (DIP)

Nguyên lý trách nhiệm duy nhất (SRP)

Như đã đề cập trong cuốn Clean Code, “Không nên có nhiều hơn một lý do để thay đổi class”. Viết một class với thật nhiều chức năng thì quá sướng. Vấn đề là class không có khái niệm liên kết và nó có khá nhiều lý do để thay đổi. Nếu quá nhiều chức năng trong một class thì khi thay đổi gì đó mình không biết được hết những ảnh hưởng của nó đến các chức năng khác trong các module liên quan.

Chưa tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

4

Tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

5

Nguyên lý Đóng/Mở (OCP)

Như đã đề cập bởi Bertrand Meyer, “thực thể phần mềm (lớp, modules, hàm, etc…) nên cho phép mở rộng, nhưng không cho phép sửa đổi.” Điều đó có nghĩa là gì? Nguyên lý này đơn giản là nên cho phép người dùng thêm mới mà không được thay đổi code hiện tại.

Chưa tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

6

Tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

7

Nguyên lý thay thế Liskov (LSP)

Nguyên lý này được định nghĩa như sau “Nếu S là phụ thuộc của T, thì object của T có thể được thay thế bởi object của S (nghĩa là object của S có thể thay thế object của T) mà không làm thay đổi các thuộc tính của chương trình(tính đúng đắn, công việc thực hiện,…)”

Để dễ hiểu hơn, nếu bạn có một class cha và một class con, sau đó class cha và class con có thể được sử dụng hoán đổi cho nhau mà không sai kết quả trả về. Có thể vẫn còn khó hiểu, hãy xem ví dụ cơ bản Square-Rectangle bên dưới.

Trong toán học, hình vuông là hình chữ nhật, nhưng nếu bạn sử dụng quan hệ “is-a” qua kế thừa, bạn sẽ gặp rắc rối.

Chưa tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

8

Tốt:

function travelToTexas(Traveler $vehicle): void {

$vehicle->travelTo(new Location('texas'));

}

9

Nguyên lý phân tách interface (ISP)

ISP đề cập rằng “Không nên ép người dùng phải phụ thuộc vào interface mà họ không sử dụng.”

Để hiểu ý nghĩa của nguyên tắc này, hãy nhìn vào những class yêu cầu một số lượng lớn các object cần phải inject vào để sử dụng. Không yêu cầu người dùng phải inject số lượng lớn các tùy chọn là một lợi thế, bởi vì hầu hết chúng không cần thiết. Hãy coi chúng là tùy chọn(có thể không dùng) để giúp cho interface bớt phình to.

Chưa tốt:

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

0

Tốt:

Không phải tất cả worker đều là employee, nhưng employee là một worker.

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

1

Nguyên lý đảo ngược dependencies (DIP)

Nguyên lý này đề cập 2 vấn đề cơ bản:

Module cấp cao không nên phụ thuộc vào module cấp thấp. Cả hai nên phụ thuộc vào abstract.
Abstract không nên phụ thuộc vào chi tiết, mà phải ngược lại.

Hơi khó hiểu một chút đúng không? Nhưng nếu bạn làm việc với PHP frameworks (ví dụ Symfony), bạn sẽ thấy nguyên tắc này được áp dụng trên Dependency Injection(DI). Một lợi ích lớn của việc này là chúng giảm sự trùng lặp giữa các modules. Trùng lặp thì tất nhiên Chưa tốt vì chúng khiến code khó refactor.

Chưa tốt:

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

2

Tốt:

function combine($val1, $val2): int {

if (!is_numeric($val1) || !is_numeric($val2)) {  
    throw new Exception('Must be of type Number');  
}
return $val1 + $val2;

}

3

Nguyên lý đừng lặp lại chính mình (DRY)

Đọc hiểu về nguyên lý DRY

Tốt nhất nên chống lặp code ngay khi có thể. Vì lặp code không tốt tí nào, khi bạn muốn thay đổi logic bạn cần phải sửa nhiều chỗ.

Hãy tưởng tượng bạn đang vận hành một nhà hàng và bạn theo dõi lượng hàng tồn kho của bạn: cà chua, hành, tỏi, gia vị,… Nếu bạn có nhiều danh sách để quản lý chúng, bạn cần cập nhật tất cả các danh sách đó mỗi khi bạn bán một đĩa thức ăn. Nhưng nếu như bạn chỉ có 1 danh sách, thì chỉ cần cập nhật ở một nơi!

Thỉnh thoảng vẫn có lặp code bởi vì bạn có hai hoặc nhiều hơn những thứ khác nhau, có nhiều điểm chung, nhưng sự khác nhau giữa chúng buộc bạn phải chia ra 2 hàm làm rất nhiều việc. Để xóa bỏ lặp code, cần tạo ra một abstract có thể xử lý sự khác biệt giữa chúng với chỉ 1 hàm/module/lớp.

Tạo ra được abstract tốt rất quan trọng và khó, đó là lý do tại sao bạn nên dựa theo các nguyên lý SOLID được đưa ra tại mục Lớp. Abstract củ chuối có thể sẽ tệ hại hơn là lặp code, hãy cẩn thận! Nếu có thể tạo một abstract tốt, hãy tạo nó! Đừng lặp lại code, nếu không bạn sẽ phải rất cực khổ mỗi khi muốn sửa đổi gì đó.