Business logic = domain logic + application logic

Về cơ bản, domain logic dùng để chỉ các logic mang tính bản chất, luôn đúng cho một business domain, phản ánh tính chất của các domain object và mối quan hệ giữa chúng với nhau, mà không phụ thuộc vào một application. Trong khi đó, application logic là các logic riêng cho một application cụ thể. Các application khác nhau sẽ có các application logic khác nhau. Việc thay đổi application logic không nên dẫn đến sự thay đổi ở domain logic. Đặt trong ngữ cảnh của một enterprise application dạng client-server với nhiều loại client (web, desktop application, mobile app, v.v), domain logic là thành phần lõi ở server, được chia sẻ giữa các client, còn application logic quy định hành vi của từng client khi tương tác với người dùng.

Chúng ta sẽ xem xét một ví dụ để làm rõ các khái niệm. Trong việc quản lí dự án, ta quy định mối build phải thuộc một và chỉ một release nào đó. Khi đó, để mối quan hệ này luôn được đảm bảo, việc một release bị xóa sẽ dẫn đến các build thuộc về nó bị xóa theo. Thao tác này thuộc về domain logic. Khi được người dùng yêu cầu xóa một release, phần mềm quản lí dự án có thể đáp ứng đúng như domain logic, hoặc bắt buộc người dùng phải tự xóa các build trong release, hoặc có thể đòi hỏi sự xác nhận của quản lí dự án v.v. Những thao tác này phát sinh và thay đổi theo hoàn cảnh sử dụng, và không làm thay đổi ngữ nghĩa của build và release. Đây chính là application logic.

Việc xây dựng user story cho một hệ thống, vốn không liên quan gì đến lập trình, cũng được lợi từ việc phân tách application logic và business logic. Theo kinh nghiệm cá nhân, nó hạn chế sự trùng lặp khi diễn giải các bước trong user story, giúp lập trình viên và tester tra cứu dễ dàng hơn, và có những định hướng tốt hơn khi hiện thực. Ngoài ra, tách biệt các vấn đề (domain logic, workflow, user experience, v.v) sẽ giúp ngữ cảnh của những cuộc thảo luận cụ thể và rõ ràng, và tất nhiên sẽ hiệu quả hơn.

Cần chú ý là không có ranh giới tuyệt đối giữa domain logic và application logic. Việc sắp đặt như thế nào phụ thuộc vào cách nhìn về business domain, yêu cầu của application, v.v. Xét cho cùng, tất cả những việc phân chia này đều nhằm đáp ứng những nguyên tắc cơ bản khi thiết kế phần mềm.

Tham khảo:

• Patterns of Enterprise Application Architecture, của Martin Fowler và các tác giả khác.
• Architecting Microsoft .NET Solutions for the Enterprise, của Dino Esposito và Andrea Saltarello.
• Pros and Cons of Data Transfer Objects, MSDN.

• Các method tiện ích với DOM (dojo.create, dojo.place, v.v) và với JavaScript (dojo.isArray, dojo.hitch, v.v).
• Một mô hình OOP kiểu class tương tự như các ngôn ngữ phổ biến Java, C#. Kết hợp với mô hình OOP kiểu prototype của JavaScript, việc lập trình OOP trên Dojo trở nên cực kì thoải mái và tiện lợi.
• Các cơ chế để thao tác với dữ liệu, như lấy dữ liệu từ server, tìm, thêm, xóa dữ liệu. Có thể xem đây là một persistent library rất đơn giản cho JavaScript. Tính năng này cũng giúp tách biệt phần nội dung ra khỏi phần hiển thị của các widget, giúp cho việc thao tác với dữ liệu trên các widget dạng bảng, cây của Dojo khá mạch lạc.
• Các widget thường dùng và cơ chế để viết thêm các widget khác. Việc viết thêm widget trong Dojo phải nói là khá đơn giản và được hướng dẫn rất chi tiết.
• Cơ chế publish/subscribe các event, theo object và global. Event là một khái niệm quan trọng trong JavaScript, và nó giúp giảm coupling khi thiết kế các ứng dụng web nặng về Ajax. Với Dojo, tất cả các method đều là event.
• Cơ chế để quản lí sự phụ thuộc giữa các file JavaScript (tương tự như import trong Java). Dojo giúp đơn giản hóa việc nạp các file JavaScript cần thiết từ server.
• Trong thiết kế có tính đến việc hỗ trợ accessiblity. Tùy nhu cầu mà điều này có cần thiết hay không.

Tuy nhiên, Dojo cũng có nhiều hạn chế mà bạn phải cân nhắc.

• Mức độ sử dụng thấp, nghĩa là cộng đồng hỗ trợ sẽ nhỏ hơn so với các library phổ biến hơn.
• Widget của Dojo được tập hợp một cách có hệ thống, và mỗi widget luôn cố gắng đáp ứng mọi nhu cầu có thể. Điều này khiến cho một số widget như Tree, DataGrid trở nên cồng kềnh và phức tạp, cả về HTML sinh ra lẫn JavaScript cho hành vi của chúng. Việc chỉnh sửa chúng cho phù hợp với nhu cầu sẽ tiêu tốn nhiều công sức của bạn.
• Chất lượng mã nguồn không đồng đều. Một số widget được xây dựng từ nhiều thành phần nhưng lại không thiết kế phù hợp với nguyên tắc Inversion of Control, khiến cho việc mở rộng, chỉnh sửa mỗi thành phần khó khăn hơn. Mặc dù điều này có thể được khắc phục phần nào trong một số trường hợp với prototype.
• Việc layout các widget của Dojo phụ thuộc rất nhiều vào kích thước của các widget liên quan, trong khi đó hiện thực các tính toán này không hoàn toàn ổn định, rải rác khắp mọi chỗ trong mã nguồn, có thể ảnh hưởng tới hiệu năng và độ ổn định của ứng dụng.

Nói thêm, bởi vì Dojo là một framework hoàn chỉnh nhằm hỗ trợ mọi nhu cầu liên quan đến phát triển ứng dụng web với JavaScript, cho nên sẽ khó mà chọn được framework thay thế với chất lượng hoàn toàn tốt hơn. Tuy nhiên, bạn có thể thử gộp những library nhỏ để có được những tính năng tương tự như Dojo cung cấp. Vì các library nhỏ nhằm giải quyết những vấn đề cụ thể hơn, chúng có thể tiến hóa nhanh hơn và ổn định hơn một framework lớn. Chẳng hạn:

• JQuery, Prototype.js, MooTools cho những mở rộng đơn giản trên JavaScript.
• JQuery cho thao tác với DOM, và JQuery UI cho các widget thường dùng.
• Prototype.js để sử dụng mô hình OOP kiểu class trong JavaScript.
• v.v

Cuối cùng, nếu bạn đã quyết định dùng Dojo, thì có lẽ vài kinh nghiệm nhỏ dưới đây sẽ có ích cho bạn:

• Học JavaScript. Nó đủ khác các ngôn ngữ phổ biến khác để bạn phải học một cách cẩn thận.
• Đọc kĩ tài liệu Dojo cung cấp, và nếu có thể, xem qua mã nguồn của một số thành phần để hiểu rõ.
• Mở rộng, chỉnh sửa các thành phần Dojo cung cấp theo ý của mình, thay vì cố gắng tìm một giải pháp “hack” dựa trên những gì Dojo đã có.
• Tìm hiểu về những vấn đề liên quan nếu cần, chẳng hạn như memory leak trong JavaScript và Dojo, kiến trúc của một ứng dụng web nặng về JavaScript, v.v

Trong ngành này dường như làm kịp thời hạn là một cái gì đó xa xỉ. Tất nhiên mọi thứ cũng có giới hạn của nó, quản lí thì có quản lí ở cao hơn, quản lí ở cao hơn thì có khách hàng, khách hàng thì có thị trường, v.v. Cho nên không phải cứ cái gì cũng nói không kịp là được.

Công bằng mà nói, không cứ gì phát triển phần mềm, mà nói chung bạn không thể có đủ thời gian để làm tất cả mọi việc, nhưng bạn có thể có thời gian để làm những việc quan trọng nhất. Vì vậy làm không kịp cũng là một biểu hiện của tính yếu kém trong việc ước lượng thời gian và đánh giá kế hoạch.

Nói như thế có nghĩa là việc nói không với người quản lí không phải chỉ đơn giản là thu hết can đảm lại mà nói. Chính xác hơn can đảm không có vai trò gì ở đây cả. Bạn phải tính toán được và chấp nhận rằng bạn không có đủ thời gian, phải thấy được việc gì cần làm với chất lượng ở mức độ hợp lí, và phải chọn lấy những giải pháp thỏa hiệp nhất. Càng nhiều thông tin và lựa chọn thì người quản lí sẽ càng dễ tiếp thu ý kiến của bạn. Vậy là kĩ năng nói không phụ thuộc vào khả năng ước lượng, nắm vấn đề và kiến thức và các giải pháp.

Khi biết nói không rồi có lẽ tôi sẽ trở nên chuyên nghiệp hơn rất nhiều.

Khi mới tìm hiểu về mappedby thì thuật ngữ “relationship owner” làm tôi cảm thấy khá mơ hồ. Lí do chủ yếu là sách giải thích rất qua loa thuật ngữ này. Tìm kiếm trên Internet có vẻ không đem lại kết quả gì đáng kể. Một cấp trên của tôi giải thích rằng việc lựa chọn relationship owner tùy thuộc vào ý nghĩa về mặt business của các entity càng khiến tôi rối loạn hơn.

Hóa ra, chỉ dẫn về “relationship owner” đã được phát biểu rất rõ ràng trong JSR 220:

Relationships may be bidirectional or unidirectional. A bidirectional relationship has both an owning side and an inverse side. A unidirectional relationship has only an owning side. The owning side of a relationship determines the updates to the relationship in the database, as described in section 3.2.3.

The following rules apply to bidirectional relationships:

• The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy element of the OneToOne, OneToMany, or ManyToMany annotation. The mappedBy element designates the property or field in the entity that is the owner of the relationship.
• The many side of one-to-many / many-to-one bidirectional relationships must be the owning side, hence the mappedBy element cannot be specified on the ManyToOne annotation.
• For one-to-one bidirectional relationships, the owning side corresponds to the side that contains the corresponding foreign key.
• For many-to-many bidirectional relationships either side may be the owning side.

Chứng tỏ trong một số trường hợp đọc specification lại tiết kiệm thời gian hơn tìm kiếm trên Internet .

Thêm đường dẫn tới thư mục cài php (C:\wamp\bin\php\php5.3.5) vào biến môi trường PATH.

Chuyển tới thư mục C:\wamp\bin\php\php5.3.5, chạy lệnh: php -d phar.require_hash=0 PEAR/go-pear.phar. Đừng chạy file go-pear.bat như thường được chỉ. Sau đó merge file PEAR_ENV.reg vào registry.

Khi chạy lệnh trên, nếu có báo lỗi liên quan đến việc giải nén gói Structures_Graph thì xử lí như sau:

• Tải gói Structures_Graph tử trang http://pear.php.net.
• Giải nén, chép thư mục Structures vào C:\wamp\bin\php\php5.3.5\pear\pear
• Tạo biến môi trường PHP_PEAR_PHP_BIN với giá trị C:\wamp\bin\php\php5.3.5\php.exe.
• Chuyển tới thư mục C:\wamp\bin\php\php5.3.5\pear\pear, chạy lệnh pear upgrade-all.

Xong .

Hôm nọ vào diễn đàn nào đấy thấy giải thích sự khác nhau giữa value type và reference type trong C#. Đại loại là biến value type nằm trên stack, biến reference type nằm trên heap. Có lẽ suy nghĩ này ảnh hưởng từ C/C++ gì đó chăng, nhưng nói chung là không chính xác. Về các đặc điểm của value type và reference type, MSDN đã trình bày đầy đủ, nên ở đây không lặp lại nữa. Quay lại chuyện stack và heap. Giả sử như ý trên đúng, tức là object tạo từ class nằm trên heap. Nếu object này có field int là value type, thì field này nằm ở đâu? Theo như ý trên thì nó nằm ở stack. Object nằm trên heap mà field nằm ở stack thì cũng hơi lạ nhỉ.

Thực ra, tôi nghĩ cái ý tưởng về stack và heap không đúng mà cũng chẳng sai. Vấn đề là, nó thuộc về hiện thực của CLR, và chúng ta không thể và cũng không cần biết chuyện nó lưu trữ các giá trị như thế nào. Việc chúng ta cần quan tâm chỉ là các tính chất và hành vi của chúng mà thôi.

Không phải chỉ C#, ngay cả với C++ thì việc sử dụng khái niệm stack và heap cũng là không cần thiết và có vẻ không chuẩn. Cụ thể thế nào thì các bạn có thể tìm hiểu thêm các khái niệm automatic storage, static storage, and dynamic storage (chẳng hạn, trong quyển C++ primer plus, đây cũng là một quyển rất tốt về C++).

Khi chưa tìm hiểu kĩ về polymorphism, tôi có cảm giác polymorphism là một cái gì đó khá mơ hồ. Nói chung thì các sách khi để cập đến vấn đề này đều dùng ví dụ minh họa hơn là định nghĩa chính xác. Với những tài liệu có định nghĩa, thì có vẻ như đánh đồng polymorphism và overriding. Tuy nhiên, trong khi với những ngôn ngữ như Java các method đều là virtual method thì cũng có những ngôn ngữ như C# trong đó virtual method và overriding phải được phát biểu một cách rõ ràng. Tuy nhiên, như ta đã biết, polymorphism cùng với encapsulation và inheritance thường được giới thiệu như là ba cột trụ (pillar) của OOP. Nếu polymorphism đồng nghĩa với overriding và virtual method thì tại sao những ngôn ngữ như C# lại có vẻ như hạn chế cột trụ này? (Nói ngoài lề là thực ra việc đòi hỏi phát biểu virtual method và overriding một cách rõ ràng trong C# có cái lí của nó, chứ không phải là để hạn chế.)

Thực tế là, khi đọc các tài liệu mang tính lí thuyết hơn, bạn sẽ thấy polymorphism không phải là một khái niệm của riêng OOP, càng không đồng nghĩa với overriding. Mặc dù không phải tất cả các tài liệu đều viết giống nhau, nhưng nhìn chung có thể định nghĩa polymorphism là tính chất cho phép các cấu trúc gồm hàm và kiểu dữ liệu có thể làm việc với nhiều kiểu dữ liệu khác nhau. Có ba dạng polymorphism:

• Parametric polymorphism: Các type liên quan đến cấu trúc được cung cấp dưới dạng biểu thức trong đó type là các biến. Chẳng hạn, C++ template chính là một cơ chế hỗ trợ parametric polymorphism trong ngôn ngữ này. Tất nhiên, parametric polymorphism có thể có trong các ngôn ngữ không hỗ trợ OOP.
• Ad hoc polymorphism: Thuật ngữ này dùng để chỉ overloading. Ví dụ phổ biến là toán tử + có thể là một function dạng int * int –> int, cũng có thể là một function dạng string * string –> string. Một số người không đồng ý xem overloading là một dang polymorphism.
• Subtype polymorphism: Đây là dạng polymorphism mà thuật ngữ “polymorphism” trong OOP chỉ tới. Với subtype polymorphism, một method có thể áp dụng cho nhiều type khác nhau thông qua subtyping. Cụ thể, nếu một method áp dụng được cho type T, nó sẽ áp dụng được cho subtype của T. Quan hệ subtype thường được thiết lập thông qua inheritance. Chú ý là, định nghĩa này không đề cập đến overriding hay virtual method gì cả. Một ngôn ngữ OOP có thể không hỗ trợ overriding mà vẫn thỏa mãn subtype polymorphism.

Một điểm đáng chú ý là trừ Wikipedia, tôi chưa thấy có nguồn nào coi overriding là một dạng polymorphism cả.

Tóm lại nên định nghĩa polymorphism như thế nào? Về mặt lương tâm mà nói thì có lẽ cần trình bày dựa theo lí thuyết về ngôn ngữ lập trình. Về mặt cảm giác, tôi nghĩ định nghĩa polymorphism trong OOP bằng subtype polymorphism tuy trông thì phức tạp nhưng lại đơn giản, mạch lạc, ít mơ hồ hơn định nghĩa thông qua overriding (đương nhiên kéo theo người học dễ hiểu, dễ nhớ, dễ hệ thống hơn). Về thực tế thì vì định nghĩa về polymorphism trong OOP thông qua overriding (và kéo theo hiểu rằng polymorphism là đặc trưng của OOP) đã quá phổ biến, mà hiểu sao thì tóm lại vẫn là biết lập trình, nên có lẽ cũng không cần bận tâm đến polymorphism thực sự là cái gì nữa .

Các bạn có thể tham khảo thêm trong Concepts in programming languages và Programming languages pragmatics.

• a++ tăng a thêm 1 (nếu a là int), trả về giá trị hiện tại (trước khi tăng) của a,
• ++a tăng a thêm 1 (nếu a là int), trả về giá trị sau khi tăng của a.

Vậy cho int a = 1 thì 1 + a++ + a++; sẽ cho ra giá trị bao nhiêu? Dễ quá nhỉ, cứ áp dụng quy tắc trên là xong. Đây là một dạng câu hỏi phổ biến mà một số sách C, C++, v.v và một số giáo viên vẫn hay đố.

Tuy nhiên, thực tế dù bạn có áp dụng quy tắc trên, hay chạy thử bằng trình dịch thì kết quả mà bạn có vẫn luôn là một câu trả lời sai. Bởi vì theo đặc tả của C++, chỉ tại các sequence point, ta mới có thể đảm bảo là các side effect (hiệu ứng lề) của biểu thức đã được thực thi, và thứ tự thực thi thường không được đảm bảo. Chẳng hạn:

• f() + g();: + không phải là sequence point, ; là sequence point. Không thể chắc chắn được là f() hay g() được thực thi trước.
• f() + g(a++);: Không thể chắc chắn f() hay g(a++) được thực thi trước, nghĩa là không thể chắc chắn f() hay a++ được thực thi trược, nên nếu trong f có thể truy xuất được a thì giá trị của a sẽ là không xác định.
• Tình huống ban đầu, 1 + a++ + a++;: Tất cả những gì ta có thể chắc chắn là a sẽ được tăng lên 1 hai lần, việc tăng này có thể xảy ra trước hoặc sau bất kì phép + nào trong biểu thức, nên giá trị của biểu thức này là không xác định, và phụ thuộc vào từng trình dịch cụ thể.

Ta kết luận được gì?

• Đặc tả của các ngôn ngữ lập trình luôn phức tạp hơn ta tưởng rất nhiều, và những người soạn ra nó thực sự là các language lawyer.
• Đừng cố lồng ghép các biểu thức như trên, bên cạnh việc không xác định giá trị nó còn làm cho mã nguồn trở nên vô cùng rối rắm.
• Hạn chế side effect, trả về kết quả nên là công việc duy nhất mà một function phải làm. Đây cũng là một nguyên tắc mà lập trình hàm cổ vũ.
• Đừng đố người khác những biểu thức như thế này .

Theo như thầy NHP nói, thì chỉ có hai người xem báo cáo của bạn là người hướng dẫn và người phản biện, ba người trong hội đồng chấm sẽ chỉ lướt qua trong lúc bạn bảo vệ. Hơn nữa ngay cả người phản biện cũng sẽ không có nhiều thời gian để xem báo cáo, cho nên bạn phải cố gắng tập trung vào các điểm chính trong luận văn của mình. Đặc biệt cần tránh việc nhồi những thứ vô bổ vào báo cáo để cho nhiều chữ.

Báo cáo:

• Chương 1: Giới thiệu, nên chiếm 10-20 trang. Đây là phần đặc biệt quan trọng, vì người phản biện sẽ căn cứ vào phần này để xem có nên đọc kĩ phần sau không .
• Tầm quan trọng: Chứng tỏ vấn đề mà bạn tìm hiểu có vai trò quan trọng (không quan trọng thì làm làm gì).
• Độ phức tạp: Chứng tỏ vấn đề này khó (không khó sao đáng làm luận văn).
• Thesis statement: Phát biểu bạn sẽ làm cái gì. Công việc mà bạn hoàn tất phải khớp với phát biểu này.
• Đóng góp của luận văn cho vấn đề bạn tìm hiểu.
• Cấu trúc của báo cáo.
• Chương 2: Kiến thức nền tảng, khoảng 20 trang. Trình bày những công nghệ và công việc liên quan (của người khác). Lưu ý không sao chép, và viết thật ngắn gọn, vì đây là những thứ người khác làm. Người phản biện thường sẽ không xem kĩ phần này mà chỉ tham khảo nếu cần thiết cho việc đọc các chương sau.
• Chương 3 (và 4, nếu hai người làm hai việc độc lập): Thiết kế và hiện thực, khoảng 60 trang, nói chung phải đảm bảo chiếm tỉ lệ lớn trong báo cáo, vì đây là những thứ do mình làm.
• Thiết kế: Chú ý phân tích, so sánh các công nghệ, phương án. Phải làm sao thể hiện những thứ mình chọn là tối ưu nhất.
• Hiện thực: Chỉ trình bày qua cách tổ chức chương trình, triển khai, v.v. Đừng chép mã nguồn vào báo cáo, vì sẽ không ai đọc.
• Chương 4: Thử nghiệm.
• Chương 5: Kết luận.
• Phụ lục: Có thể trình bày kế hoạch thực hiện luận văn, bao gồm dự kiến và thực tế, những việc nảy sinh, v.v

Thuyết trình:

• Thời gian nói khoảng 15-20 phút, số slide khoảng 20-25.
• Một số slide quan trọng:
• Slide 0: Giới thiệu tên, tuổi, v.v
• Slide 1: Bố cục của bài thuyết trình.
• Slide 2-3: Chương 1 của báo cáo, nói khoảng 2 phút.
• Chú ý không nói chương 2 của báo cáo, hoặc chỉ nói trong một slide.

Tháng trước HM có chat với một người bạn và nhận được một câu trong đề thi giữa kì môn Lập trình hướng đối tượng như sau:

Trong C++ câu lệnh ClassB CB = new ClassB() tạo ra đối tượng trong vùng nhớ: a. heap b. stack c. static d. tất cả đều sai

Và HM nhận ra đã hai năm kể từ khi học xong môn này, nó vẫn chả thay đổi gì cả. Câu hỏi trên thì dính dáng gì đến OOP? Khi xưa thi môn này HM cũng gặp những câu hỏi khiến người ta có cảm giác đây là môn “Lập trình OOP, Java, và C++ cóp nhặt”.

Theo ý kiến của HM (và HM không phải là giáo viên), một môn Lập trình hướng đối tượng nếu được dạy, cần phải thể hiện được:

• OOP là một paradigm, các ngôn ngữ chỉ là implementation.
• Các khái niệm về encapsulation, inheritance, polymorphism, overriding, v.v
• Giới thiệu qua về các implementation khác nhau cho những khái niệm trên.
• Các nguyên lí khi thiết kế hướng đối tượng, và một dự án lớn áp dụng được nhiều nguyên lí này thì rất tuyệt. Tuyệt hơn nữa nếu nó sử dụng lại bài tập lớn của môn học trước dành cho sinh viên mới, vì nó sẽ tạo ra sự đối chiếu. Môn Lập trình hướng đối tượng khi HM học không dạy cái này, và cũng chỉ đưa ra các bài thực hành dạng copy-paste, chạy có thể được có thể không, và hoàn toàn không minh họa gì cho các nguyên lí OOP.

Thực sự cảm thấy rất tiếc.

Trước hết, hãy nói về nguyên tắc chung khi thiết kế chương trình:

1. Giữ những thứ phải thay đổi cùng nhau ở thật gần nhau. Chẳng hạn khi thay đổi về thiết kế ở class A luôn kéo theo thay đổi ở B, thì nên cho A và B vào cùng một module.
2. Cho phép những thứ không liên quan thay đổi một cách độc lập với nhau (nói cho có vẻ “chuyên ngành” là orthogonal). Ví dụ không có lí do gì để sửa đổi class Person khi class Money bị sửa đổi.

Từ hai nguyên tắc này có thể đẻ ra cả tá nguyên tắc và khái niệm cụ thể hơn, mà trong đó có cohesion và coupling. Tuy nhiên, nếu nắm vững hai nguyên tắc trên thì trong trường hợp không biết về các khái niệm khác, bạn vẫn có thể nhận ra những bất thường trong thiết kế.

Vậy cohesion là gì? Khi nói đến cohesion chúng ta nghĩ đến nhiệm vụ của từng module. Nhiệm vụ của từng module càng rõ ràng và tách biệt thì cohesion càng cao (high cohesion), và đó là mục tiêu cần đạt tới khi thiết kế. Giải thích bằng code có lẽ sẽ không rõ ràng bằng bài viết này:

Tại kỳ họp Quốc hội thứ năm, khi thảo luận về quản lý chất lượng vệ sinh an toàn thực phẩm có vị đại biểu Quốc hội đã ví việc có tới 5 bộ chịu trách nhiệm chính như vậy cũng giống như “nhiều sãi không ai đóng cửa chùa”.
Bởi thế, làm rõ trách nhiệm của từng cơ quan quản lý Nhà nước về an toàn thực phẩm là một yêu cầu được nhấn mạnh khi xây dựng dự Luật An toàn thực phẩm.

Thực ra không có một phương pháp tuyệt đối để xác định những nhiệm vụ nào thì được coi là liên quan và nên được xếp vào cũng một module, hay những nhiệm vụ nào là không phù hợp với một module nào đó. Tuy nhiên, có một cách rất hữu dụng, là kiểm tra tên của một class hay method. Nếu bạn không thể kiếm một cái tên phù hợp cho class, bạn nên kiểm tra xem nhiệm vụ của module tương ứng đã được định nghĩa rõ ràng chưa. Cũng vậy, nếu tên của một method có từ and hoặc chứa hai hành động trở lên, thì bạn nên xem xét phân tách method thành nhiều method nhỏ hơn. Về các lời khuyên liên quan đến cách đặt tên, xem thêm Code complete.

Tiếp theo là coupling. Coupling là khái niệm chỉ độ phụ thuộc giữa các module với nhau khi thực hiện một chức năng nào đó. Cũng như cohesion, coupling được chia làm nhiều cấp độ, và một thiết kế tốt sẽ cho coupling thấp (loose coupling). Thế nào là phụ thuộc? Đó là khi một module khi hoạt động phải hiểu biết về chức năng và cách hoạt động của các module khác. Chẳng hạn, khi một class dùng chung một vùng nhớ (một object chẳng hạn) với class khác, thì class này phải hiểu rõ class kia sẽ làm gì với vùng nhớ chung đó, và vậy là có coupling giữa hai class. Có rất nhiều dạng coupling, có dạng chấp nhận được, có dạng nên hạn chế, bạn có thể xem thêm trong Code complete.

Lí do phải giảm coupling là vì nếu nhiều module couple chặt với nhau, thì khi bạn thiết kế lại một module, bạn sẽ phải kiểm tra tất cả các module còn lại, và coupling càng chặt thì khả năng các module còn lại này bị thay đổi càng cao. Ngoài ra, có một số dạng coupling ngầm tương đối khó nhận ra, điều này sẽ làm cho việc thay đổi càng khó khăn hơn. Bạn có thể liên hệ với thủ tục hành chính. Nếu người dân phải đi qua nhiều bước thủ tục thì khi các bước này bị thay đổi, người ta phải tuyên truyền lại cho nhiều chục triệu người dân lẫn nhân viên hành chính. Nếu các bước thủ tục này được encapsulate lại thành một bước duy nhất (“một cửa”) thì người ta chỉ phải đến, đưa hồ sơ (“input”) và lấy kết quả (“output”). Thay đổi về thủ tục bây giờ chỉ đòi hỏi đào tạo lại các nhân viên bên trong.

Bạn có thể thấy cohesion và coupling phần nào phản ánh hai nguyên tắc ban đầu.

HM thấy trên mạng có một số người hỏi về kiến trúc phân lớp (layered) và kiến trúc n-tier. Cũng như nhiều khái niệm khác, nếu tỉ mỉ đi vào chi tiết thì chắc không có định nghĩa thống nhất, tuy nhiên nếu để nắm ý tưởng chung, thì có lẽ tốt nhất là xem "Microsoft application architecture guide" (Microsoft viết mà sai thì chịu thôi ). Tải miễn phí tại Microsoft, hoặc đọc trong mục patterns & practices của MSDN. Dưới đây tóm lược các ý chính:

Kiến trúc phân lớp nhóm các chức năng liên quan đến nhau trong từng lớp (layer). Các chức năng ở một lớp khi làm nhiệm vụ của mình có thể sử dụng các chức năng mà lớp dưới nó cung cấp. Có hai dạng

• Strict layering: Lớp trên chỉ liên hệ với lớp ở ngay dưới nó.
• Relaxed layering: Lớp trên có thể liên hệ với nhiều lớp dưới nó.

Khi nói về kiến trúc phân lớp, chúng ta nói về cách tổ chức luận lí của code, ví dụ thông qua các package, namespace, module, v.v. Không hề có gì gợi ý rằng các lớp phải chạy trên các máy khác nhau, hay thậm chí trong các process khác nhau.

Tier là nơi các lớp chạy. Các tier phải tách biệt với nhau về memory space. Nhưng cũng không có nghĩa là các tier phải chạy trên các máy khác nhau. Trong hệ điều hành, các process tách biệt với nhau về memory space, cho nên nếu bạn có một chương trình với hai lớp Presentation và Business Services chạy trên hai process giao tiếp với nhau dùng Web services thì bạn cũng đã có một hệ thống 2-tier rồi.

Các lớp có thể ở cùng một một tier, hoặc được phân tán trên nhiều tier (n-tier). Vậy một tier có thể có nhiều lớp. Tuy nhiên, thông thường với các hệ thống lớn, các tier sẽ không ở trên cùng một máy vật lí, vì các lí do về performance, scalability, fault tolerance, security v.v.

Giả sử bạn gặp tình huống xử lí trên một biến data kiểu Enumerable như sau:

var q = from d in data … select d;
foreach (var item in q) { doSomething(item); }

Nếu bạn muốn câu truy vấn q chạy ở chế độ song song (chẳng hạn, khi bạn có nhiều core và muốn tận dụng chúng) bạn dùng ParallelEnumerable.AsParallel():

var q = from d in data.AsParallel() … select d;
foreach (var item in q) { doSomething(item); }

Và nếu hàm doSomething() không quan tâm đến thứ tự xử lí của item (tức là gọi doSomething với item nào trước thì kết quả cũng ra như nhau) thì bạn cũng có thể chạy foreach ở chế độ song song:

var q = from d in data.AsParallel() … select d;
Parallel.ForEach(q, item => { doSomething(item) });

Nhưng bạn cũng có thể dùng ForAll với câu truy vấn q để đạt hiệu quả tương tự:

var q = (from d in data.AsParallel() … select d);
q.ForAll(item => { doSomething(item) });

Nhìn hai đoạn code cuối ta có cảm giác performance của chúng giống nhau, nhưng thực ra không phải như vậy. Tạm gọi đoạn code dùng Parallel.ForEach() là đoạn code (1) và đoạn code dùng ParallelEnumerable.ForAll() là đoạn code (2).

Các công việc mà đoạn code (1) thực hiện (không hoàn toàn chính xác trên thực tế, nhưng đủ để cho thấy sự khác biệt) là:

• Chạy câu truy vấn:
• Phân hoạch data ra thành nhiều phần (để chạy song song).
• Chạy câu truy vấn trên từng data, tạm gọi kết quả là q1, q2, q3, v.v.
• Trộn q1, q2, q3, v.v lại thành Enumerable object q.
• Chạy Parallel.ForEach():
• Phân hoạch q ra thành nhiều phần (để chạy song song).
• Gọi doSomething();

Sơ đồ minh họa cho đoạn code (1).

Đoạn code (1) lãng phí ở chỗ đầu tiên ta trộn các q1, q2, q3, v.v lại thành q, sau đó lại phân hoạch q ra. Sẽ tốt hơn nếu sau khi phân hoạch data, câu truy vấn được chạy, và các item lấy ra sẽ được cho vào doSomething() luôn. Nói cách khác doSomething() trở thành một phần trong hoạt động của câu truy vấn. Đó chính là cách mà đoạn code (2) thi hành. Dưới đây là sơ đồ minh họa cho đoạn code (2):

Đó là lí do lại sao đoạn code (2) cho performance tốt hơn, và được khuyên dùng trong những tình huống tương tự.

Nếu muốn tìm hiểu thêm về Parallel trong C#, bạn có thể đọc Paterns of Parallel Programming (sách miễn phí từ Microsoft).

Trước hết, bạn thử suy nghĩ, tại sao Java không giống C#, mà người ta lại dạy bạn là hai ngôn ngữ này đều là lập trình hướng đối tượng? Nếu bạn gặp thêm một ngôn ngữ X nào đó, làm sao bạn biết nó có hướng đối tượng? Hay nếu bạn vô tình đọc phải một cuốn như Object Oriented Programming With ANSI-C, bạn có dám nói C là một ngôn ngữ lập trình hướng đối tượng không?

Để trả lời những câu hỏi này, bạn phải hiểu lập trình hướng đối tượng là một paradigm. Paradigm định nghĩa các khái niệm mà chúng ta sẽ dùng để suy nghĩ về một vấn đề nào đó. Một số ngôn ngữ nào đó có thể cung cấp các tính năng cho phép chúng ta ứng dụng paradigm đó để hiện thực một cách dễ dàng, nhưng paradigm không bao giờ quy định cụ thể tính năng đó là gì, cú pháp ra sao, v.v. Chẳng hạn, paradigm cho lập trình hướng đối tượng nêu lên khái niệm encapsulation. Java dùng các modifier như public, private. Những người phát triển C# cho rằng property giúp tăng cường tính encapsulation, và họ đưa property vào những ngôn ngữ này. Những người phát triển Python lại lập luận rằng encapsulation không phải nhiệm vụ của trình dịch, nên trong Python không có cơ chế tạo private method, người ta ngầm quy ước method bắt đầu với “__” là private. Và cả Java, C#, Python đều được người phát triển chúng tuyên bố là có hỗ trợ lập trình hướng đối tượng. Nếu bạn hiểu encapsulation, bạn sẽ việc được code thỏa mãn tương đối tính chất này ở cả ba ngôn ngữ, nhưng nếu bạn chỉ học ngôn ngữ thôi, có thể code của bạn sẽ không có tính encapsulation. Hiểu một paradigm không chỉ giúp bạn khi sử dụng một ngôn ngữ được cho là hỗ trợ nó, mà bạn có thể áp dụng những khái niệm hay từ nó cho các ngôn ngữ khác, để làm cho code của bạn có chất lượng cao hơn (bạn thử nghĩ làm thể nào để tăng encapsulation trong C).

Cần chú ý là trong khi một ngôn ngữ có thể tốt hơn một ngôn ngữ khác, như C# 3.0 so với C# 2.0 (mặc dù so sánh này chỉ là tương đối), bạn không thể so sánh paradigm này có tốt hơn paradigm khác không. Mỗi paradigm đều thích hợp trong một số tình huống, và không thích hợp trong những tình huống khác. Ví dụ, paradigm lập trình hàm cổ vũ cho việc sử dụng immutable object, nhưng không phải mọi bài toán đều giải quyết được chỉ dùng immutable object. Hiểu rõ các paradigm sẽ giúp bạn không áp dụng chúng một cách cứng nhắc, nhờ đó lời giải của bạn cho các vấn đề sẽ trở nên uyển chuyển, hiệu quả hơn (ví dụ này có vẻ hợp). Cũng bởi vì không có paradigm nào là tốt nhất, các ngôn ngữ lập trình hiện đại thường đều ở dạng multiparadigm, trong đó có thể có một paradigm là chủ đạo. Muốn tận dụng tốt nhất các tính năng mà những ngôn ngữ này cung cấp, bạn phải hiểu thế mạnh của các paradigm và nhìn ra những tình huống ứng dụng chúng.

Cuối cùng, cũng như nhiều khái niệm khác như khoa học máy tính và kĩ thuật máy tính, strong typing và weak typing, các paradigm nói chung cũng được định nghĩa một cách tương đối hoặc trừu tượng. Cho nên có thể đôi khi bạn sẽ băn khoăn liệu paradigm này có phải là hệ quả hay là một cách phát biểu khác của paradigm kia, v.v. Trong trường hợp này có lẽ tốt nhất là khỏi phải suy nghĩ nhiều làm gì cho mệt , thế giới định nghĩa sao ta chấp nhận thế. Điều quan trọng khi tìm hiểu một paradigm là phải ghi nhớ những khái niệm quan trọng nhất mà nó cổ vũ, và nếu có thể thì học một ngôn ngữ được cho là đại diện cho nó. Như thế, khi đã thành thạo, cho dù bạn không thể định nghĩa paradigm này, bạn vẫn có thể rút ra được những phương pháp và kinh nghiệm hay cho việc lập trình. Có thể xem như paradigm tác động tới thiết kế của các ngôn ngữ, và ngược lại các ngôn ngữ góp phần định nghĩa nên paradigm.

• –projects: Làm việc với một vài module nhất định, chứ không phải toàn bộ project
• –also-make: Build các project mà module cần build (được chỉ ra bằng –projects) phụ thuộc
• –also-make-dependents: Build các project phụ thuộc vào module cần build (được chỉ ra bằng –projects).

Điểm tiện dụng của các option này là ta sẽ làm việc từ thư mục gốc của project, không cần phải chuyển vào từng module.

Giả sử ta có project A với các module như sau:

A
|_B
|_C -> B

(module C phụ thuộc module B).

Nếu bạn chưa install module B, các lệnh compile, test với C sẽ báo lỗi. Để test (hoặc compile) C một cách suôn sẻ, bạn dùng lệnh sau:

mvn –projects C test –also-make

Tất nhiên nếu module B đã ổn định, thì bạn nên install nó trước, bởi vì lệnh trên sẽ chạy test với cả module B. Để install module B, bạn dùng lệnh sau:

mvn –projects B install

Bây giờ khi làm việc với C, bạn không cần –also-make nữa. Không rõ vì sao mà ngay cả khi install B, thì HM vẫn không thể compile C được, vì java không resolve được các dependency(!). Thêm một lí do để dùng Maven từ dòng lệnh.

Và nếu bạn chính sửa gì đó ở module B, và muốn install lại, cùng với module C (để test, để kiểm tra xem bạn có break API của B không, v.v), bạn dùng lệnh sau:

mvn –project B install –also-make-dependents

Cuối cùng, nếu bạn muốn làm việc với nhiều module, chỉ cần phân tách giữa các module với dấu “,”:

mvn –project B,C

Gọn đẹp hơn dùng Eclipse, đúng không nào .

Dưới đây là các bước tạo một event. Xem thêm chi tiết ở đây.

public class CustomEventArgs: EventArgs {…} 
public delegate void CustomEventHandler(object sender, CustomEventArgs a); 
public event CustomEventHandler RaiseCustomEvent;

Nếu bạn dùng Generics, bạn không cần phải tự tạo delegate:

public class CustomEventArgs: EventArgs {…} 
public event EventHandler<CustomEventArgs> RaiseCustomEvent;

Nếu bạn không cần một class EventArgs riêng, bạn không phải tạo CustomEventArgs:

public event EventHandler<EventArgs> RaiseCustomEvent;

Raise event

Cần chú ý là bạn nên tách phần code để raise event ra khỏi phần code kiểm tra điều kiện và tạo EventArgs, vì bạn sẽ thấy tiếp theo đây, raise event đòi hỏi một số thao tác linh tinh có thể làm code của bạn rối rắm hơn:

void OnRaiseCustomEvent(CustomEventArgs e) { 
  if (RaiseCustomEvent != null) { 
    RaiseCustomEvent(this, e); 
  } 
}

Tại sao phải kiểm tra null? Vì nếu RaiseCustomEvent là null, tức là chưa có ai subscribe, lệnh raise event sẽ throw Exception.

Vẫn còn một vấn đề nữa. Trong một chương trình multithread, rất có khả năng một object nào đó sẽ hủy subscribe trước khi raise event, nhưng sau khi phép kiểm tra null xảy ra. Nếu việc hủy subscribe này làm cho event thành null, bạn hiểu điều gì sẽ xảy ra. Do đó, bạn phải tạo một bản copy cho event cần raise:

var handler = RaiseCustomEvent; 
if (handler != null) …

Bây giờ thì dù RaiseCustomEvent có thay đổi thế nào, handler event cũng không bị ảnh hưởng. Tại sao một phép copy lại làm được điều đó? C# copy reference chứ không copy value mà? Nếu bạn quan tâm, xin mời đọc tiếp. Nếu không, hãy an tâm như thế là đủ.

Rườm rà? Bạn không thích lặp lại đoạn mã này với tất cả các event, chẳng hạn khi bạn có quá nhiều event (Custom1, Custom2, v.v)? Có thể dùng extension method để làm cho code gọn đẹp hơn nữa, nhưng hẹn bài khác .

Vì sao vừa có event, vừa có delegate

Để ý rằng, với delegate, chúng ta cũng có các toán tử +=, –=, và cũng invoke được các delegate đã add, tương tự như event. Vậy tại sao chúng ta lại phải tạo event mà không dùng luôn delegate? Bởi vì nếu dùng delegate, sẽ có hai tình huống không mong đợi sau:

• Subscriber override các subscriber khác bằng toán tử =. Chẳng hạn, một cách vô tình, lệnh subscribe được viết là … = … Kết quả là tất cả các delegate đã add vào CustomEventHandler trước đó sẽ bị xóa.
• Subscriber có thể raise event bằng cách gọi delegate. Trong khi việc này lẽ ra chỉ nên được thực hiện bởi publisher.

Event thực chất được xây dựng dựa trên delegate, nhưng không cho phép các tình huống trên xảy ra. Khi khai báo một event, trình dịch sẽ ngầm tạo cho chúng ta một biến delegate private trong chính class chứa event. Lưu ý là event là một khái niệm ở mức CIL, vì vậy nó không đơn thuần chỉ là một wrapper cho delegate. Bạn có thể tham khảo đoạn mã dưới đây (từ quyển Essential C# 4.0), mô tả một cách sơ lược những gì trình dịch sẽ làm.

public delegate void CustomEventHandler(object sender, CustomEventArgs a);

private CustomEventHandler customEventHandler;

public void add_CustomEventHandler(CustomEventHandler handler) { 
  System.Delegate.Combine(customEventHandler, handler); 
}

public void remove_CustomEventHandler(CustomEventHandler handler) { 
  System.Delegate.Remove(customEventHandler, handler); 
}

public event CustomEventHandler customEventHandler { 
  add { add_customEventHandler(value) } 
  remove { remove_customEventHandler(value) } 
}

Và delegate là một immutable type

Để dễ hiểu, hãy xét kiểu string, cũng immutable, và cũng hỗ trợ toán tử += như delegate:

string s1 = "old"; 
string s2 = s1; 
s1 += “new”;

s2 vẫn sẽ là “old”, vì khi gán s1 += “new”, một chuỗi mới sẽ được tạo ra với giá trị là “oldnew”, và s1 sẽ trỏ sang chuỗi mới đó. Chuỗi s2, tất nhiên vẫn trỏ tới chuỗi cũ. Bây giờ xem lại phần copy trong raise event, bạn sẽ thấy vấn đề hoàn toàn sáng tỏ.

(Xóa phần immutable object, vì HM muốn viết nó thành một bài riêng)

• Lí do khiến dynamic được đưa vào C# là để làm việc với COM (chú ý là cả COM cũng phải được “tân trang” thì mới tận dụng được dynamic), và các ngôn ngữ dynamic như Ruby, Python được đơn giản hơn. Các ứng dụng phát sinh thêm như ở đây không phải là lí do chính thức.
• dynamic là một built-in type như int và float, chứ không phải một syntax mới. Các biến dynamic cũng là object. Với các biến kiểu dynamic, trình biên dịch C# sẽ không thực hiện kiểm tra kiểu lúc biên dịch mà chỉ đóng gói các thông tin cần thiết để phân giải lúc runtime lời gọi các method của dynamic object. Lí do đằng sau thiết kế này là Microsoft không muốn thay đổi tính chất static typing của C#, và cũng không muốn lập trình viên dùng dynamic một cách không có chủ ý.
• dynamic là một contextual keyword (bạn thử khai báo int dynamic = 1; xem).
• dynamic dùng các dịch vụ của Dynamic Language Runtime (DLR). DLR là thư viện (chứ không phải runtime như CLR, mặc dù tên gọi có từ “runtime”) cung cấp các dịch vụ cần thiết khi xây dựng các ngôn ngữ dynamic trên nền .NET. Có thể coi dynamic là syntactic sugar để sử dụng DLR trong C#. Khi các ngôn ngữ dynamic trên nền .NET sử dụng DLR, việc cộng tác với nhau sẽ đơn giản hơn.
• Dynamic object expose các method, property vào lúc runtime, nói cách khác, nó có thể tự dispatch thông điệp gửi đến nó. Khi gán một object cho biến kiểu dynamic, trình dịch wrap các object này vào các dynamic object.
• Lập trình viên C# có thể lựa chọn dùng hoặc không dùng dynamic khi làm việc với COM và các ngôn ngữ dynamic. Điều này phụ thuộc vào sở thích.

Tham khảo blog của hai lập trình viên này ở đây và ở đây nếu muốn biết sâu hơn về dynamic (có thể dùng thay thuốc ngủ ).

Cách dùng thì đơn giản rồi, điều quan trọng là khi nào thì dùng dynamic? Xem bài này nếu bạn quan tâm đến lí do chính thức mà Microsoft đưa dynamic vào C#. Ở đây chỉ nói về một ví dụ rất đơn giản mà các sách hay dùng.

Static typing giúp phát hiện các lỗi về method signature (ví dụ, trình dịch sẽ bắt lỗi khi bạn truyền thiếu tham số), type compability (ví dụ, bạn không thể gán object kiểu Book cho biến kiểu Car được). Hơn nữa, Intellisense (chức năng nhắc mã trong IDE) chỉ hoạt động được với các biến static (vì biến dynamic không có thông tin về kiểu). Như vậy có vẻ static typing là một lựa chọn quá an toàn, quá tiện lợi, và không có lí do gì để dùng dynamic trong C#.

Tuy nhiên, theo như một số sách và trang web, thì có những tình huống mà static typing cũng không giúp phát hiện lỗi cho chúng ta, chẳng hạn như khi parse XML:

string bookDef = "<Book><Title>The wedding singer</Title></Book>" 
XElement book = XElement.Parse(bookDef); 
Console.WriteLine(book.Descendants("Title").FirstOrDefault().Value);

bookDef có thể là string được tạo sẵn, cũng có thể do người dùng nhập vào, hay đọc từ tập tin, v.v. Dù thế nào đi nữa, trình dịch không thể (và không quan tâm) giá trị của nó khi dịch lệnh XElement book… Điều đó nghĩa là nếu bạn lỡ viết nhầm “Title” thành “Tittle” trong lệnh Console.WriteLine, trình dịch cũng không thể phát hiện được, và bạn sẽ nhận Exception vào lúc runtime.

string bookDef = "<Book><Title>The wedding singer</Title></Book>" 
dynamic book = DynamicXml.Parse(bookDef); 
Console.WriteLine(book.Title);

XML được parse lúc runtime thành một object, với property là các element. Object này được gán cho book, và chúng ta có thể lấy thông tin từ XML một cách rất… OOP. Điều này có thể thực hiện được với static typing sử dụng Reflection, nhưng dynamic giúp cho công việc trở nên đơn giản hơn rất nhiều. Và chúng ta cũng không mất gì cả, vì đằng nào thì static typing cũng không giúp bắt những lỗi như “Tittle” khi biên dịch.

Để xây dựng DynamicXml, tham khảo hướng dẫn của MSDN.

Chú ý là có những thứ trong XML khó có thể diễn tả trong C#, như namespace, quy tắc đặt tên, v.v, cho nên ví dụ này chỉ ở mức ứng dụng là làm ví dụ . HM nghĩ nếu xây dựng được một DynamicXml hỗ trợ đầy đủ XML, thì việc sử dụng nó cũng chả đơn giản hơn XElement là mấy (chưa nói đến chúng ta đã có LINQ2XML).

Dĩ nhiên là dynamic có những lí do hợp lí để tồn tại, nhưng đó là chuyện khác.

Bây giờ ta có lệnh gán IList<Mammal> a = new List<Elephant>(). Vì a có kiểu khai báo là IList<Mammal>, nó có thể gọi method void Add(Mammal item). Tuy nhiên, List<Elephant>() lại chỉ hiện thực method void Add(Elephant item), nên ta không thể gọi a.Add(tiger). Do đó có hai phương án. Phương án thứ nhất là trình biên dịch chấp nhận lệnh gán trên, các tình huống gây lỗi sẽ được bắt lúc runtime. Phương án thứ hai là không cho biên dịch lệnh gán này. C# chọn phương án thứ hai. Lí do có lẽ là để phù hợp với quan điểm về static typing.

Còn method Mammal Get(int index)? Giả sử ta gọi Mammal b = a.Get(0). Bởi vì List<Elephant> hiện thực method Elephant Get(int index), và Elephant là con của Mammal, nên lệnh gọi này hoàn toàn hợp lệ cả lúc biên dịch lẫn runtime.

Như vậy, nếu chúng ta chỉ sử dụng type T (trong IList<T>) cho các giá trị output, thì sẽ không bao giờ xảy ra chuyện rắc rối như với a.Add(Elephant item). Chính vì lí do này, C# 4.0 giới thiệu thêm kí hiệu out cho phép ta chú thích với trình biên dịch rằng, type T chỉ dùng cho output. Nói cách khác, nếu IList<T> chỉ có method Get, ta có thể khai báo interface này là IList<out T>, và khi đó IList<Mammal> a = new List<Elephant>() là một phép gán hợp lệ.

Trong tình huống ngược lại, IList<Elephant> a = new List<Mammal>(), thì method Get mới lại là kẻ gây rắc rối. Vì method này trong IList<Elephant> trả về Elephant, còn hiện thực của List<Mammal> lại trả về Mammal, và tất nhiên không phải tất cả các Mammal đều là Elephant. Tương tự như trường hợp ban đầu, nếu ở đây, IList<T> không có Get, tức là T không được dùng cho giá trị output mà chỉ cho input, thì phép gán sẽ hoàn toàn hợp lệ. Để chú thích cho trình duyệt điều này, ta dùng từ khóa in, tương tự như out.

Còn hai thuật ngữ covariance và contravariance liên quan gì đến in và out? Dựa vào bài viết này, có thể liên hệ như sau: IList<out T> cho phép bảo toàn chiều “lớn hơn” giữa Mammal và Elephant, còn IList<in T> đảo chiều “lớn hơn” giữa Elephant và Mammal.

Nãy giờ bạn có thắc mắc tại sao lại là IList<…> a = new List<…> chứ không phải List<…> a = new List<…> không? Đó là vì CLR chỉ hỗ trợ tính năng này cho interface và delegate (theo "C# in depth”). Vậy tại sao CLR lại chỉ hỗ trợ như vậy. Câu trả lời dễ hiểu nhất mà HM từng thấy là ở đây, do một thành viên trong nhóm Visual C# đưa ra:

Sure, that’s a reasonable example but you haven’t shown anything that couldn’t also be done with interfaces. Just make interface ILookup<out T> and have Lookup<T> implement it. What compelling additional benefit over interface variance does your scenario for class variance add?

We don’t have to provide a justification for not implementing a feature. Not implementing a feature is free. Rather, we have to provide a justification for implementing a feature — features can cost millions of dollars to Microsoft, and impose an even larger burden upon our customers who must then spend time and money learning about the feature.

Đoạn comment thứ hai cho chúng ta thêm một câu hỏi: vậy tính năng vừa bàn ở trên trong C# 4.0 dùng để làm gì? Khi nào thì dùng? Cái này thì phải suy nghĩ đã .

Ngắn:

• Chapter 6 – Agile principles, patterns, and practices in C# – by Martin C. Robert, Martin Micah. Khá thú vị. Xem online tại đây.
• Phần 3, 4, 5 của Craftsman.

Trung bình:

• Part I – Test-Driven Development by example – Kent Beck.
• Part III – Test-Driven Development: A practical guide – David Astels.
• Phần 6, 7, 8, 9, 10 của Craftsman.

Dài:

• Part II – Test-Driven Development in Microsoft .NET – James W. Newkirk, Alexei A. Vorontsov.
• Part III – Growing object-oriented software, guided by test – Steve Freeman, Nat Pryce.

Đặc biệt, nếu bạn có thời gian, không thể bỏ qua bộ Craftsman.

Trước hết phải dạo qua bước thủ tục đã. Tại sao lập trình viên nên dùng tài liệu tiếng Anh (chứ không phải là tiếng Việt)?

• Sách tiếng Anh (tất nhiên là những quyển hay nhất) có chất lượng tốt hơn sách tiếng Việt. Nói chính xác hơn, sách lập trình tiếng Việt đa phần rất tệ (và rất mỏng), chỉ lướt qua các kiến thức bề mặt chứ ít khi đi sâu vào cốt lõi của vấn đề. Ngoại lệ có lẽ là các sách dịch.
• Phần lớn các công nghệ phổ biến đều được phát triển bởi các công ti Mĩ. Tài liệu hỗ trợ vì thế sẽ viết bằng tiếng Anh là chủ yếu. Nếu có dịch sang tiếng khác thì cũng còn lâu tiếng Việt mới tới lượt.
• Stack Overflow. Đây là trang web hỏi đáp nổi tiếng nhất cho lập trình viên. Ngay cả những vấn đề chưa được tài liệu hóa thì bạn cũng có cơ hội tìm được câu trả lời ở đây. Thậm chí cỗ máy tìm kiếm của MSDN cũng lấy các kết quả từ Stack Overflow. Tiếng Anh là ngôn ngữ duy nhất được dùng trên trang này.
• Sách điện tử tiếng Anh rất dễ kiếm, đủ đề tài từ lập trình đến dạy hẹn hò (tất nhiên, tải sách điện tử “lậu” là không hợp pháp).

Vậy làm sao để đọc tài liệu tiếng Anh? Thứ nhất là phải học tiếng Anh. Nếu học nghiêm túc thì chắc bằng A là đủ rồi. Thứ hai, phải luyện tập. Bạn cần phải:

• Bớt thời gian tìm kiếm sách học tiếng Anh, rồi lời khuyên học tiếng Anh, v.v đi. Chỉ có luyện tập mới tạo nên sự hoàn thiện.
• Tập đọc tài liệu. Tất nhiên HM không thể có dẫn chứng xác thực, nhưng có rất nhiều sinh viên mắc bệnh lười đọc, hiếm khi đọc trọn vẹn giáo trình cho môn học, mà chỉ phụ thuộc vào bài giảng của giáo viên. Nếu thi trắc nghiệm thì có khi chỉ cần giải đề năm trước và học thuộc là đã có thể qua (và qua với điểm khá) . Chỉ nhìn cái gì nhiều chữ đã nản thì còn tính gì đến tiếng Anh tiếng Việt, hơn nữa tài liệu tiếng Anh lúc nào cũng dài, chi tiết, dày đặc chữ. Tập càng sớm càng tốt, ngay từ môn học đầu tiên. Đừng sợ hãi những bài báo 8-9 trang, hay những quyển sách dày 400-500 trang, nếu nội dung của nó thật sự có ích. Đừng trông chờ một ai đó (kể cả Google) lúc nào cũng có thể trả lời cho bạn những câu hỏi kiểu như làm sao hiện thực thuật toán tìm đường ngắn nhất, thuật toán Euclid mở rộng là gì. Đừng phụ thuộc vào những bài giảng trên lớp. Hãy đọc sách và động não.
• Đừng sợ tiếng Anh. Bạn sẽ không bao giờ đọc tốt tiếng Anh nếu bạn không đủ kiên nhẫn và quyết tâm đọc nó. Nhiều người mặc dù đã được học tiếng Anh khá bài bản nhưng vấn có tâm lí này. Chỉ cần cấu trúc của câu phức tạp một chút, chỉ cần đoạn văn dài một chút, là họ đã bỏ qua rồi. Đừng làm thế. Hãy kiên nhẫn đọc cho hiểu từ những câu thông báo ngắn trên màn hình đến những bài báo dài từ Wikipedia tiếng Anh. Cố gắng đừng đóng lại một trang web chỉ vì nó viết bằng tiếng Anh, hãy đóng nó chỉ khi nó không hữu ích.
• Đọc tiếng Anh thật nhiều. Bạn có tin là thậm chí một quyển sách tiếng Anh cấp hai cũng giúp bạn cải thiện khả năng đọc tiếng Anh không? Khi đọc một câu tiếng Anh, đừng dịch nó qua tiếng Việt rồi mới hiểu nó, mà hãy cố gắng hiểu trực tiếp bằng tiếng Anh. Coi như những từ tiếng Anh đó chẳng qua là từ tiếng Việt. Chẳng hạn, apple là táo. Vậy táo là gì? Nếu bạn không định nghĩa được táo là gì, mà chỉ nghĩ táo là táo, thì cũng hãy nghĩ apple là apple thôi.
• Đừng đọc cà nhắc. Tập trung vào cấu trúc của câu, xem câu đó nói gì, hơn là tập trung vào nghĩa của từng từ. Nếu nghĩa của từ đó không cần thiết cho việc hiểu cả câu thì lơ nó đi cũng được, khi gặp nhiều lần hãy tra. Nếu bạn phải dừng lại tra từ quá nhiều, bạn sẽ không tóm gọn được ý nghĩa của cả đoạn, và hơn nữa bạn cũng sẽ chóng chán đọc tiếng Anh.
• Đừng xấu hổ. Nếu bạn chưa thạo thì bạn đọc chậm. Nếu không hiểu thì nói là không hiểu. Nhất là lúc đầu khi tập đọc tiếng Anh mà không dịch trung gian qua tiếng Việt mọi thứ sẽ rất khó khăn và mất nhiều thời gian. Cũng giống như tập gõ bàn phím mười ngón vậy, lúc đầu chắc chắn người tập sẽ gõ chậm hơn gõ “mổ cò”, nhưng sau cùng họ sẽ gõ nhanh hơn hẳn những người “mổ cò” (cộng với việc không cần nhìn bàn phím).
• Đừng dừng lại. Ngay cả khi bạn đọc tiếng Anh như tiếng Việt, thì cũng không có nghĩa là bạn có thể dừng lại. Hãy đọc thêm tiếng Anh ở nhiều lĩnh vực khác, mở rộng vốn từ của mình, tập viết tiếng Anh nhiều hơn để tăng cường trình độ tiếng Anh của mình. Tại sao? HM không thể trả lời được, nhưng HM nghĩ sự tự mãn, dù nhỏ hay lớn, khi đã xuất hiện sẽ làm con người ta tiêu tan ý chí phấn đấu, trở nên sợ hãi và dừng bước trước những thử thách vượt quá khả năng.

Một số công cụ rất hữu ích:

• Simple English Wikipedia. Wikipedia phiên bản chỉ dùng tiếng Anh đơn giản. Vì là Wikipedia chắc chắn sẽ có chủ đề thú vị với bạn.
• Englishforums.com. Ở đây lúc nào cũng có giáo viên hoặc người bản xứ trả lời câu hỏi của bạn.
• Lingoes. Từ điển, giống Babylon, nhưng miễn phí.

Mong là một ngày nào đó blog này sẽ không còn lượt truy cập nào nữa .

Tại sao không dùng println cho việc logging? Bởi vì chúng quá thô sơ. Một giải pháp logging, có lẽ phải đáp ứng các yêu cầu sau:

• Tùy biến:
  • Bật, tắt logging (toàn bộ hoặc theo loại thông điệp.
  • Vị trí xuất log (màn hình, tập tin, database, v.v)
  • Định dạng, lượng thông tin cần log
• Thông tin có thể log:
  • Vị trí gọi log
  • Thời gian
  • Thông điệp, stack trace, v.v

Có nhiều logging framework trong Java, trong đó nổi tiếng nhất là Log4J. Để thuận tiện khi chuyển đổi giữa các logging framework, người ta phát triển facade chung cho chúng. Không may là cũng lại có hơn một facade (Java là thế). Hiện nay, các dự án có vẻ đang ưa chuộng facade SLF4J. API của SLF4J được framework logback hiện thực trực tiếp (native implementation). Ngoài tính dễ sử dụng, SLF4J còn có một lợi thế là được phát triển bởi tác giả của Log4J—tất nhiên là người hiểu rõ các hạn chế của Log4J.

Dưới đây là một ví dụ nhỏ về SLF4J. Tài liệu hướng dẫn và cả javadoc của SLF4J và logback đã rất cụ thể và đầy đủ, nên nếu bạn muốn tìm hiểu sâu hơn thì đó là nơi tốt nhất để bắt đầu.

Mặc định của logback là log ra console:

import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 
public class HelloWorld { 
  public static void main(String[] args) { 
    Logger logger = LoggerFactory.getLogger("HelloWorld"); 
    logger.debug("Hello world."); 
  } 
}

Kết quả (console):

22:12:35.261 [main] DEBUG HelloWorld - Hello world.

Sửa đổi tập tin cấu hình (thường là logback.xml) và ta sẽ log được ra tập tin:

<configuration> 
  <appender name="FILE" class="ch.qos.logback.core.FileAppender"> 
    <file>hw.log</file> 
    <encoder> 
      <pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</pattern> 
    </encoder> 
  </appender> 
  <root level="debug"> 
    <appender-ref ref="FILE" /> 
  </root> 
</configuration>

Kết quả (trong tập tin hw.log):

2010-08-21 21:35:57,583 DEBUG [main] HelloWorld [HelloWorld.java:7] Hello world.

Tuy nhiên, để unit test hiệu quả, chúng ta cần có các công cụ để tiến hành nó một cách tự động. Các công cụ này gọi là unit test framework. Với Java, framework nổi tiếng nhất là JUnit.

Nếu bạn muốn tìm hiểu về JUnit, thì bạn nên đọc “JUnit in action”. Dưới đây là một ví dụ nhỏ về JUnit để bạn tham khảo.

Kiểm tra với một test case

Giả sử chúng ta có một class Number như dưới đây. Mỗi object của class đại diện cho một số nguyên. Method isEven kiểm tra tính chẵn lẻ của số nguyên đó. Mục tiêu của chúng ta là kiểm tra tính đúng đắn của method isEvent.

public class Number { 
    private int number; 
    public Number(int number) { this.number = number; } 
    public boolean isEven() { return (number % 2 == 0)?true:false; } 
}

Việc đầu tiên là tải tập tin junit-4.x.x.jar và cho nó vào CLASSPATH. Đoạn mã dưới đây sẽ kiểm tra isEvent với 2.

import static org.junit.Assert.*; 
import org.junit.Test; 
public class NumberTest { 
    @Test public void testIsEven() { 
        Number number = new Number(2); 
        assertTrue(number.isEven()); 
    } 
}

Dịch hai đoạn mã trên và chạy lệnh java org.junit.runner.JUnitCore NumberTest. Khi đó JUnit sẽ chạy các method được đánh dấu @Test. Kết quả là:

JUnit version 4.8.2 
. 
Time: 0.008 
OK (1 test)

Kiểm tra với nhiều test case

Bây giờ ta muốn kiếm tra với nhiều số hơn. Chúng ta sẽ không chèn thêm assertTrue vào testIsEven (vì như vậy sẽ không thể biết được số nào làm cho test bị sai). Thay vào đó, chúng ta sẽ tham số hóa method testIsEven. Các tham số được lấy từ bộ test tạo ra bởi method getTestParameters.

import static org.junit.Assert.*; 
import org.junit.Test; 
import org.junit.runner.RunWith; 
import org.junit.runners.Parameterized; 
import org.junit.runners.Parameterized.Parameters; 
import java.util.Arrays; 
import java.util.Collection;  

@RunWith(value=Parameterized.class) 
public class NumberParameterizedTest { 
    private int value; 
    private boolean expected; 
    public NumberParameterizedTest(int value, boolean expected) { 
        this.value = value; 
        this.expected = expected; 
    } 
    @Parameters public static Collection<Object[]> getTestParameters() { 
        return Arrays.asList(new Object[][] { {2, true}, {3, false}, {5, true}, }); 
    } 
    @Test public void testIsEven() { 
        Number number = new Number(value); 
        assertEquals(number.isEven(), expected); 
    } 
}

Lần này, Junit sẽ lần lượt lấy từng mẫu ra để kiểm tra. Kết quả là (trích):

JUnit version 4.8.2 
...E 
Time: 0.022 
There was 1 failure: 
1) testIsEven[2](NumberParameterizedTest)...

Như vậy là test sai với mẫu thứ ba (5, true) (vì đếm từ 0).

Kiểm tra Exception

Trong một số trường hợp, một method sẽ throw Exception thay vì trả về kết quả tính toán. Để đảm bảo hành vi của method đúng như mong đợi, chúng ta phải test cả những trường hợp này để xem chúng có throw đúng Exception cần throw không. @Test(expected=YourException.class) là annotation phục vụ cho mục đích này.

Dùng test làm hướng dẫn sử dụng

Hãy nhìn lại đoạn code trên. Khi đọc test (nếu bạn hiểu JUnit), bạn sẽ suy ra ngay cách sử dụng method isEven: đầu tiên tạo một object Number với constructor nhận vào giá trị int, sau đó gọi isEven(). Vậy là, test code còn một tác dụng khác là làm hướng dẫn sử dụng (tương tự như các đoạn code trong tutorial trên mạng). Ưu điểm của việc lấy test làm hướng dẫn sử dụng là nhanh gọn và bám sát theo thay đổi của chương trình.

class Outer {
	SomeClass o;
	public void OuterMethod() {
		int a;
		class Inner {
			public void InnerMethod() {
				// Do something
			}
		}
		Inner i = new Inner;
		o = new SomeClass(i);
	}
}

Ở đây, i và a là các local variable của method OuterMethod. Khi method này kết thúc, i và a sẽ bị xóa khỏi stack. Thế còn object mà i trỏ tới liệu có bị Garbage Collector xóa? Câu trả lời là tùy từng trường hợp. Vì i đã được pass cho object o, nếu o lưu lại một reference để trỏ tới object mà i đang trỏ tới, thì object này chưa đủ điều kiện để bị thu hồi vùng nhớ. Điều đáng nói ở đây là object mà i trỏ tới có thể tồn tại lâu hơn method OuterMethod. Bây giờ, nếu trong phần mã của InnerMethod có một method nào đó sử dụng i, và method này được chạy khi method OuterMethod đã kết thúc (nghĩa là i đã bị xóa), thì nó sẽ lấy i ở đâu ra? Tất nhiên, nó không thể lấy được i ở đâu cả. Để tránh tình huống này, Java không cho mã của method-local inner class truy xuất variable của method chứa nó, trừ khi variable là final.

Xét tiếp phần “final” của vấn đề. Vì final variable không thể bị thay đổi một khi đã được gán giá trị, cho nên object của inner class có thể copy lại. Vậy tại sao không copy các variable còn lại? Rất đơn giản, nếu biến int i được copy, thì khi đó i của object và i của method không liên hệ gì với nhau, mọi thay đổi của i trong object không ảnh hưởng gì đến i của method, nghĩa là việc copy i cũng chỉ tương đương với việc chúng ta truyền i vào trong object thông qua constructor hoặc method bình thường, không hơn không kém. Hoàn toàn không cần thiết phải đưa thêm một tính năng khi nó không thực sự giúp giải quyết vấn đề gì.

Static/dynamic typing

Đây là cách phân loại dựa vào thời điểm thực hiện kiểm tra kiểu.

Một ngôn ngữ lập trình thuộc dạng static typing (định kiểu chặt?) khi phần lớn công việc kiểm tra kiểu được thực hiện lúc biên dịch. Do khi biên dịch ta không thể xác định được giá trị của biến tại vị trí bất kì trong chương trình, trình biên dịch ngôn ngữ static typing phải gán kiểu cho biến ngay từ đầu (nhờ lập trình viên khai báo hoặc tự xác định khi biến được khởi tạo).

Trong khi đó, ngôn ngữ dạng dynamic typing kiểm tra kiểu lúc runtime. Kiểu của biến được xác định dựa vào giá trị của nó lúc sử dụng. Do đó, việc gán kiểu cho biến lúc biên dịch là không cần thiết (gán cũng được, nhưng như thế thì không cần đến dynamic typing nữa).

C là ngôn ngữ static typing, còn Python là ngôn ngữ dynamic typing. Để hiểu thêm, so sánh sự khác nhau giữa var (static typing) và dynamic (dynamic typing) trong C#.

Strong/weak typing

Khi kiểu của tham số trong một biểu thức không phù hợp, trình biên dịch phải chuyển tham số này thành kiểu đúng, rồi mới tính giá trì biểu thức. Tùy thuộc vào khả năng chuyển đổi giữa các kiểu với nhau mà chúng ta coi ngôn ngữ lập trình là strong typing hay weak typing. Ví dụ, C được xem là weak typing so với Java (nhớ là trong C ta có thể viết if (1) {} nhưng trong Java thì không). Python và Perl đều là ngôn ngữ dynamic typing, nhưng Perl được xem là weak typing so với Python (nhớ là biểu thức 1+”1” chỉ có ý nghĩa trong Perl).

Nói chung cách phân chia strong/weak này không có tiêu chuẩn gì, vì vậy ít được dùng một cách nghiêm túc. Tuy nhiên nhầm lẫn giữa hai cách phân loại static/dynamic và strong/weak thì cũng không hay chút nào.

Trước hết, cho hai class Animal và Cat:

class Animal {} 
class Cat extends Animal {}

Tiếp theo cho class Hunter và BetterHunter:

class Hunter { 
    public void Kill(Animal a) { System.out.println("Hunter killed Animal"); } 
    public void Kill(Cat c) { System.out.println("Hunter killed Cat"); } 
} 
class BetterHunter extends Hunter { 
    public void Kill(Animal a) { System.out.println("BetterHunter killed Animal"); } 
    public void Kill(Cat c) { System.out.println("BetterHunter killed Cat"); } 
}

Bây giờ xét tình huống sau, kết quả in ra là gì?

Animal a = new Cat(); 
Hunter h = new BetterHunter(); 
h.Kill(a);

Vì h trỏ đến BetterHunter, JVM phân giải h.Kill thành Kill của BetterHunter. Sau đó, vì a trỏ đến Cat, JVM chọn Kill(Cat). Kết quả là “BetterHunter killed Cat”.

Sai. Java chỉ hỗ trợ Single dispatch, vì overriding được hiện thực nhờ vtable. Nói cách khác JVM chỉ phân giải method dựa vào tham số đầu tiên (this). Bước thứ hai (chọn Kill nào) được thực hiện trong lúc biên dịch (overload). Vì vậy Kill của BetterHunter vẫn được gọi, nhưng là Kill(Animal). Kết quả là “BetterHunter killed Animal”.

Để có Double dispatch, tức là gọi Kill(Cat), xem Thinking in Java, hoặc pattern Visitor.

Tuy nhiên theo ý kiến chung là không nên dùng Singleton vì:

• Khó thay đổi, mở rộng. Singleton dùng method static. Class con có thể hide method static, nhưng không thể override chúng.
• Vi phạm nguyên tắc Explicit interface với các module dùng cùng một Singleton (tuy nhiên, đây không phải là luật).
• Gây trở ngại cho unit test. Đây là hệ quả của lí do đầu tiên (xem nhanh).

Khi nào thì dùng Singleton? Bài viết này đề xuất:

• Nếu tính chất “Singleton” không phải là bản chất của class, mà là do class dùng nó yêu cầu thế, thì tính duy nhất nên được hiện thực theo một cách độc lập, như Factory Method hay Dependency Injection.
• Nếu tính chất “Singleton” là bản chất của class, xem xét việc dùng biến static để lưu trạng thái của instance (vẫn đem lại tính “duy nhất”), trước khi dùng đến phương pháp trong Gang of Four (vốn dùng cả method static).

Xem thêm Use your singletons wisely.

Khác với C/C++, việc thu hồi vùng nhớ trong Java được thực hiện bởi Gabage Collector (GC). Các vùng nhớ không còn được trỏ tới sẽ có khả năng bị thu hồi (mặc dù ta không thể đảm bảo được thời điểm mà GC sẽ thực hiện điều đó) (không còn memory leak). Và tất nhiên, các vùng nhớ vẫn còn được trỏ tới bởi ít nhất một reference sẽ không bị thu hồi (không còn dangling pointer).

Vùng nhớ chỉ thỏa mãn tiêu chuẩn thu hồi khi không còn reference nào trỏ tới. Điều này nghĩa là ta phải nhớ xóa tất cả các reference tới vùng nhớ không còn dùng. Và thông thường, chuyện này không có gì phức tạp, chỉ cần trỏ reference tới vùng nhớ khác, tới null, hoặc để reference tự biến mất khi ra khỏi block chứa nó (chẳng hạn, khi method khai báo reference đó kết thúc). Nói chung là đa số được thực hiện một cách “vô tình”, tức là ta thậm chí không để ý là mình đang làm điều đó.

Nhưng có những tình huống mà chúng ta phải chủ động xóa reference, ví dụ như khi làm việc với Listener. Để A có thể nhận thông báo về các event mới trong B, nó phải được thêm vào danh sách Listener của B, giả sử bằng method addActionListener. Khi muốn kết thúc sự tồn tại của A, ta cần để đưa A ra khỏi danh sách, giả sử bằng removeActionListener. Đây là điều bắt buộc khi chúng ta muốn vùng nhớ của A có thể được thu hồi, vì chừng nào A còn nằm trong danh sách Listener thì vẫn còn reference trỏ đến nó. Tất nhiên, triển vọng là ta sẽ quên làm việc đó, như cái cách chúng ta quên giải phóng bộ nhớ trong C/C++. Chưa kể đến các tình huống đau đầu như có vài vị trí (ví dụ như vài nhánh if) có thể kết thúc A, đồng nghĩa với việc có vài vị trí cần gọi removeActionListener .

Như vậy, mặc dù phần mềm viết bằng Java không có kiểu memory leak như C/C++, nhưng vẫn có thể có những vùng nhớ không còn sử dụng, song cũng không thể bị thu hồi, đó chính là memory leak “kiểu Java”.

Chính vì lí do trên, Java cho chúng ta thêm một số dạng reference đặc biệt trong package java.lang.ref, là WeakReference (WR) và SoftReference (SR). Các reference này cũng được dùng để trỏ tới các vùng nhớ, như reference mà chúng ta vẫn quen dùng (giờ gọi là strong reference). Tuy nhiên, nếu vùng nhớ được trỏ tới bởi cả strong reference lẫn WR, thì khi strong reference cuối cùng bị xóa bỏ, vùng nhớ này có thể được thu hồi bởi GC, và WR không có khả năng ngăn cản điều đó. SR “strong” hơn WR một chút, nghĩa là vùng nhớ được trỏ tới bởi WR sẽ được GC ưu tiên thu hồi hơn (ưu tiên tới đâu thì phụ thuộc vào hiện thực của từng máy ảo Java). Bây giờ, nếu ta đưa A vào danh sách Listener qua một WR chứ không phải là strong reference, ta sẽ không cần bận tâm tới việc gọi removeActionListener khi muốn kết thúc A nữa. Chi tiết cách sử dụng WR và SR, tham khảo JDK documentation và Thinking in Java (ví dụ khá rõ, dù không nói nhiều về ý nghĩa của WR và SR).

Chú ý là với các ứng dụng thông thường, thì hiện tượng này nếu có cũng không làm máy cạn bộ nhớ được, vì vậy cũng không nhất thiết phải dùng đến SR và WR.

1. Giữ lại túi nylon sau khi mua hàng (ở siêu thị, nhà sách, v.v). Lần mua sắm sau hãy đem túi ấy đi để đựng đồ, góp phần (tuy rất rất nhỏ) giảm bớt nhu cầu dùng túi nylon. Việc dùng túi giấy ở Việt Nam còn xa mới phổ biến. Đơn giản nhưng khó nhớ.
2. Ngủ sớm. Đừng mất thời gian suy nghĩ làm việc sáng hay làm việc khuya hiệu quả hơn. Hãy suy nghĩ về việc làm việc sáng hay làm việc khuya dùng nhiều điện hơn.
3. Dùng giấy vệ sinh thật tiết kiệm. Bạn không cần cả mét khăn để lau một vết bẩn nhỏ. Bạn không cần phải lau miệng liên tục trong khi ăn. Dùng khăn vải thay cho giấy vệ sinh khi có thể, chẳng hạn như để lau các vết bẩn dạng khô, và việc giặt khăn thêm một cái khăn vải không đòi hỏi thêm xà bông so với hàng ngày.
4. Hạn chế bật đèn. Nhiều khi ta không cần ánh sáng nhưng cứ bật theo thói quen. Tận dụng ánh sáng mặt trời khi làm việc. Nếu nhà tắm có cửa sổ, đừng tắm quá muộn để có thể tận dụng ánh sáng mặt trời.
5. Hạn chế bật quạt. Cũng là một thói quen tương tự như bật đèn. Nếu không nóng và không có muỗi thì không nên mở quạt. Muốn thoáng? Mở cửa sổ ra. Cũng đừng mở máy lạnh quá to. HM thấy nhiều công ti nhân viên có hành động rất là kì quặc: mở máy lạnh to rồi mặc áo ấm, giữa mùa hè.
6. Tiết kiệm điện khi dùng máy tính. Tắt máy (hoặc hibernate, sleep) khi không dùng trong một thời gian dài, tắt màn hình nếu không dùng trong một thời gian ngắn. Giảm độ sáng màn hình và đừng vặn loa máy tính quá lớn, không những tiết kiệm điện mà còn bảo vệ đôi tai, đôi mắt quý giá của bạn.
7. Nếu hay dùng bút bi, xem xét chuyển sang dùng bút chì bấm nếu có thể. Đằng nào thì học sinh, sinh viên cũng đã có sẵn bút chì rồi. Bút bi thường làm bằng nhựa, và khi dùng xong thì chỉ có vất vào thùng rác, không sử dụng lại được bộ phận nào. Trong khi đó, việc phân loại rác thải ở Việt Nam còn rất hạn chế.

Hành động nhỏ cho một thay đổi lớn.

Tuy nhiên, bao đóng thường bị hiểu sai thành che dấu thông tin một cách vật lý, ngăn cản client truy cập vào phần “bên trong” của supplier. Chính vì vậy mới có quan niệm cứ tạo private field, rồi sau đó tạo thêm các public getter/setter và thế là tính bao đóng vẫn được đảm bảo.

Bertrand Meyer trong Object-oriented software construction đã đưa ra một định nghĩa khác, nhằm tránh sự hiểu lầm trên. Bao đóng nghĩa là tính đúng đắn của các client chỉ có thể chứng minh dựa trên tính đúng đắn của các thuộc tính public của supplier. Nói cách khác, không thể viết được client chỉ có thể vận hành đúng đắn dựa vào các thuộc tính private của supplier.

Ví dụ, xét trường hợp một supplier cung cấp một cơ chế tìm kiếm trong bảng. Client của nó, chẳng hạn như một module trong chương trình bảng tính, sử dụng supplier trên để tìm kiếm các phần tử trong bảng. Bao đóng ở đây có nghĩa rằng, ngay cả khi người xây dựng client biết cụ thể supplier dùng tìm kiếm nhị phân hay bảng băm, họ cũng không thể viết ra một client chỉ chạy đúng với một trong hai phương pháp tìm kiếm, và sai với phương pháp còn lại.

Martin Fowler còn đưa thêm thuật ngữ published để tránh sự nhập nhằng này. Các thuộc tính public là các thuộc tính mà ngôn ngữ lập trình cho phép truy cập từ bên ngoài. Các thuộc tính published là các thuộc tính public mà người phát triển sẽ công bố cho cộng đồng. Chính các thuộc tính published sẽ cho thấy module có thỏa tính bao đóng hay không. Và Eclipse là một ví dụ đáng kể cho chính sách này.

Tóm lại, các cơ chế public, private của các ngôn ngữ lập trình chỉ là công cụ để việc bao đóng được thực hiện một cách gọn gàng và an toàn. Còn việc một module có thỏa mãn tính chất này không còn phụ thuộc vào thiết kế của nó.

Để khẳng định điều này, xin được minh họa một tính năng của Java, cho phép lấy giá trị của một private field của một object bên ngoài.

import java.lang.reflect.Field;

class Foo { 
    private int bar = 100; 
}

public class EncapsulationExample { 
    public static void main(String[] args) throws Exception { 
        Foo foo = new Foo(); 
        Class c = foo.getClass(); 
        Field f = c.getDeclaredField("bar"); 
        f.setAccessible(true); 
        Object o = f.get(foo); 
        System.out.println(o.toString()); // 100 
    } 
}

Vào chủ đề chính. Tình hình là vừa mới kiếm được cách tìm nghịch đảo theo phép đồng dư để chuẩn bị thi mật mã. Mà môn này mình thì cúp, còn hai đồng minh chiến lược thì ngủ, và khả năng là có một số anh em khác vừa ngủ vừa cúp, nên tranh thủ post lại cách giải lên đây.

Cách giải này tìm thấy trong chính quyển sách giáo khoa Cryptography and Network Security Principles and Practices (đừng đọc Wiki). Ta giả vờ nghiên cứu thuật toán đã.

Tìm nghịch đảo của b (tức là b^-1) modulo m. Bắt buộc đưa về 0 < b < m.

EXTENDED EUCLID(m, b)
1. (A1, A2, A3) (1, 0, m); (B1, B2, B3) (0, 1, b)
2. if B3 = 0 return A3 = gcd(m, b); no inverse
3. if B3 = 1 return B3 = gcd(m, b); B2 = b1 mod m
4. Q = thương của A3 / B3.
5. (T1, T2, T3) <- (A1 – QB1, A2 – QB2, A3 – QB3)
6. (A1, A2, A3) <- (B1, B2, B3)
7. (B1, B2, B3) <- (T1, T2, T3)
8. goto 2

Ta luôn có mT1 + bT2 = T3 mA1 + bA2 = A3 mB1 + bB2 = B3.

Tất nhiên sinh viên BK làm gì có thời gian mà đọc cái này. Ta ví dụ luôn với b = 550, m = 1759 như sách giáo khoa, nhưng mình sửa lại cách kẻ bảng chút ít cho nó nhanh hơn :”>.

Hàng đầu là 1, 0, m. Hàng hai là 0, 1, b. Chú ý hàng đầu là m. Và nhắc lại, bắt buộc đưa về 0 < b < m.

Lấy hàng trên cột cuối chi hàng dưới cột cuối, tức là 1759 / 550. Thương là Q.

Lấy Q nhân với hàng dưới (tức là 3 nhân với các số cùng hàng), rồi lấy hàng trên trừ đi kết quả, cột theo cột, được hàng tiếp.

Và lại tính Q = 550 / 109. Làm thế cho đến khi số ở cột cuối là 1.

Và số cạnh số 1 đó (số 355) là nghịch đảo của 550 modulo 1759, hay 355 * 550 = 1 (mod 1759).

Tất nhiên nếu bạn chưa gặp số 1 mà đã gặp 0 rồi thì tức là không có nghịch đảo.

Khi đó số trên số 0 là ước chung lớn nhất (tức là 3), và hai số cùng hàng với 3 là 1 và –1 có tính chất 15 * 1 + 12 * (-1) = 3.

Trường hợp 1759 mà làm tiếp thì cũng sẽ gặp 0, có điều việc làm tiếp là không cần thiết. Dĩ nhiên 1759 * (-111) + 550 * 355 = 1.

Di chuyển trong list

Cái này quá đơn giản. Muốn item trở thành cấp con, dùng Tab. Muốn item trở thành cấp cao hơn, khi item trống, ấn Enter (xem hình), đừng dùng nút Decrease. Muốn đưa một item đã có lên cấp cao hơn, dùng Shift + Tab. Cũng dùng Enter để tắt chế độ list, đừng dùng nút Bullets (xem hình).

Enter liên tục:

Tạo list

Tạo list bằng nút Bullets. Với list có sẵn, tạo item mới bằng cách Enter (xuống dòng) từ item cũ, đừng dùng Bullets. Chỉ dùng nút Bullets khi tạo list mới.

Tất nhiên, tạo list kiểu này sẽ gây ra một số vấn đề rắc rối. Đó là khi sau này bạn muốn sửa lại bullet thành hình khác, hoặc muốn tăng giảm khoảng cách của bullet với chữ, v.v. Điều này hiếm khi cần thiết, tuy nhiên nếu bạn quan tâm, xin đọc tiếp.

Tạo list (kiểu 2)

Để có thể thay đổi định dạng list dễ dàng trong tương lai, chúng ta sẽ tạo một list style. Mặc định Word không có một list style nào hết (hơi dở).

Bước 1:

Bước 2: Mục Name đặt tên cho style mới, sau đó bấm vào nút Format chọn Numbering để đổi bullet.

Bước 3: Nếu không ưng ý với bullet có sẵn, chọn New Bullet.

Nên chọn bullet từ font Symbol:

Sau đó, OK, OK và OK. Bây giờ chọn style mới tạo (My style) và thử thôi:

Vì là LaTeX fanboy nên mình sẽ bắt chước bullet trong LaTeX (tròn, gạch, hoa thị). Có vẻ đẹp hơn mặc định của Word .

Bây giờ giả sử bạn muốn sửa. Ấn chuột phải vào style của bạn và chọn Modify:

Cửa sổ này y hệt ở bước 2 thôi, trừ cái tên.

Sau khi sửa style, tất cả các list sẽ tự động thay đổi theo:

Tạo list kiểu này thật đơn giản và tiện dụng. Cái này không thấy sách ghi, phải đào bới trong mục Help và thử nghiệm rất vất vả mới thành công .

Word tạo ra chữ smallcap bằng cách thu các chữ in hoa nhỏ lại một chút. Ví dụ, chữ “Dựng sẵn” trong style thường là “Dựng sẵn”, khi bạn (theo ý thích) chuyển sang smallcap, Word sẽ lấy chữ viết hoa tương ứng (ví dụ, dạng viết hoa tương ứng của “ự” là “Ự”) thu nhỏ lại, nhưng vì Word không biết chữ “ự” (gồm chữ “ư” và dấu nặng) viết hoa sao, cho nên nó vẫn để “ự” thay vì “Ự”. Với Unicode tổ hợp, Word sẽ viết hoa chữ cái (“ư” thành “Ư”), rồi ghép thêm dấu nặng vào, cho nên smallcap cho tổ hợp chạy tốt.

Nếu bạn thấy rắc rối, thì nên dùng Unicode dựng sẵn và tránh xa các template có kiểu chữ smallcap ra. Hơn nữa, các chương trình gõ tiếng Việt thường mặc định dùng Unicode dựng sẵn, nếu bạn muốn dùng Unicode tổ hợp thì phải lưu ý cả những người cùng soạn thảo.

Trước hết, nếu muốn tạo một văn bản xịn trong Word thì các bạn phải quên mục Font trong tab Home đi đã. Chính xác hơn là đừng có ngứa tay tô đậm, làm nghiêng, gạch chân màu mè hoa lá gì đó. Có hai lí do cho điều này (mà ai đọc về HTML rồi thì cũng hiểu ngay là tại sao). Thứ nhất, định dạng của mình chắc chắn là xấu hơn định dạng có sẵn. Thứ hai, là nếu sau này có hối hận và muốn sửa thì cũng chả sửa được, trừ khi siêng năng soát lại toàn bộ văn bản. Nếu các bạn muốn nhấn mạnh một đoạn văn bản (thường sẽ là in nghiêng), hãy định nghĩa một style “nhấn mạnh” và gán style này cho đoạn văn bản đó. Nếu sau này có đổi ý muốn nhấn mạnh văn bản bằng chứ in đậm thì chỉ cần định nghĩa style là xong. (Nói thêm là Word cũng có sẵn kiểu “nhấn mạnh” rồi, đó là “Emphasis”.)

Vậy, điều đầu tiên là chỉ dùng cái bảng dưới đây để định dạng thôi, và chỉ dùng đến mục Font để định nghĩa style (và tốt hơn hết không nên làm việc này lúc đầu, tập trung vào nội dung đã).

Tuân thủ điều này 100%, và việc đổi cách trình bày văn bản sẽ chỉ cần một hai cú chuột (để chọn style phù hợp). Toàn style làm sẵn, nên rất đẹp:

Điều cần làm thứ hai là vào mục Show/Hide trong tab View và bật Document Map lên. Nó sẽ cho bạn một bảng mục lục tài liệu bên tay trái để nhảy qua nhảy lại trong văn bản rất là tiện lợi. (Nhìn hình ở trên.)

Tiếp theo xuống góc dưới bên phải và chọn Web Layout (biểu tượng quả cầu xanh). Như thế bạn sẽ không phải bận tâm về header, footer, qua trang, lề trái phải, v.v. Như đã nói, tập trung vào nội dung đã. Giờ chỉ còn một băng giấy dài với độ rộng bằng bề ngang cửa sổ thôi. (Cũng có trong hình ở trên.)

Bây giờ chúng ta có thể bắt tay vào soạn thảo được rồi.

Xem hướng dẫn cài đặt và tải xuống ở đây (chỉ nên tải BibWord styles thôi). Trong này có IEEE là style thường thấy trong các paper.

—————-

Phần này dành cho ai chưa từng xài tính năng citation trong Word 2007. Trước hết xem hình đã.

Nếu gõ cái đoạn vừa rồi bằng tay thì vừa xấu vừa mất công, mà mỗi lần trích dẫn phải tra lại, còn xóa hoặc chèn thêm thì chắc là không tưởng (ví dụ sửa [4] thành [3] đồng nghĩa với việc phải lục lại toàn bộ tài liệu).

Thêm nguồn tham khảo

Vào References > Manage Sources (trong cụm Citations & Bibliography). Nó ra cái bảng này:

Muốn thêm thì chọn New. Dễ tới mức không cần hướng dẫn thêm. Có mấy “Type of Source” hay gặp là “Book”, “Web site”, “Report”, “Conference Proceedings”, v.v

Có một chú ý nhỏ là để nhập tên tác giả nên dùng chức năng “Edit” để nhập riêng tên, họ, chữ lót. Chức năng này cũng cần thiết khi phải nhập nhiều tác giả.

Chèn trích dẫn

Với Style IEEE, có một chú ý nhỏ. Nếu trích dẫn cùng lúc nhiều nguồn, thì thay vì để “[1][2]” thì nên để là “[1, 2]” bằng cách chèn “[1]” rồi để con trỏ vào trong “[1]” chèn “[2]”. Nó sẽ tự chuyển thành “[1, 2]”.

Tạo danh sách

curl "http://en.wikipedia.org/wiki/Pipeline_(Unix)" | \
sed 's/[^a-zA-Z ]/ /g' | \
tr 'A-Z ' 'a-z\n' | \
grep '[a-z]' | \
sort -u | \
comm -23 - /usr/share/dict/words

Giải thích ngắn gọn:

• curl lấy nội dung trang web
• sed chuyển kí tự không phải chữ cái và khoảng trắng thành khoảng trắng
• tr chuyển chữ hoa thành chữ thường và khoảng trắng thành dấu xuống dòng
• grep bỏ các dòng trống
• sort xếp từ theo thứ tự và bỏ từ lặp
• comm để lấy ra từ không có trong từ điển

Cái triết lí của Unix “Write programs that do one thing and do it well" cũng từ pipeline mà ra. Chính xác hơn, là từ câu nói của Doug Mcllroy, người phát minh ra pipe trong Unix:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Trong quyển “Pattern-oriented software architecture”, khái niệm này còn có tên có tuổi hẳn hoi: Pipes and Filters pattern, một trong ba architectural pattern (pattern để xây dựng kiến trúc tổng quát cho phần mềm).

Mà kể ra thì pipeline nhìn cũng đẹp thật, gọn gàng, hiệu quả. Cho nên các Linux fanboy (như mình ngày xưa) hay lấy nó làm cái cớ hạ Windows xuống và vênh mặt lên tự hào (nói nữa sợ mất tính khách quan). Tiếc là “Write programs that do one thing and do it well” chỉ còn là quá khứ. Bạn thử nhìn vào hình dưới và đọc những dòng màu xanh nước biển:

Tất nhiên là gần như không thể đọc được. Bởi vì cái ls này đã quá ham hố làm hai thứ: liệt kê thư mục và định dạng dữ liệu xuất (chia cột, tô màu). Mà nó lại không làm tốt việc tô màu.

Không phải mình tự nghĩ ra đâu, mà là Rob Pike và Brian W. Kernighan (đồng tác giả “The C Programming Language”) nói thế trong paper “Program design in the UNIX environment”:

An example of the first approach is Berkeley’s version of the ls command, which lists the filenames in a directory. Let us call it lsc to avoid confusion. The 7th Edition ls command lists filenames in a single column, so for a large directory, the list of filenames disappears off the top of the screen at great speed. lsc prints in columns across the screen (which is assumed to be 80 columns wide), so there are typically four to eight times as many names on each line, and thus the output usually fits on one screen. The option -1 can be used to get the old single-column behavior.

…The automatic columnation in lsc is reminiscent of the ‘‘wild cards’’ found in some systems that provide filename pattern matching only for a particular program. The experience with centralized processing of wild cards in the UNIX shell shows overwhelmingly how important it is to centralize the function where it can be used by all programs.

One solution for the ls problem is obvious — a separate program for columnation, so that columnation into say 5 columns is just ls | 5…

Thế nên đừng tường cứ có pipe được là thành “do one thing and do it well”.

Chuyện này có từ thời BSD, nhưng thôi cứ chửi GNU cho tiện (vì bây giờ GNU rất phổ biến trên Linux). Vậy là từ cái đống lệnh pipe phức tạp nhưng dễ quản lí (vì mỗi người một việc) bây giờ chúng ta có một đống lệnh pipe phức tạp và khó quản lí (nhiều người cũng làm được một việc, chọn ai bây giờ). Tốt nhất là cứ theo kiểu Windows, thân ai người đấy lo, thiếu chức năng thì viết lệnh mới.

Dùng câu này trong “Pattern-oriented software architecture” để kết là hợp nhất:

The Pipes and Filters pattern, in contrast, is less often used, but is attractive in areas where data streams can be processed incrementally. Surprisingly, some system families modelled in this fashion turn out to be poor candidates for this paradigm, neglecting areas where this pattern could be used more beneficially.

Không quan tâm tới chuyện checked exception trong Java hay dở thế nào nữa, tại vì chúng ta không phải là Sun. Họ làm sao là quyền của họ. Việc của chúng ta là làm theo ý họ theo cách tốt nhất có thể.

Sun có một bài dài về checked exception, và họ kết luận:

Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don’t want to be bothered with specifying the exceptions your methods can throw.

Here’s the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

Tức là với Sun, lập trình viên phải ưu tiên xem xét checked exception trước. Trong quyển Effective Java: Programming Language Guide, Josh Bloch (một trong những người tham gia thiết kế Java) cụ thể hóa các chỉ dẫn trên một chút:

• Item 39: Use exceptions only for exceptional conditions. That is, do not use exceptions for control flow, such as catching NoSuchElementException  when calling Iterator.next() instead of first checking Iterator.hasNext().
• Item 40: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors. Here, Bloch echoes the conventional Sun wisdom — that runtime exceptions should be used only to indicate programming errors, such as precondition violations.
• Item 41: Avoid unnecessary use of checked exceptions. In other words, don’t use checked exceptions for conditions from which the caller could not possibly recover, or for which the only foreseeable response would be for the program to exit.
• Item 43: Throw exceptions appropriate to the abstraction. In other words, exceptions thrown by a method should be defined at an abstraction level consistent with what the method does, not necessarily with the low-level details of how it is implemented. For example, a method that loads resources from files, databases, or JNDI should throw some sort of ResourceNotFound exception when it cannot find a resource (generally using exception chaining to preserve the underlying cause), rather than the lower-level IOException, SQLException, or NamingException.

Tuy nhiên, như đã nói, các ông trùm đều cho rằng checked exception theo kiểu Java phá vỡ tính bao đóng, làm code dài, khó bảo trì, v.v cho nên một hướng dẫn chung chung thế kia có lẽ là chưa đủ. Có hai lựa chọn có vẻ đáng chú ý.

Thứ nhất là quan điểm “cực đoan” của Bruce Eckel (người viết mấy quyển Thinking in), chỉ nên có checked exception. Bruce Eckel đề xuất việc mở rộng RuntimeException thành ExceptionAdapter có tác dụng:

Here, you’re still able to catch the specific type of exception but you’re not forced to put in all the exception specifications and try-catch clauses everywhere between the origin of the exception and the place that it’s caught. An even more importantly, no one writing code is tempted to swallow the exception and thus erase it. If you forget to catch some exception, it will show up at the top level. If you want to catch exceptions somewhere in between, you can.

Thứ hai là quan điểm “ôn hòa” của Rod Johnson trong J2EE Design and Development. Giống như Anders Hejlsberg, ông này cũng cho là checked exception là cần thiết, vấn đề là dùng sao cho hợp lí (trong điều kiện vẫn chưa tìm ra giải pháp nào phù hợp về mặt ngôn ngữ):

Checked exceptions are much superior to error return codes (as used in many older languages). Sooner or later (probably sooner) someone will fail to check an error return value; it’s good to use the compiler to enforce correct error handling. Such checked exceptions are as integral to an object’s API as parameters and return values.

However, I don’t recommend using checked exceptions unless callers are likely to be able to handle them. In particular, checked exceptions shouldn’t be used to indicate that something went horribly wrong, which the caller can’t be expected to handle.

Rod Johnson còn đề xuất cả một hướng dẫn cụ thể:

Question	Example	Recommendation if the answer is yes
Should all callers handle this problem? Is the exception essentially a second return value for the method?	Spending limit exceeded in a processInvoice() method	Define and used a checked exception and take advantage of Java’s compile-time support.
Will only a minority of callers want to handle this problem?	JDO exceptions	Extend RuntimeException. This leaves callers the choice of catching the exception, but doesn’t force all callers to catch it.
Did something go horribly wrong? Is the problem unrecoverable?	A business method fails because it can’t connect to the application database	Extend RuntimeException. We know that callers can’t do anything useful besides inform the user of the error.
Still not clear?		Extend RuntimeException. Document the exceptions that may be thrown and let callers decide which, if any, they wish to catch.

Decide at a package level how each package will use checked or unchecked exceptions. Document the decision to use unchecked exceptions, as many developers will not expect it.

The only danger in using unchecked exceptions is that the exceptions may be inadequately documented. When using unchecked exceptions, be sure to document all exceptions that may be thrown from each method, allowing calling code to choose to catch even exceptions that you expect will be fatal. Ideally, the compiler should enforce Javdoc-ing of all exceptions, checked and unchecked.

If allocating resources such as JDBC connections that must be released under all circumstances, remember to use a finally block to ensure cleanup, whether or not you need to catch checked exceptions. Remember that a finally block can be used even without a catch block.

Quyển J2EE Design and Development còn trình bày rất nhiều về exception và các vấn đề đáng quan tâm khác trong Java.

Nhưng theo Anders Hejlsberg (kiến trúc sư trưởng của C#), thì cái cách Java hiện thực checked exception có vẻ không tốt. Tức là, checked exception vẫn là một ý tưởng hữu ích:

Frankly, they look really great up front, and there’s nothing wrong with the idea. I completely agree that checked exceptions are a wonderful feature. It’s just that particular implementations can be problematic. By implementing checked exceptions the way it’s done in Java, for example, I think you just take one set of problems and trade them for another set of problems. In the end it’s not clear to me that you actually make life any easier. You just make it different.

Nhưng giải pháp Java đưa ra thì có vấn đề:

The concern I have about checked exceptions is the handcuffs they put on programmers. You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren’t helping them any. It is sort of these dictatorial API designers telling you how to do your exception handling. They should not be doing that.

Alan Griffiths cũng đồng ý rằng giải pháp của Java gây ra một số vấn đề, trong đó có việc phá vỡ tính bao đóng (mà cũng không biết ông này là ông nào, có điều thấy bài viết cũng được). Nhưng ngắn gọn lại thì cũng như quan điểm của Hejlsberg—lập trình viên sớm muộn sẽ catch và throw một loạt exception Exception:

The throws clause, at least the way it’s implemented in Java, doesn’t necessarily force you to handle the exceptions, but if you don’t handle them, it forces you to acknowledge precisely which exceptions might pass through. It requires you to either catch declared exceptions or put them in your own throws clause. To work around this requirement, people do ridiculous things. For example, they decorate every method with, "throws Exception." That just completely defeats the feature, and you just made the programmer write more gobbledy gunk. That doesn’t help anybody.

Cái này mình cũng đồng ý, vì mình cũng hay làm thế cho nhanh. Vấn đề là Exception thì bao gồm cả RuntimeException, là những exception mà chúng ta không nên tự xử lí. Mình thấy tốt hơn hết là để cho lập trình viên catch những exception họ muốn/cần catch, và phần còn lại sẽ được throw tự động.

Có một lời giải thích khá thú vị cho giải pháp C# đưa ra—không hỗ trợ exception, hay chính xác hơn là không đưa ra giải pháp thực sự nào. Đó là vì họ chưa nghĩ ra.

C# is basically silent on the checked exceptions issue. Once a better solution is known—and trust me we continue to think about it—we can go back and actually put something in place. I’m a strong believer that if you don’t have anything right to say, or anything that moves the art forward, then you’d better just be completely silent and neutral, as opposed to trying to lay out a framework.

And so, when you take all of these issues, to me it just seems more thinking is needed before we put some kind of checked exceptions mechanism in place for C#. But that said, there’s certainly tremendous value in knowing what exceptions can get thrown, and having some sort of tool that checks. I don’t think we can construct hard and fast rules down to, it is either a compiler error or not. But I think we can certainly do a lot with analysis tools that detect suspicious code, including uncaught exceptions, and points out those potential holes to you.

Cũng là một lời khuyên hay. Nếu không thể làm cho tình huống tốt hơn thì hãy để nó nguyên như thế, ít nhất nó cũng sẽ không tệ đi.

Vẫn còn bảy bài phỏng vấn với ông trùm ngôn ngữ lập trình này, phải ráng đọc cho hết.

Quay lại nhà vệ sinh đã. Không muốn đưa chủ đề này lên blog, nhưng tại vì bức xúc quá thể. Đây là những gì thu nhặt được sau hơn một tuần buộc phải lê lết ở trường vì đói Internet:

• Số nhà vệ sinh nữ ít hơn rất nhiều so với số nhà vệ sinh nam. Nếu bạn định rủ bạn gái tới BK, tốt hơn hết là nên lập trước bản đồ, để lúc đấy đỡ phải lên Google map. Và nếu có thể thì vào thử luôn , vì chuyện thứ ba.
• Các nhà vệ sinh đều không có hệ thống xả nước tự động, ngoại trừ các thực thể sinh học thông minh có khả năng tự di chuyển và cọ rửa khoảng 12 hoặc 24 giờ một lần. Tuy nhiên rất nhiều sinh viên nam (vì nữ HM không thể biết được) mặc định rằng hệ thống ấy tồn tại.
• Hệ quả của chuyện trên là khi vào nhà vệ sinh HM phải chuyển sang chế độ “tiết kiệm năng lượng”, cắt giảm các hoạt động không cần thiết trong cơ thể, để giảm bớt nhu cầu hô hấp tới mức tối đa.
• Nếu bạn có từng vào nhà vệ sinh ở BK, có lẽ bạn sẽ nhận ra sự đan xen hài hòa giữa nhiều trường phái kiến trúc Đông Tây, mà điển hình là ở B1 và B9. Nhà vệ sinh ở B1 lấy ý tưởng đề cao sự giao lưu cộng đồng kiểu châu Âu (chắc thế, vì người ta hay nói ở tây hay tham gia hoạt động xã hội), cho nên cánh cửa được thiết kế sao cho chỉ cần hé mở một chút, thì sẽ không còn có sự ngăn cách nào giữa người đi vệ sinh và người đi bộ ngoài hành lang. Trái lại, nhà vệ sinh B9 lại được xây dựng đậm chất châu Á. Cụ thể hơn, là kiểu Pol Pot, không có gì là của cá nhân, tất cả đều thuộc về tập thể. Khó tả quá. Đại để là, chung một dòng sông.

Thế nên phải vào nhà vệ sinh ở BK là cả một sự khổ nhục. Chỉ đến sáng nay, khi phải qua cơ sở 2 đại học sư phạm có chút chuyện HM mới nhận ra, có một cái nhà vệ sinh gắn vòi rửa tay như BK quả là một mơ ước đáng để ước mơ của sinh viên ở cơ sở này. Đúng là cuộc sống không phải lúc nào cũng như ý mình nên hãy biết hạnh phúc với những thứ đang có.

Nếu lúc nào bạn có chuyện gì buồn bã, tuyệt vọng thì hãy vào nhà vệ sinh ở BK, sau đó làm lại điều đó ở cơ sở 2 đại học sư phạm, nhất định bạn sẽ thấy nhẹ nhõm phần nào.

Thường thì chúng ta get một field để lấy thông tin của đối tượng, và thao tác trên thông tin đó. Vấn đề là tại sao phải trực tiếp làm việc trên thông tin này. Xét cho cùng, đối tượng là một thực thể mà tất cả những gì bên ngoài (nên) được biết về nó là các “dịch vụ” mà nó cung cấp. Cho nên, thay vì lấy thông tin từ đối tượng để thực hiện một công việc, hãy bảo đối tượng này làm nó cho chúng ta. Nếu điều này là không thể, thì có vẻ như thiết kế của chương trình có vấn đề, các đối tượng đã không được xây dựng để làm các công việc của nó một cách tách bạch, rõ ràng. Và khi sự coupling giữa các đối tượng càng cao, việc bảo trì và mở rộng trong tương lai sẽ càng khó khăn, phức tạp.

Mặt khác, khi get hay set một field nào đó, thường chúng ta đã có giả định về kiểu và ý nghĩa của nó. Nói cách khác, chúng ta đã có hiểu biết nhất định về hiện thực bên trong của đối tượng. Có điều, hiện thực của một đối tượng không phải là một bất biến. Khó có thể đảm bảo trong tương lai, khi đối tượng được xây dựng lại, các private field đó sẽ giữ nguyên kiểu và ý nghĩa như hôm nay, thậm chí nó có thể không tồn tại nữa. Hệ quả là, những đoạn mã có sử dụng get/set cũng trở nên vô dụng. Điều đó đồng nghĩa với việc không đạt được tính dễ bảo trì và mở rộng—mục tiêu mà lập trình hướng đối tượng hướng tới.

Tất nhiên, nói như thế không có nghĩa là chúng ta phải tránh xa get/set. Get/set sẽ tồn tại nếu chúng thực sự là những “dịch vụ” cần thiết, và không phụ thuộc và thay đổi của bất kì cách hiện thực nào của đối tượng. Nhưng lúc đó thì get/set lại không hẳn liên quan đến cái get/set người ta hay dạy cho học sinh nữa.

/* ====== x.h ====== */ 
#include “y.h” 
class X 
{ 
  Y *m_y; 
  ... 
};

/* ====== y.h ====== */ 
#include “x.h” 
class X; 
class Y 
{ 
  X *m_x; 
  ... 
};

Dễ thấy muốn có x.h phải có y.h, mà muốn có y.h thì lại cần đến x.h. Trừ khi có khả năng xử lý cyclic dependency (như kiểu của Java), trình biên dịch sẽ báo lỗi.

Cách xử lí:

/* ====== x.h ====== */ 
// Forward declaration of Y for cyclic dependency 
class Y; 
class X 
{ 
  Y *m_y; 
  ... 
};

/* ====== y.h ====== */ 
// Forward declaration of X for cyclic dependency 
class X; 
class Y 
{ 
  X *m_x; 
  ... 
};

Đây gọi là forward declaration. Nó giúp giải quyết được cyclic dependency kiểu trên, tuy nhiên, có những dạng cyclic dependency không thể xử lí bằng forward declaration được.

Bạn có thể đọc thêm một số nguyên tắc khác ở đây.

• Máy tính hỏng. Nếu là hệ điều hành, màn hình, v.v hỏng thì không sao, còn ổ cứng mà hỏng thì xem như xong.
• Không lưu trước khi chỉnh sửa. Và chuyện “sửa đồ lành thành đồ què” không phải là hiếm.
• Làm nhóm. Tất nhiên là có cả tá lí do để việc làm nhóm không được như ý, nhưng nói chung đã cũng làm một bài mà mỗi phần lại ở một máy khác nhau thì cũng bất tiện.
• v.v

Tóm lại là cần phải có một chỗ lưu trữ nhanh gọn, an toàn. Dĩ nhiên với các rắc rối ở trên thì lưu trữ trực tuyến là hợp lí nhất, tuy nhiên nếu chỉ sử dụng các dịch vụ như iFile, MediaFire thì sẽ có những hạn chế nhất định, như phải tải xuống/lên một lượng lớn dữ liệu một cách thủ công, khó khăn khi quản lí các bản sao lưu, v.v. Vì vậy, chúng ta sẽ dùng một công cụ gọi là SVN. Cụ thể SVN là gì thì bạn có thể tự tìm hiểu. Ở đây sẽ chỉ cách dùng trang Sourceforge và TortoiseSVN để quản lí bài tập của bạn. Ngoài Sourceforge còn có nhiều trang cung cấp dịch vụ tương tự, như Google Code. Nếu bạn không muốn công khai mã nguồn thì có thể thử Unfuddle.

Việc đầu tiên là bạn phải đăng kí tài khoản ở Sourceforge. Sau đó tạo một project mới (vào link Create project). Khi đã tạo xong thì vào trang của project đó (từ mục/portlet My projects). Tại trang của project vào link Develop (link trong trang của project chứ không phải link cùng tên dưới logo Sourceforge). Và bạn sẽ có được một URL kiểu như thế này: https://nmh-blog.svn.sourceforge.net/svnroot/nmh-blog.

Tiếp theo là cài TortoiseSVN.

Bây giờ tạo một thư mục để lưu project trên máy. Vào trong thư mục này, ấn chuột phải chọn SVN Checkout. Nhập vào URL lúc nãy. OK, và thế là xong. Giờ cái thư mục sẽ trông như thế này:

Sau khi làm xong một phần của bài tập, nếu bạn muốn tải lên mạng thì ấn chuột phải vào thư mục này và chọn SVN Commit. Chọn các tập tin cần đưa lên:

Và sau một vài thao tác lặt vặt:

Ngược lại nếu muốn tải xuống thay vì tải lên bạn chọn SVN Update thay vì SVN Commit. SVN đủ thông minh để chỉ tải xuống hoặc tải lên các phần dữ liệu bị thay đổi, nên thường bạn chỉ tốn thời gian trong lần đầu.

Nếu bạn lỡ dại làm gì đó bài tập của mình và muốn quay về phiên bản cũ, ấn chuột phải chọn TortoiseSVN > Show log để xem toàn bộ các thay đổi của mình:

Và sau đó, chọn thời điểm bạn muốn quay lại, ấn chuột phải và …

Mà có lẽ bạn tự tìm hiểu sẽ thú vị hơn .

Chép lại đây kẻo mất mất.

Elements of an application letter for an internship for a BCCB student

Here is a letter that I made up as an example. Comments to each individual part are in the right hand-side column.

Text of letter	Comments
Dear Dr. Miller,	For the US, use Dr., not Prof., to address someone.
I am a second-year student of Biochemistry and Cell Biology at the International University Bremen, Germany.	Introduce yourself first.
In order to gain practical experience in a research environment and to explore graduate school options, I wish to perform a 10-week internship in a research laboratory, and I would like to  ask whether there might be a place available in your laboratory from June to August, 200x.	Tell the addressee what you want from them, and why.
During my studies at IUB, I have become interested in studying the molecular mechanisms of the immune response. I find it especially interesting how one might manipulate the system in order to induce specific immunity against viruses or other pathogens. The molecular basis of this is antigen presentation through MHC class I molecules, and I would like participate in research on them because it combines techniques across the whole spectrum of the life sciences, from molecular dynamics to cell biology.	The next question the addressee will ask is "Is he or she really motivated to work with me, i.e. applying specifically to my lab or am I just one of many people who get a nonspecific letter?" So first, you need to demonstrate that you have a connection to the subject. Of course, this section very much depends on your interest and the lab you are applying to. The text on the left is just an example.
I came across your laboratory when reading the literature on MHC class I molecules, and especially the work in your group described in the Journal of Immunology, 2004 ("The role of class I molecules in ankylosing spondylitis") and in Nature, 2005 ("Class I haplotype determines clinical outcome of ankylosing spondylitis") has motivated me to write to you.	Next, you should demonstrate that you know some of the work from the lab, ideally by mentioning the titles of a couple of interesting papers (make sure you have actually seen them). Of course, this section very much depends on your interest and the lab you are applying to. The text on the left is just an example.
I would be very excited to participate in work on a similar subject.	Do not suggest an actual research project – as an intern you have no control over that.
Regarding my training, I am convinced that the intense teaching approach at IUB has equipped me with solid fundamental knowledge of biochemistry and cell biology. Since IUB puts its students on the track to a career in research, this is complemented by laboratory courses from the first semester on. In addition, I have worked as a research assistant in Prof. xxx’s lab for xxx months to gain some additional experience.	The next question the addressee will ask is "Is that person qualified to work in my lab or will they just break everything?" So you must convince them that you are well-trained. Of course, only write what actually applies to you.
If I am given the chance to work in your group, I am certain that due to my previous training and my enthusiasm for the subject I will be able to make a meaningful contribution to your research effort.	This part is important. What is your host going to get from your time with them?
I have attached my CV, which contains the details of my theoretical and practical training, my current university transcript, and the names and addresses of three referees. If you wish, I can ask them to send their letters directly to you.	Normally, for an internship, the prospective host should contact the referees and ask for the letters. (This also helps minimize the impact on IUB faculty who have to write many letters for grad school already.)
I am looking forward to hearing from you. Sincerely, …….

© Sebastian Springer 2005. Please contact me with suggestions for improvements.

Thứ nhất, Scheme có tương đối ít khái niệm hơn các ngôn ngữ phổ biến, như C#, C++, Java, v.v. Điều này giúp bạn tập trung vào những yếu tố quan trọng khác trong lập trình, thay vì tiêu tốn thời gian và công sức vào những chi tiết cú pháp vụn vặt.

Thứ hai, chương trình dùng Scheme viết ra nhìn rất ngắn gọn và đẹp (nói chung các ngôn ngữ lập trình hàm đều thế). Ví dụ:

(define (even-fibs n) 
(accumulate +  
            0  
            (filter even?   
                    (map fib    
                         (enumerate-interval 0 n)))))

Đoạn mã trên là một phần của chương trình tính tổng các số chẵn trong (n+1) số Fibonacci đầu tiên. Bạn có thể thấy từng bước tính toán nếu đọc ngược từ dưới lên:

• Liệt kê (enumerate) các số từ 0 đến n,
• Ánh xạ (map) dãy trên sang dãy Fibonacci. Nôm na là tạo danh sách các số Fibonacci từ thứ 0 đến thứ n,
• Lọc (filter) các số chẵn trong danh sách,
• Tính tổng (accumulate) các số vừa được lọc.

Thứ ba, ngay cả một chương trình Scheme cỡ trung bình cũng khá khó viết. Nếu chưa có một phác thảo tương đối rõ ràng về chương trình của mình, thì thậm chí cái bạn viết ra có thể không chạy được chứ chưa nói đến chạy đúng hay sai, nhất là khi dùng IDE của MIT. Có lẽ chính sự quá dễ dàng trong việc viết ra một chương trình “chạy được” bằng các ngôn ngữ như C, C++ (cái này BK chọn để dạy trong môn Kĩ thuật lập trình), Java, C# khiến cho chúng ta nhiễm thói quen “mì ăn liền”, đọc yêu cầu xong là nhảy vào lập trình liền, và kết quả là chương trình rất rối rắm và dễ mắc lỗi.

Nếu quan tâm tới Scheme, bạn có thể tham khảo thêm ở trang web của môn này ở MIT OCW. Quyển sách giáo khoa chính—Structure and Interpretation of Computer Programs—là một trong những quyển sách về máy tính hay nhất mà mình từng đọc. Bạn có thể tìm thấy ở đó không chỉ những hướng dẫn về lập trình Scheme mà còn rất nhiều lí thuyết thú vị, như thiết kế chương trình, tính trừu tượng, tính nondeterministic, v.v. Đọc nó, và bạn sẽ không bao giờ còn băn khoăn liệu mình có chọn sai ngành.