Tại sao nên hạn chế sử dụng Singleton, static function(util class, Helper class)?

Đây thực sự là một câu hỏi không dễ để trả lời… Một cách thông thường, trong suy nghĩ của hầu hết lập trình viên sẽ là: chỗ nào giống nhau, gọi lại nhiều lần thì nên gom thành common class, static cho dễ gọi.

Ok, mọi thứ đều ổn, nhưng nếu ko để ý & quá tay một chút thì nó đã vi phạm nghiêm trọng đến design ứng dụng – nó phá vỡ ranh giới của các element,module hoặc class

Tại sao lại như vậy? Bản chất Lập trình OOP là mô phỏng thực tế cuộc sống vào chương trình bằng ngôn ngữ lập trình. Thay vì dùng văn tả cảnh, thì lập trình viên tả lại cuộc sống bằng ngôn ngữ lập trình trên một framework nào đấy. Ở ngoài cuộc sống có gì, thì chương trình cũng có cái đó, chúng ta có Sinh viên, có Tài khoản ngân hàng, có Ô tô…etc.

Nhưng nếu bạn để ý, trong cuộc sống Util class, Helper class, Common class… ko tồn tại. Ai đó tạo lên cuộc sống hẳn phải là một lập trình viên cực kỳ vĩ đại.

Phân ranh giới. (Boundaries)

Software architect là một nghệ thuật để tạo ra các ranh giới, nhằm phân tách các element, class, module..etc

Cùng xem xét ví dụ sau:

DisplayHelper – static function

ZxingDecoder cần lấy ra orientation device, hàm lấy orientation dùng ở rất nhiều nơi nên tạo sẵn một class DisplayHelper để dùng. Hàm get orientation cần context nên parameter của ZxingDecoder là context

Display – interface

Mình tạo ra 1 interface là Display để có thể get orientation của device, parameter đầu vào của ZxingDecoder là display.

Điểm khác biệt lớn nhất là ở cách viết 2 – ZxingDecoder đã tách khỏi(1 phần tách khỏi) framework android – khi nó xóa đi sự hiện diện của context, tức là mình đang cố gắng phân rõ ranh giới của ZxingDecoder khỏi android framework Nói một cách khác mình đang cố gắng decouple ZxingDecoder khỏi android framework

ZxingDecoder là 1 bộ decode barcode – nó ko phụ thuộc vào framwork, việc decode này mang ý nghĩa – class mình viết có thể chạy được ở bất cứ đâu, không chỉ là trên android framework

Ngoài ra, nếu sử dụng DisplayHelper – khi có càng nhiều nơi, càng nhiều class, layer, module gọi hàm get orientation, hoặc một function của DisplayHelper thì các bạn có thể tượng tượng rằng DisplayHelper như một sợi xích đâm xuyên tất cả các layer, module, class, và buộc chặt các thành phần này lại với nhau và hoàn toàn không thể tách rời. Nói cách khác, khi đó ko thể tạo ra các ranh giới Boundaries cho bất cứ thành phần nào dùng chung DisplayHelper. Tất cả đều phẳng, và dính chặt vào android framework thông qua context của DisplayHelper

Dễ code(Create) – khác với việc dễ maintain(Update).

Phân ranh giới. (Boundaries) – là target cho hầu hết các task refactor bạn phải làm

Làm thế nào để phân ranh giới? à, cái ý mình ko dám nói 😀 (ở bài viết này)