Nhập môn lập trình Java

rình của tôi không chạy, nếu tôi gặp phải một 
phương thức có tên là a() thì tôi chỉ muốn nện cho ai đó một trận. 
Hãy dành thêm vài phút để chọn một cái tên rất gợi tả; nếu có thể, bạn hãy cân 
nhắc việc đặt tên cho các phương thức theo cách thức sao cho mã lệnh của bạn đọc 
ra giống như lời nói thông thường vậy, thậm chí nếu điều này có nghĩa là cần thêm 
các phương thức phụ trợ để làm được việc đó. Ví dụ, hãy xem xét việc thêm vào 
một phương thức phụ trợ khiến cho đoạn mã lệnh này thêm dễ đọc hơn: 
if (myAdult.getWallet().isEmpty()) { 
 do something 
} 
Phương thức isEmpty() của ArrayList tự nó rất có ích, nhưng điều kiện logic trong 
câu lệnh if của chúng ta có thể được lợi từ phương thức hasMoney() của Adult 
như sau: 
public boolean hasMoney() { 
 return !getWallet().isEmpty(); 
} 
Sau đây là câu lệnh if đọc giống lời nói thông thường hơn: 
if (myAdult.hasMoney()) { 
 do something 
} 
Kỹ thuật này đơn giản và có lẽ là bình thường trong trường hợp này, nhưng nó lại 
rất hữu hiệu khi mã lệnh trở nên phức tạp hơn. 
Giữ cho số lượng các lớp ít nhất 
Một trong những nguyên tắc chủ đạo để có được thiết kế đơn giản trong lập trình 
đỉnh cao (XP) là đạt được mục tiêu với ít lớp nhất có thể, nhưng không ít hơn. Nếu 
bạn cần một lớp khác, chắc chắn là nên thêm nó vào. Nếu thêm lớp khác làm cho 
mã lệnh của bạn đơn giản hơn hay làm cho bạn diễn dịch ý định của mình dễ dàng 
hơn thì hãy cứ tiếp tục thêm lớp vào. Nhưng chẳng có lý do gì để thêm các lớp chỉ 
để có chúng mà thôi. Thường khi bắt đầu dự án bạn có ít lớp hơn là khi hoàn thành 
xong xuôi, dĩ nhiên, nhưng cũng thường thì dễ tái cấu trúc mã lệnh của bạn thành 
nhiều lớp hơn là tích hợp chúng lại. Nếu bạn có một lớp có rất nhiều phương thức, 
phân tích xem liệu có phải có một lớp khác mắc bẫy vào đây và đang đợi được 
tách ra hay không. Nếu có, hãy tạo ra một đối tượng mới. 
Trong hầu hết các dự án Java của tôi, không ai ngại xây dựng các lớp nhưng chúng 
tôi cũng luôn cố gắng giảm số lượng các lớp mà không làm cho ý định của mình 
kém tường minh. 
Hãy giữ cho số lượng các chú thích ít nhất 
Tôi thường viết các chú thích thừa trong mã lệnh của mình. Đọc chúng hệt như 
đọc cả một cuốn sách. Bây giờ tôi đã khôn ngoan hơn chút ít. 
Tất cả các chương trình học tập về khoa học máy tính, tất cả các cuốn sách dạy lập 
trình và rất nhiều lập trình viên tôi quen biết đều khuyên bạn chú thích cho các mã 
lệnh. Trong một vài trường hợp, các chú thích thật sự có ích. Nhưng trong một số 
trường hợp khác thì chính chúng lại làm cho việc bảo trì mã lệnh khó thêm. Thử 
nghĩ xem bạn phải làm gì khi bạn thay đổi mã lệnh. Có chú thích ở đấy không? 
Nếu có, tốt hơn là bạn phải thay đổi cả chú thích hoặc là nó sẽ trở nên lỗi thời kinh 
khủng, và thời gian trôi đi, thậm chí nó chả diễn tả gì mã lệnh cả. Theo kinh 
nghiệm của tôi thì nó chỉ tăng gấp đôi thời gian bảo trì của bạn mà thôi. 
Quy tắc chủ đạo của tôi là: Nếu mã lệnh khó đọc và khó hiểu đến nỗi cần phải có 
chú thích thì tôi cần làm cho nó sáng sủa hơn đủ để không cần chú thích nữa. Có 
thể là nó quá dài hoặc làm quá nhiều việc. Nếu thế, phải làm cho nó trở nên đơn 
giản hơn. Có thể nó quá khó hiểu. Nếu thế, tôi sẽ bổ sung thêm các phương thức 
phụ trợ để làm nó dễ hiểu hơn. Thực tế, trong 3 năm lập trình Java với các thành 
viên trong đội, tôi có thể đếm số lượng chú thích tôi đã viết trên đầu ngón tay và 
ngón chân. Hãy làm mã lệnh của bạn sáng sủa hơn! Nếu bạn cần một bức tranh 
tổng thể về hệ thống, hoặc một thành phần cụ thể nào đó làm cái gì, hãy viết tài 
liệu ngắn gọn để mô tả nó. 
Những chú thích dài dòng thường khó bảo trì, thường chúng không diễn giải ý 
định của bạn tốt bằng một phương thức được viết chuẩn, nhỏ gọn, và sẽ nhanh 
chóng trở nên lỗi thời. Đừng phụ thuộc quá nhiều vào các chú thích. 
Hãy dùng một phong cách nhất quán 
Viết mã lệnh theo phong cách gì thực sự là vấn đề về sự cần thiết và cái có thể 
chấp nhận được trong môi trường của bạn là gì. Tôi thậm chí không biết đến một 
phong cách mà tôi có thể gọi là “tiêu biểu”. Nó là chuyện sở thích cá nhân. Ví dụ, 
những dòng lệnh sau có thể làm tôi giật nảy mình cho đến khi tôi biến đổi đi: 
public void myMethod() 
{ 
 if (this.a == this.b) 
 { 
 statements 
 } 
} 
Vì sao điều đó lại làm tôi băn khoăn? Vì cá nhân tôi không ưa kiểu viết mã lệnh 
thêm cả loạt dòng mới, mà theo ý kiến của tôi, không cần thiết. Trình biên dịch 
Java ghi nhận những dòng mã lệnh sau đây cũng giống như vậy, và tôi tiết kiệm 
được vài dòng: 
public void myMethod() { 
 if (this.a == this.b) 
 statements 
} 
Không có cách viết nào là “đúng” hay là “sai”. Chỉ đơn giản là nó ngắn hơn cách 
kia. Vậy điều gì xảy ra khi tôi viết mã lệnh với những người thích cách đầu tiên 
hơn ? Chúng tôi trao đổi về nó, chọn ra kiểu chúng tôi sẽ dùng và sau đó thì trung 
thành với nó. Chỉ có một quy tắc nghiêm ngặt là hãy nhất quán. Nếu những người 
tham gia thực hiện một dự án áp dụng các phong cách khác nhau, việc đọc mã 
lệnh sẽ khó khăn. Hãy chọn một kiểu thôi và đừng thay đổi nữa. 
Tránh dùng lệnh switch 
Một vài lập trình viên Java thích dùng lệnh switch. Tôi thì nghĩ lệnh đó cũng hay, 
nhưng sau đó nhận ra rằng switch thực ra chỉ là một loạt lệnh if, và như thế có 
nghĩa là logic điều kiện sẽ xuất hiện ở nhiều nơi trong mã lệnh của tôi. Đó là sự 
lặp lại mã lệnh, và đấy là cái không chấp nhận được. Tại sao? Bởi vì có những mã 
lệnh giống nhau tại nhiều vị trí có thể khiến cho mã lệnh khó thay đổi. Nếu tôi có 
cùng lệnh switch ở tại 3 nơi và tôi muốn thay đổi cách xử lý một trường hợp cụ thể 
thì tôi phải thay đổi 3 đoạn mã lệnh. 
Bây giờ, nếu như bạn có thể tái cấu trúc mã lệnh sao cho chỉ còn có một lệnh 
switch thì sao? Tuyệt vời! Tôi không tin có bất kỳ chuyện tệ hại gì khi dùng nó. 
Trong một vài trường hợp, dùng switch lại khiến mã lệnh sáng tỏ hơn là nhiều 
lệnh if lồng nhau. Nhưng nếu bạn thấy nó xuất hiện ở nhiều nơi có vấn đề thì bạn 
nên sửa đi. Cách dễ nhất để khỏi vấp phải vấn đề này là tránh dùng lệnh switch trừ 
khi nó là công cụ tốt nhất cho công việc đó. Theo kinh nghiệm của tôi thì điều này 
rất hiếm khi xảy ra. 
Hãy để là public 
Tôi để dành lời khuyến cáo gây nhiều tranh cãi nhất đến phút cuối cùng. Hãy 
chuẩn bị tinh thần nào và hít thở thật sâu. 
Tôi tin bạn sẽ sai lầm khi đặt toàn bộ các phương thức của bạn ở chế độ truy nhập 
là public. Các biến cá thể đặt ở chế độ protected. 
Dĩ nhiên, nhiều lập trình viên chuyên nghiệp sẽ rùng mình khi nghĩ đến điều đó vì 
nếu mọi thứ đều là công cộng thì ai cũng có thể biến đổi chúng được, có thể bằng 
cả những cách bất hợp pháp. Trong một thế giới mà mọi thứ đều có thể truy cập 
công cộng, bạn phải phụ thuộc vào tính nguyên tắc của người lập trình trong việc 
đảm bảo rằng mọi người không thể truy nhập vào những thứ mà họ không nên truy 
nhập khi họ không được phép. Nhưng trong thực tế lập trình, ít có điều gì gây 
phiền toái hơn là muốn truy cập một biến hay một phương thức mà bạn không 
nhìn thấy được. Nếu bạn hạn chế truy cập những thứ trong mã lệnh và bạn coi 
rằng những người khác sẽ không truy cập được, thì có lẽ bạn thực sự là đấng toàn 
năng. Đó là một giả định nguy hiểm trong mọi thời điểm. 
Nỗi phiền toái này thường lộ ra khi bạn dùng mã lệnh của người khác. Bạn có thể 
thấy một phương thức thực hiện chính xác những gì bạn muốn làm, nhưng nó lại 
không cho phép truy cập công cộng. Đôi khi có lý do chính đáng để làm việc đó 
và việc hạn chế các truy nhập là có ý nghĩa. Thế nhưng, đôi khi lý do duy nhất để 
chế độ truy cập không là public là những người viết mã lệnh đã nghĩ rằng “Chả 
bao giờ có ai cần truy nhập vào đây cả”. Hoặc có thể họ đã nghĩ “Chẳng ai sẽ cần 
truy nhập vì…” và tiếp theo, không có một lý do đủ vững chắc. Nhiều khi người ta 
sử dụng chế độ private vì nó có sẵn đó. Đừng làm vậy. 
Hãy để các phương thức là public và các biến là protected cho đến khi bạn có lý 
do hợp lý để hạn chế truy nhập. 
Theo dấu chân của Fowler 
Bây giờ bạn đã biết cách làm thế nào để viết mã lệnh Java tốt và giữ gìn cho nó 
chuẩn mực. 
Cuốn sách hay nhất trong ngành công nghiệp phần mềm là cuốn “Tái cấu trúc” 
của Martin Fowler (xem Các tài nguyên). Nó thậm chí còn rất hài hước nữa. Tái 
cấu trúc có nghĩa là thay đổi thiết kế của mã lệnh hiện có mà không làm biến đổi 
kết quả của nó. Fowler nói về các “mùi mã lệnh” đang xin được tái cấu trúc, và đi 
sâu vào chi tiết các kỹ thuật khác nhau (hoặc các kiểu tái cấu trúc khác nhau) để 
khắc phục chúng. Theo quan điểm của tôi, việc tái cấu trúc và khả năng viết mã 
lệnh kiểm thử đi trước (code test-first) (xem Các tài nguyên là những kỹ năng 
quan trọng nhất mà các lập trình viên mới vào nghề cần học. Nếu mọi người đã 
thạo cả hai, nó sẽ cách mạng hóa ngành công nghiệp này. Nếu bạn trở nên thành 
thạo ở cả hai kỹ năng, sẽ rất dễ kiếm việc làm, vì bạn sẽ có thể làm ra kết quả tốt 
hơn so với đa số người tìm việc. 
Việc viết mã lệnh Java tương đối đơn giản. Viết mã lệnh Java “tốt” lại là mẹo 
mực. Bạn hãy tập trung để trở thành những người lành nghề. 
Tổng kết 
Trong tài liệu này, bạn đã học về lập trình hướng đối tượng, khám phá cú pháp của 
Java để giúp bạn tạo ra các đối tượng hữu dụng, và hiểu biết về một IDE giúp bạn 
kiểm soát môi trường phát triển của mình. Bạn có thể tạo ra các đối tượng có khả 
năng thực hiện tốt một số việc, mặc dù dĩ nhiên là không phải tất cả mọi việc mà 
bạn có thể tưởng tượng ra. Nhưng bạn có thể mở rộng hiểu biết của mình theo 
nhiều cách, bao gồm cả việc nghiên cứu kỹ về Java API và khám phá các khả năng 
khác của ngôn ngữ Java qua các bài hướng dấn khác của developerWorks. Hãy 
xem phần Các tài nguyên để tìm tài liệu về tất cả các vấn đề này. 
Ngôn ngữ Java chắc chắn không là hoàn hảo; mọi ngôn ngữ đều có các thói tật và 
mọi các lập trình viên đều có ngôn ngữ ưa thích của mình. Tuy nhiên, nền tảng 
Java là công cụ tốt có thể giúp bạn viết nên các chương trình chuyên nghiệp chuẩn 
mực ở mức yêu cầu cao.