<html><body><h2>1. Factory Design Pattern Là Gì</h2>Trước khi đi đến concept của Factory Design Pattern thì anh em mình cùng nhau xem qua một ví dụ thực tiễn này nhé. Fintech ra đời là một cánh tay đắc lực cho việc phát triển các hệ thống về Finance, Insurance và Banking. Mình cũng đã có một vài năm kinh nghiệm làm về Banking, nên mình sẽ lấy một service của Banking làm ví dụ.Hầu hết các ngân hàng sẽ hỗ trợ bốn loại tài khoản như sau:<ul><li>Checking Account</li><li>Savings Account</li><li>Money Market Account</li><li>Certificate of Deposit</li></ul>Bài toán đặt ra là tìm một solution thích hợp để tạo ra các loại Banking Account này. Factory design pattern sẽ là một ứng cử viên sáng giá. Vì nhiệm vụ của design pattern này là quản lý việc tạo ra đối tượng theo yêu cầu.<h2>2. Factory Design Pattern Diagram</h2><figure class="image image_resized" style="width:82.92%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Untitled-CALXd1GZrELYXeQ9CvTahYBhgBxMJlFnX2HTi9dF.webp"></figure>Giờ mình cùng nhau tìm hiểu các cách để implement Factory design pattern. Từ class diagram anh em coder có thể dễ dàng nhận thấy được cách implement cho Factory cực kỳ giản đơn.AccountFactory nhận vào input là AccountType và trả về output là một particular BankAcount.<h2>3. Factory Design Pattern Implementation</h2>Dựa vào diagram trên anh em mình cùng nhau đi qua cách implementation của design pattern này.Đầu tiên mình tạo ra một BankAccount đây là abstract class sẽ chứa thông tin được dùng chung cho các Account cụ thể.public abstract class BankAccount{     protected String bankName;    protected String accountNumber;    protected BigDecimal balance;     protected abstract String withDraw();    protected abstract String deposit();} CheckingAccount là một class mở rộng của BankAccount. Class này chiệu trách nhiệm triển khai các business logic cụ thể cho tài khoản Checking.public class CheckingAccount extends BankAccount{     @Override    protected String withDraw(){        return "Checking account withdraws";    }    @Override    protected String deposit(){        return "Checking account deposits";    }}SavingAccount là một class mở rộng của BankAccount. Class này chiệu trách nhiệm triển khai các business logic cụ thể cho tài khoản Saving.public class SavingsAccount extends BankAccount{     @Override    protected String withDraw(){        return "Saving account withdraws";    }    @Override    protected String deposit(){        return "Saving account deposits";    }}MoneyMarketAccount là một class mở rộng của BankAccount. Class này chiệu trách nhiệm triển khai các business logic cụ thể cho tài khoản MoneyMarket.public class MoneyMarketAccount extends BankAccount{     @Override    protected String withDraw(){        return "MoneyMarket account withdraws";    }    @Override    protected String deposit(){        return "MoneyMarket account deposits";    }}CertificateDepositAccount là một class mở rộng của BankAccount. Class này chiệu trách nhiệm triển khai các business logic cụ thể cho tài khoản CertificateDeposit.public class CertificateDepositAccount extends BankAccount{    @Override    protected String withDraw(){        return "CertificateDeposit account withdraws";   } @Override    protected String deposit(){        return "CertificateDeposit account deposits";    }}AccountType là những giá trị cố định và đã được định nghĩa trước trong domain của ngành ngân hàng vì vậy nó là một hằng số nên mình dùng Enum cho kiểu dữ liệu này để đảm bảo tính toàn vẹn.public enum AccountType{    CHECKING,    SAVINGS,    MONEY,    CERTIFICATE}AccountFactory là class triển khai Factory design pattern. Dựa vào accountType để tạo ra từng loại BankAccount tương ứng.public class AccountFactory{    public BankAccount createAccount(AccountType accountType){        switch(accountType) {            case CHECKING:                return new CheckingAccount();            case SAVINGS:                return new SavingsAccount();            case MONEY:                return new MoneyMarketAccount();            case CERTIFICATE:                return new CertificateDepositAccount();            default:                throw new IllegalArgumentException(“Error”));        }    }}Dưới đây là cách sử dụng AccountFactory để tạo ra CheckingAccount.public class Execution{     public static void main(String[] args){        AccountFactory accountFactory = new AccountFactory();        BankAccount account = accountFactory.createAccount(AccountType.CHECKING);        account.withDraw();        account.deposit();    }}<h2>4. The Pros and Cons of Factory Design Pattern</h2><h3>The Pros of Factory</h3>Với Factory điểm mạnh đầu tiên mình có thể nhìn thấy đó là pattern này centralized việc tạo ra các objects vào một nơi. Điều này giúp cho developers có thể dễ dàng đọc code và maintain.Thứ hai, pattern này hạn chế sự phụ thuộc giữa các class với nhau. Điều này giúp chúng ta có thể dễ dàng mở rộng (scale). Lấy ví dụ sau này sẽ có thêm nhiều loại account mới như Credit, Debit…Khi đó chúng ta chỉ cần tạo thêm các sub-class extends BankAccount và thêm vào factory method.Thứ ba, có thể ẩn đi các logic phức tạp khi tạo ra các object.<h3>The Cons of Factory</h3>Như các bạn thấy việc tạo ra các object trong method create(AccountType type) phụ thuộc vào constructor của các sub-class. Do đó, nếu construct có nhiều tham số thì factory method sẽ trở nên phức tạp.Số lượng sub-class có thể ngày càng nhiều. Với mình đây thật sự không phải là một nhượt điểm của factory. Tuy nhiên, điều này sẽ dẫn tới việc method create(AccoutType type) sẽ ngày càng phình to ra.<h2>5. The Conclusion</h2>Mình xin phép kết thúc bài viết tại đây. Qua bài viết mình cũng đã list ra thế nào là Factory Design Pattern. Cách cách để implement một Factory… Hy vọng nhận được nhiều đóng góp của mọi người để cộng đồng lập trình ngày càng phát triển và đặc biệt để những bài viết sau được tốt hơn.Các bài viết trong cùng chủ đề về Design Pattern<ul><li><a href="https://careers.saigontechnology.com/blog-detail/design-pattern-bai-01-solid-trong-thiet-ke-huong-doi-tuong-2">[Design Pattern] Bài 01: SOLID Trong Thiết Kế Hướng Đối Tượng | Careers Saigon Technology</a></li><li><a href="https://careers.saigontechnology.com/blog-detail/design-pattern-bai-03-su-dung-singleton-trong-java">[Design Pattern] Bài 03: Sử Dụng Singleton Trong Java | Careers Saigon Technology</a></li></ul></body></html>

Bài viết nằm trong chuỗi bài về design pattern. Là phần tiếp theo của series design pattern, Factory một design pattern cực kỳ hữu dụng trong việc tạo ra object. Vậy Factory là gì, làm sao để implement một Factory. Qua bài viết hy vọng có thể support được mọi người có thêm kiến thức về Factory.

&lt;html&gt;&lt;body&gt;&lt;h2&gt;1. Design Patterns l&agrave; g&igrave; nhỉ?&nbsp;&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tổng quan th&igrave; Design Patterns như một c&ocirc;ng thức để ta c&oacute; thể &aacute;p dụng v&agrave;o giải quyết một số vấn đề cụ thể trong lập tr&igrave;nh, cụ thể l&agrave; Lập tr&igrave;nh hướng đối tượng (OOP). N&oacute; l&agrave; những giải ph&aacute;p đ&atilde; được đ&uacute;c kết v&agrave; tối ưu h&oacute;a cho c&aacute;c trường hợp cụ thể. Thay v&igrave; phải t&igrave;m c&aacute;ch tối ưu h&oacute;a, tổ chức code lại từ đầu, th&igrave; bạn đơn giản c&oacute; thể &aacute;p dụng c&aacute;c Design Patterns ph&ugrave; hợp v&agrave; đ&atilde; được tối ưu cho trường hợp bạn gặp phải. Từ định nghĩa đ&oacute; ta c&oacute; thể thấy được một số t&igrave;nh huống m&agrave; Design Patterns c&oacute; thể ph&aacute;t huy sức mạnh tối đa của n&oacute;:&lt;/p&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Bạn gặp một t&igrave;nh huống phức tạp khi lập tr&igrave;nh. Đừng lo, khả năng cao đ&atilde; c&oacute; một (hoặc c&oacute; thể l&agrave; một v&agrave;i) Design Patterns c&oacute; thể giải quyết vấn đề của bạn thật đơn giản v&agrave; gọn g&agrave;ng. Chỉ cần &aacute;p dụng theo l&agrave; xong.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Bạn trao đổi với c&aacute;c developer kh&aacute;c trong team về c&aacute;ch tổ chức source code của một hệ thống kh&aacute; lớn v&agrave; phức tạp. Bạn (v&agrave; team của bạn) cảm thấy kh&oacute; khăn khi tr&igrave;nh b&agrave;y &yacute; tưởng của m&igrave;nh. H&atilde;y sử dụng Design Patterns như một ng&ocirc;n ngữ chung để n&oacute;i về những &yacute; tưởng phức tạp một c&aacute;ch đơn giản. (Giả sử thay v&igrave; n&oacute;i rằng &ldquo;Ta c&oacute; thể tạo một Abstract Class để tập trung c&aacute;c xử l&yacute; tạo c&aacute;c Instance của class Hotel để dễ d&agrave;ng che giấu việc khai b&aacute;o c&aacute;c Instance con li&ecirc;n quan đến Hotel đồng thời c&oacute; thể dễ d&agrave;ng tạo nhiều Instance của Hotel mootj c&aacute;ch dễ d&agrave;ng v&agrave; tường minh&rdquo; th&igrave; ta c&oacute; thể n&oacute;i l&agrave; &ldquo;Ta c&oacute; thể &aacute;p dụng Abstract Factory Design Patterns cho class Hotel&rdquo; thế th&ocirc;i!)&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;2. Những điểm mạnh của Design Patterns&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Việc nắm bắt v&agrave; &aacute;p dụng Design Patterns v&agrave;o trong c&ocirc;ng việc của một Developer thực sự sẽ gi&uacute;p ta c&oacute; một bước ph&aacute;t triển ho&agrave;n to&agrave;n mới về cả tư duy lẫn kỹ năng lập tr&igrave;nh. Bạn c&oacute; thể thấy r&otilde; điều đ&oacute; qua những điểm mạnh của n&oacute; sau đ&acirc;y:&nbsp;&lt;/p&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Gi&uacute;p bạn tăng tốc độ ph&aacute;t triển c&aacute;c ứng dụng.&nbsp;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Cải thiện code structure, dễ d&agrave;ng n&acirc;ng cấp v&agrave; sửa đổi.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Tăng khả năng code reusability.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Tăng t&iacute;nh readable đối với những cấu tr&uacute;c code phức tạp. Tăng khả năng communicate giữa c&aacute;c th&agrave;nh vi&ecirc;n trong team (Nếu mọi người đều biết về Design Patterns)&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Do c&aacute;c Design Patterns đ&atilde; được tối ưu n&ecirc;n ta cũng c&oacute; thể tr&aacute;nh được những lỗi kh&ocirc;ng mong muốn ph&aacute;t sinh trong qu&aacute; tr&igrave;nh Implementation.&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;3. Những hạn chế của Design Patterns&lt;/h2&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Design Patterns kh&ocirc;ng phải l&agrave; ch&igrave;a kh&oacute;a vạn năng, n&oacute; chỉ c&oacute; thể giải quyết được một số những vấn đề nhất định. Nếu ta sử &aacute;p dụng Design Patterns v&agrave;o những trường hợp kh&ocirc;ng ph&ugrave; hợp c&oacute; thể l&agrave;m code trở n&ecirc;n rối v&agrave; phức tạp hơn.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Design Patterns chỉ l&agrave;m cho code dễ đọc dễ hiểu với những người c&oacute; kinh nghiệm về Design Patterns đang được &aacute;p dụng. Tuy nhi&ecirc;n đối với những người mới c&oacute; thể sẽ gặp kh&oacute; khăn trong việc nắm bắt cấu tr&uacute;c v&agrave; kh&oacute; khăn trong việc debug.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Bản th&acirc;n từng Design Patterns cũng c&oacute; những khuyết điểm của ri&ecirc;ng n&oacute; (ta sẽ khảo s&aacute;t cụ thể khi đi v&agrave;o chi tiết từng Pattern). N&ecirc;n khi &aacute;p dụng Design Patterns n&agrave;o ta lu&ocirc;n phải c&acirc;n nhắc kỹ lưỡng những lợi &iacute;ch v&agrave; khuyết điểm của n&oacute; để đưa ra quyết định c&oacute; n&ecirc;n sử dụng hay kh&ocirc;ng.&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;4. Ph&acirc;n loại c&aacute;c Design Patterns:&lt;/h2&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Nh&oacute;m Creational: Nh&oacute;m Creational l&agrave; nh&oacute;m những Design Patterns tập trung c&aacute;c giải ph&aacute;p khởi tạo đối tượng v&agrave; che giấu logic khởi tạo những đối tượng:&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;&lt;i&gt;Nh&oacute;m Creational bao gồm: Factory Method,&nbsp;Abstract Factory, Builder, Prototype, Singleton&lt;/i&gt;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Nh&oacute;m Structural: Nh&oacute;m Structural l&agrave; nh&oacute;m những Design Patterns tập trung v&agrave;o việc tối ưu c&aacute;c thiết kế của class v&agrave; sự kết hợp c&aacute;c class v&agrave; object trở lại một cấu tr&uacute;c lớn hơn.&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;&lt;i&gt;Nh&oacute;m Structural bao&nbsp;gồm:&nbsp;Adapter, Bridge, Composite, Decorator, Facade, Flyweight v&agrave;&nbsp;Proxy&lt;/i&gt;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Nh&oacute;m Behavioral: Nh&oacute;m Behaviour l&agrave; nh&oacute;m những Design Patterns tập trung sự ph&acirc;n chia tr&aacute;ch nhiệm của c&aacute;c class v&agrave; object để phục vụ một mục đ&iacute;ch cụ thể. Nh&oacute;m n&agrave;y tập trung nhiều hơn v&agrave;o mối quan hệ giữa c&aacute;c class v&agrave; object với nhau.&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;&lt;i&gt;Nh&oacute;m Behavioral bao gồm:&nbsp;Interpreter, Template Method, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy v&agrave; Visitor&lt;/i&gt;&nbsp;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;5. Cần chuẩn bị những g&igrave; trước khi t&igrave;m hiểu về Design Patterns?&lt;/h2&gt;&lt;ul&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;OOP: Tất nhi&ecirc;n rồi, bạn phải nắm t&iacute;nh vũng tư duy lập tr&igrave;nh theo hướng đối tượng đ&atilde;. C&aacute;c Design Patterns đơn giản l&agrave; gi&uacute;p bạn triển khai c&aacute;c t&iacute;nh chất của OOP dễ d&agrave;ng v&agrave; linh hoạt hơn m&agrave; th&ocirc;i.&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;C&aacute;ch đọc sơ đồ UML:&nbsp; C&aacute;c Design Pattern thường được thể hiện dưới dạng UML diagram, việc đọc hiểu một số concept UML cơ bản l&agrave; cần thiết để bắt đầu học Design Patterns&nbsp;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;C&aacute;c bạn c&oacute; thể tham khảo tại đ&acirc;y:&nbsp;&lt;a href=&quot;https://www.guru99.com/uml-diagrams.html&quot;&gt;&lt;i&gt;&lt;u&gt;https://www.guru99.com/uml-diagrams.html&lt;/u&gt;&lt;/i&gt;&lt;/a&gt;&lt;/li&gt;&lt;li style=&quot;text-align:justify;&quot;&gt;Dưới đ&acirc;y l&agrave; 1 số concept UML cơ bản m&igrave;nh sẽ sử dụng trong loạt b&agrave;i viết n&agrave;y:&nbsp;&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-Cn1yI9X33XdJ5N3xgCYsyzvq0ix1YjSsqI6bTqLf.png&quot; alt=&quot;A picture containing diagram
        Description automatically generated&quot;&gt;&lt;/p&gt;&lt;p&gt;&lt;img src=&quot;https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-CpD296nUoYXW0lMySCd5csSytIINBYEQV7eQ1CdD.png&quot; alt=&quot;Diagram
        Description automatically generated&quot;&gt;&lt;/p&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;ul&gt;&lt;li&gt;Ngo&agrave;i ra hiểu được 2 quy tắc thiết kế &ldquo;&lt;i&gt;program to interfaces, not implementations&rdquo;&nbsp;&lt;/i&gt;v&agrave; &ldquo;&lt;i&gt;favor composition over inheritance&rdquo;&nbsp;&lt;/i&gt;cũng kh&aacute; quan trọng. Hầu hết c&aacute;c Design Patterns đề được thiết kế dựa tr&ecirc;n 2 quy tắc n&agrave;y.&lt;/li&gt;&lt;/ul&gt;&lt;h2&gt;6. Lời Kết&lt;/h2&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T&oacute;m lại th&igrave;: Design Patterns l&agrave; những mẫu thiết kế để giải quyết những vấn đề phổ biến hay gặp phải trong lập tr&igrave;nh, đ&atilde; được chấp nhận v&agrave; sử dụng rộng r&atilde;i của nhiều lập tr&igrave;nh vi&ecirc;n c&oacute; kinh nghiệm.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&Aacute;p dụng Design Patterns gi&uacute;p bạn cải thiện đ&aacute;ng kể tốc độ ph&aacute;t triển ứng dụng v&agrave; dễ d&agrave;ng hơn trong việc bảo tr&igrave;, sửa chữa.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tuy nhi&ecirc;n, bạn cũng cần phải c&acirc;n nhắc kỹ lưỡng t&iacute;nh chất của b&agrave;i to&aacute;n cần giải quyết, quy m&ocirc; dự &aacute;n đang triển khai cũng như những th&agrave;nh vi&ecirc;n trong team của bạn trước khi cố gắng &aacute;p dụng bất k&igrave; Design Patterns n&agrave;o v&agrave;o code của dự &aacute;n.&lt;/p&gt;&lt;p style=&quot;text-align:justify;&quot;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cuối c&ugrave;ng, Design Patterns sinh ra nhằm mục đ&iacute;ch đơn giản h&oacute;a qu&aacute; tr&igrave;nh ph&aacute;t triển ứng dụng, chứ kh&ocirc;ng phải l&agrave;m cho n&oacute; phức tạp l&ecirc;n. Nhớ điều n&agrave;y nh&eacute;!&lt;/p&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;p&gt;&lt;strong&gt;References:&nbsp;&lt;/strong&gt;&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://refactoring.guru/design-patterns&quot;&gt;&lt;u&gt;Design Patterns&lt;/u&gt;&lt;/a&gt;&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;https://www.digitalocean.com/community/tutorials/gangs-of-four-gof-design-patterns&quot;&gt;&lt;u&gt;Gangs of Four (GoF) Design Patterns | DigitalOcean&lt;/u&gt;&lt;/a&gt;&lt;/p&gt;&lt;p&gt;Books:&nbsp;&lt;a href=&quot;https://books.google.com.vn/books/about/Head_First_Design_Patterns.html?id=GGpXN9SMELMC&amp;amp;redir_esc=y&quot;&gt;&lt;u&gt;Head First Design Patterns&lt;/u&gt;&lt;/a&gt;&lt;/p&gt;&lt;/body&gt;&lt;/html&gt;

Design Patterns là một trong những công cụ hữu hiệu nhất để giải quyết các bài toán bạn gặp phải trong khi lập trình. Trong bài viết này mình sẽ chia sẻ cho các bạn khái niệm tổng quan về Design Patterns. Ở những bài viết sau ta sẽ đi sâu vào từng Design Patterns để có thể hiểu sâu hơn về nó.

Giới thiệu tổng quan về Design Patterns

Mô hình kiến trúc N-layer đã khá phổ biến trong phát triển phần mềm, nhưng nó vẫn có khá nhiều điểm yếu. Từ đó, nhiều kiến trúc khác đã ra đời để giúp việc phát triển được tốt hơn. Trong bài viết này, chúng ta sẽ tìm hiểu 2 mô hình được sử dụng rộng rãi là Onion và Clean.

So sánh Onion Architecture và Clean Architecture

Bài viết này mình tập trung chủ yếu vào các nguyên lý của SOLID.  Nhằm hướng dẫn cho anh em lập trình viên nhà mình có một cái nhìn tổng quan về SOLID chẳng hạn như: SOLID là gì? Lợi hại của SOLID? Hy vọng có thể support được mọi người có thêm kiến thức về các nguyên lý thiết kế code.

[Design Pattern] Bài 01: SOLID Trong Thiết Kế Hướng Đối Tượng

Bài viết nằm trong chuỗi bài về design pattern. Mở đầu của serie này là một design pattern khá quen thuộc và thân thương đó chính là Singleton. Vậy Singleton là gì, làm sao để implement một Singleton...
Qua bài viết hy vọng có thể support được mọi người có thêm kiến thức về Singleton.
OK Let’s Go.

[Design Pattern] Bài 03: Sử Dụng Singleton Trong Java

[Design Pattern] Bài 04: Sử Dụng Factory Trong Java

Bài viết nằm trong chuỗi bài về design pattern. Là phần tiếp theo của Creational pattern, Builder một design pattern cực kỳ hữu dụng trong việc tạo ra object. Vậy Builder là gì, làm sao để implement một Builder. Qua bài viết hy vọng có thể support được mọi người có thêm kiến thức về Builder.

[Design Pattern] Bài 05: Sử Dụng Builder Trong Java

Design Patterns

<html><body><h2>1. Builder Design Pattern Là Gì</h2>Ở những bài trước mình cũng đã giới thiệu với anh em các mẫu design thuộc nhóm Creational như <a href="https://saigontechnology.com/blog/design-pattern-lesson-03-using-singleton-in-java">Singleton</a> và <a href="https://saigontechnology.com/blog/factory-design-pattern-in-java">Factory</a>. Hôm nay, mình sẽ giới thiệu thêm một mẫu design nữa cùng cha khác ông nội với hai mẫu trên, hân hạnh giới thiệu Builder pattern.Thứ nhất, mình cũng xin góp vui một tí đó là mấy ông anh bà chị ngày xưa cũng khá rảnh rỗi nên đẻ ra một đống pattern cho đời con, đời cháu gối đầu giường. Nào là Singleton, Factory giờ lại còn Builder vâng vâng và mây mây…Thật ra, nếu nghiền ngẫm thì cái gì cũng có nguyên do, Singleton thì đảm bảo tạo ra một instance duy nhất, Factory thì có thể tạo ra nhiều loại object dựa vào các condition. Tuy nhiên, phần lớn anh em dev đều phải làm việc với những object có rất nhiều thuộc tính và việc tạo ra object như vậy thật sự rất nan giải. Tại sao lại nan giải? Và có giải pháp nào cho vấn đề này không? Câu trả lời chính là Builder pattern.Ok, Lets Go, giờ mình cùng nhau phân tích cái “nan giải” và làm sao Builder giúp chúng ta giải quyết những vấn đề này.Vẫn là ví dụ dựa trên nền tảng Fintech. Chúng ta đi xây dựng một hệ thống Core Banking. Tính năng cụ thể mình cần implement chính là viết một API tạo BankAccount cho ngân hàng SaigonTechnologyBank. Tuy là một trong những ngân hàng tầm cỡ quốc tế nhưng ngân hàng ngày chỉ yêu cầu thông tin cho mỗi Account bao gồm: họ tên khách hàng, địa chỉ email và số điện thoại.Yêu cầu hơi bị dễ và chúng ta có thể đưa ra solution trong một nốt nhạc.public class BankAccount {    private String fullName;    private String email;    private String phoneNumber;    public BankAccount(String fullName, String email, String phoneNumber){        this.fullName = fullName;        this.email = email;        this.phoneNumber = phoneNumber;    }}Với sự thành công từ SaigonTechnologyBank thì ngày càng có nhiều ngân hàng khác mong muốn sử dụng hệ thống CoreBanking của chúng ta. Tuy nhiên ngoài những thông tin chung cho BankAccount thì với mỗi ngân hàng mới, lại có thêm rất nhiều thông tin khác như: căn cước công dân, quốc tịch, địa chỉ, nghề nghiệp, thông tin người thân…Class BankAccount giờ đây có thêm kha khá thuộc tính, điều này dẫn đến việc muốn tạo object thì phải thêm tất cả các thuộc tính này vào constructor. Thử tưởng tượng một constructor mà có hơn mười tham số thì sao? Thì mệt chứ sao.<ul><li style="text-align:justify;">Mệt vì cần quá nhiều tham số truyền vào từ phía client, đây cũng là một hạn chế của việc sử dụng Factory.</li><li style="text-align:justify;">Mệt vì phải nhớ từng vị trí của từng tham số.</li><li style="text-align:justify;">Mệt vì có nhiều tham số là optional.</li></ul>Giải pháp cũng khá đơn giản là mình tạo ra nhiều constructor, muốn tạo object như nào thì cứ sử dụng constructor tương ứng. Thế nhưng, việc tạo ra các constructor lại gây ra nhiều sự nhầm lẫn và bắt buộc lập trình viên phải nhớ cách sử dụng hoặc phải investigate từng constructor để có thể chọn một cái thích hợp nhất.Tưởng gì, vậy thì mình tạo ra một constructor với các required fields. Rồi dùng setter() để update thông tin cho các optional fields. Tuyệt vời, nhưng cách này lại không thể apply cho immutable object.Khóc một dòng sông. Cách này không được, cách kia cũng không được. Nhưng may mắn, các tiền bối đi trước đã thiết kế ra một design pattern có tên là Builder. Nghe cái tên là thấy uy tín rồi. Thiết kế này giúp chúng ta khắc phục được những hạn chế của các vấn đề trên.<h2>2. Builder Design Pattern Diagram</h2><figure class="image image_resized" style="width:85.96%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/unnamed%20(15)-JUl9d6DWlxRvA9Oxbss5HoVkntg0TOOToq0C8Yvr.webp"></figure> Giờ mình cùng nhau tìm hiểu các cách để implement Builder design pattern.Từ class diagram anh em coder có thể dễ dàng nhận thấy được cách implement cho Builder khá giản đơn. AccountDirector sử dụng BankAccountBuilder để tạo ra BankAcount. Ở đây, anh em mình assume rằng BankAccount có nhiều optional fields nhé.<h2>3. Builder Design Pattern Implementation</h2>Dựa vào diagram trên anh em mình cùng nhau đi qua cách implementation của design pattern này.Để cho đơn giản thì mình sẽ đặt class BankAccountBuilder vào class BankAccount.public class BankAccount{     private String bankName;     // Required field    private String accountNumber;// Required field    private String idNumber;     // Required field     private String fullName;    private String email;    private String password;    private String address;     public BankAccount(String bankName, String accountNumber, String idNumber){        this.bankName = bankName;        this.accountNumber = accountNumber;        this.idNumber = idNumber;    }     // Getter() and Setter() should be here     public static class BankAccountBuilder {         private String bankName;      // Required field        private String accountNumber; // Required field        private String idNumber;      // Required field         private String fullName;        private String email;        private String password;        private String address;         public BankAccountBuilder(String bankName, String accountNumber, String idNumber){            this.bankName = bankName;            this.accountNumber = accountNumber;            this.idNumber = idNumber;        }         public BankAccountBuilder withFullName(String fullName){            this.fullName = fullName;            return this;        }         public BankAccountBuilder withEmail(String email){            this.email = email;            return this;        }         public BankAccountBuilder withPassword(String password){            this.password = password;            return this;        }         public BankAccountBuilder withAddress(String address){            this.address = address;            return this;        }         public BankAccount build() {// validation() should be here.     BankAccount bankAccount = new BankAccount(this.bankName, this.accountNumber, this.idNumber);             bankAccount.setFullName(this.fullName);            bankAccount.setEmail(this.email);            bankAccount.setPassword(this.password);            bankAccount.setAddress(this.address);             return bankAccount;        }    }}Và dưới đây là cách mà class AccountDirector sẻ sử dụng BankAccountBuilder để build object của BankAccount. public class AccountDirector{    public static void main(String[] args){        String bankName = "SaigonTechnologyBank";        String accountNumber = "STS7777777";        String idNumber = "7777777";         BankAccount account = new BankAccount.BankAccountBuilder(bankName, accountNumber, idNumber)                .withFullName("Wind Hero")                .withAddress("MID")                .build();         System.out.println(account);    }}<h2>4. The Pros and Cons of Builder Design Pattern</h2><h3>The Pros of Builder</h3><ul><li>Với Builder điểm mạnh đầu tiên mình có thể nhìn thấy đó là pattern này giúp chúng ta kiểm soát việc tạo ra object có nhiều thuộc tính một cách dễ dàng.</li><li>Giải phóng constructor có nhiều tham số đồng thời giảm tải số lượng constructor dư thừa.</li><li>Builder có thể hỗ trợ tạo ra immutable object.</li></ul>StringBuilder và StringBuffer chính là hai trong số nhiều Builder thông dụng được cung cấp bởi Java.<h3>The Cons of Builder</h3><ul><li>Nhược điểm lớn nhất của Builder chính là việc bị duplicate code. Vì hầu như Class Builder phải copy hoàn toàn các thuộc tính của Class Product.</li><li>Class Builder sẽ ngày càng phình to ra khi có thêm các thuộc tính mới</li></ul>Hiện tại, anh em dev nhà Java có thể dùng Lombok để đơn giản hóa việc tạo ra Builder.<h2>5. The Conclusion</h2>Mình xin phép kết thúc bài viết tại đây. Qua bài viết mình cũng đã list ra thế nào là Builder design pattern. Các cách để implement một Builder… Hy vọng nhận được nhiều đóng góp của mọi người để cộng đồng lập trình ngày càng phát triển và đặc biệt để những bài viết sau được tốt hơn.</body></html>

<html><body><h2>1. Giới Thiệu Về SOLID</h2>Phần lớn ai trong chúng ta đã ít nhiều đã nghe qua các nguyên lý như là: Nguyên Lý Chuồng Bồ Câu, Nguyên Lý Tảng Băng Trôi…Trong ngành công nghệ phần mềm của chúng ta cũng có một nguyên lý đó là Nguyên Lý Thiết Kế Hướng Đối Tượng SOLID. Đầu tiên mình xin chia sẻ cách mình hiểu về chữ “nguyên lý”. Với mình nguyên lý là lý thuyết được đúc kết từ kinh nghiệm thực tiễn chỉ ra những nguyên tắc đúng đắn. Lấy ví dụ: Đặt N con chim bồ câu vào M cái chuồng với điều kiện N &gt; M thì ít nhất sẻ có một cái chuồng có nhiều hơn một con chim bồ câu. Trước hết anh em coder hãy cùng nhau tìm hiểu về SOLID để biết xem em nó là gì. Các nguyên lý SOLID được giới thiệu lần đầu tiên vào năm 2000 bởi Robert C.Martin với cái tên thiện lành chú Bob (Uncle Bob) - tác giả của nhiều cuốn sách nổi tiếng về Clean Code, Clean Architect… và SOLID chính là chữ viết tắt của các nguyên lý sau: <ul><li style="text-align:justify;">Single Responsibility Principle</li><li style="text-align:justify;">Open-Closed Principle</li><li style="text-align:justify;">Liskov Substitution Principle</li><li style="text-align:justify;">Interface Segregation Principle</li><li style="text-align:justify;">Dependency Inversion Principle</li></ul> Nguyên Lý Thiết Kế Hướng Đối Tượng SOLID chính là những kinh nghiệm được các thế hệ đi trước rút ra trong quá trình chinh chiến trên các dự án thực tiễn. Các nguyên lý này chỉ ra cho mình cách để thiết kế code có hiệu quả hơn. Hiệu quả ở đây có nghĩa là: dễ đọc, dễ hiểu, dễ kiểm thử…và đặc biệt dễ bảo trì. Giờ mình sẽ cùng nhau tìm hiểu qua từng nguyên lý của SOLID. <h2 style="text-align:justify;">2. Single Responsibility Principle (SRP)</h2>Nguyên lý đầu tiên tương ứng với chữ S trong SOLID có nội dung như sau:“A class should have one and only one reason to change, meaning that a class should have only one job.”<img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-eAWTPK0qDTEC44wBMFtAWbmVljalfNDdqSKPxcug.png">Free source: <a href="https://codingjourneyman.com/2015/02/11/solid-single-responsibility-principle/">https://codingjourneyman.com/2015/02/11/solid-single-responsibility-principle/</a> Nguyên lý nói rằng một class chỉ nên có một và chỉ một lý do để thay đổi, điều đó có nghĩa là một class chỉ nên chịu trách nhiệm một công việc nào đó mà thôi. Điểm chính ở đây là mọi thứ trong class phải liên quan đến một mục đích chứ đừng hiểu nhầm thành trong một class chỉ có thể chứa một thuộc tính hoặc một phương thức nhé.Mình sẽ lấy ví dụ cho các bạn dễ hiểu: <pre><code class="language-plaintext">public class FinancialReport {
	public void loadDataFromDatabase();
	public void exportDataToPDF();
	public void dataMining();
}</code></pre>Class FinancialReport đang giữ đến ba chức năng. Nếu mình thay đổi cơ sở dữ liệu hoặc thay đổi cách export data thì mình phải sửa đổi class này. Nếu trong tương lai lại có thêm nhiều tính năng thì class sẽ ngày càng phình to ra. Suy ra, class FinancialReport đã vi phạm nguyên lý SRP. Giờ mình sẽ áp dụng nguyên lý SRP để sữa lại class này. Ta có thể tách class này ra làm ba Class riêng, mỗi class chỉ làm một nhiệm vụ duy nhất. Tuy số lượng class của chúng ta tăng lên nhưng code sẽ rõ ràng hơn, dễ đọc hơn. Và nếu muốn sửa code trong một class nào đó thì cũng không ảnh hưởng đến các class còn lại.Đến đây sẽ có một hiểu nhầm nữa của developer là lo sợ số lượng class tăng lên sẽ không tốt. Đừng lo nhé, vấn đề thực sự nằm ở số lượng dòng code của từng class. Tuy số lượng class sẽ tăng nhiều hơn nhưng việc sửa chữa sẽ đơn giản hơn, dễ dàng tái sử dụng hơn, class ngắn hơn nên cũng ít bug hơn. Trong trường hợp bạn có apply Unit Test thì việc áp dụng SRP cũng hạn chế rất nhiều việc sửa lại các hàm test.<h2 style="text-align:justify;">3. Open-Closed Principle (OCP)</h2>Nguyên lý thứ hai chính là chữ O trong SOLID có nội dung như sau:“Objects or entities should be open for extension, but closed for modification.”<img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-UAO7ceiAejNz3SIcEXWrWqwum9i5HsDq0NRTYpPv.png">Free source: <a href="https://self-learning-java-tutorial.blogspot.com/">https://self-learning-java-tutorial.blogspot.com/</a>Chúng ta có thể “mạnh dạng” mở rộng class một cách thoải mái, nhưng đừng sửa code nó. Trong ngành lập trình của chúng ta có một nguyên tắc bất di bất dịch đó là cái gì nó đang work tốt thì đừng có đụng vào.Trong thực tế, chúng ta hay thay đổi chức năng đã có, thêm chức năng mới, hoặc xóa luôn chức năng đó. Việc đó ảnh hưởng rất lớn đến chương trình đang chạy. Việc thêm bớt dù chỉ một dòng code cũng bắt buộc ta phải test lại toàn bộ chức năng. Vì thế, khi code chúng ta cố gắng đừng sửa class có sẵn mà hãy xem xét có thể mở rộng class được không. Tạo class mới trên nền class cũ giúp chúng ta hạn chế việc làm cho những thứ có sẵn bị lỗi, chúng ta chỉ cần tập trung lo cho tính năng mới.Mình sẽ lấy một ví dụ để minh họa việc vi phạm nguyên lý OCP<pre><code class="language-plaintext">public class Shape {
    public double height;
    public double width;
    public double radius;
    public double area(String shapeType){
        if(shapeType.equals("rectangle")){
            return this.height*width;
        }else if (shapeType.equals("circle")){
            return 3.14*radius*radius;
        }
        return 0.0;
    }
}</code></pre>Với cách viết này, code vẫn chạy ngon lành tuy nhiên trong trường hợp chúng ta muốn tính thêm diện tích của hình tam giác, hình than…thì chúng ta phải thêm các thuộc tính tương ứng cũng như là phải thêm nhiều đoạn if-else statement. Làm cho class ngày càng phình ra, rối ren và việc kiểm thử cũng trở nên phức tạp hơn. Giờ mình sẽ apply giải pháp của OCP xem như thế nào nhé.<pre><code class="language-plaintext">public abstract class Shape{
    public double height;
    public double width;
    public abstract double area(String shapeType);
}
public class Rectangle extends Shape{
    @Override
    public double area(String shapeType){
        return this.height*width;
    }
}
public class Triangle extends Shape{
    public double radius;
    @Override
    public double area(String shapeType){
        return this.radius*this.radius*3.14;
    }
}</code></pre>Bằng cách sử dụng tính năng Inheritance trong OOP để hiện thức hóa OCP. Mỏi khi chúng ta cần tính diện tích cho một loại Shape nào đó chúng ta chỉ việc vào thêm class mới. Điều này trách việc chúng ta phải modify trực tiếp vào class Shape như phương pháp củ.<h2 style="text-align:justify;">4. Liskov Substitution Principle (LSP)</h2>Nguyên lý thứ ba tương ứng với chữ L trong SOLID có nội dung như sau:“Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” <img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-Ab8zLRAXxmTHdTOZ8nEN3cNngyVhxthbJK3lg62M.png"> Free source: <a href="https://www.vectorstock.com/">https://www.vectorstock.com/</a>Các đối tượng có kiểu class cha trong chương trình có thể được thay thế bằng các đối tượng có kiểu class con của nó mà không thay đổi tính đúng đắn của chương trình.Nghe có vẻ rắc rối và trừu tượng quá. Theo mình hiểu nguyên lý này có ý nghĩa là các class con phải có cùng bản chất với class cha. Mình cùng xem qua một ví dụ như sau. Giả xử, mình có class Bird. Dĩ nhiên Bird thì có thể bay lượn bằng đôi cánh. Vậy các class con của Bird có thể là class Pigeon, class Eagle. Nhưng class AirPlane thì không thể là class con của Bird được. Mặc dù em nó cũng có cánh và biết bay, tuy nhiên em nó bay bằng động cơ. Cần phải có động cơ, có nhiên liệu thì máy bay mới có thể bay được. Trong ngữ cảnh này, nếu mình dùng AirPlane đại diện cho Bird thì nó không hợp lý.<h2 style="text-align:justify;">5. Interface Segregation Principle (ISP)</h2>Nguyên lý thứ tư chính là chữ I trong SOLID có nội dung như sau:“Many client-specific interfaces are better than one general-purpose interface”<img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-XedrebjOPnsOayeLh1G2C01RmMLraSdF40zUtqJn.png">Free source: <a href="https://www.lvguowei.me/">https://www.lvguowei.me/</a>Tách ra nhiều interface nhỏ với các mục đích cụ thể thì tốt hơn là sử dụng chung một interface lớn.Đây là một trong những nguyên lý dễ hiểu nhất trong SOLID. Đọc sao hiểu y như vậy. Đôi lúc do trong quá trình code mình tạo một interface, sau đó khi có yêu cầu thêm tính năng mới, anh em developer nhà mình cứ tiện tay thêm một abstract method vào interface cho “tiện”. Đến một lúc nào đó interface phình to ra, và có những class nó chỉ cần sử dụng một hoặc hai method trong interface nhưng phải override hết tất cả các hàm trong interface đó. SoS căng rồi đây. Anh em mình cùng nhìn qua ví dự như sau: <pre><code class="language-plaintext">public interface DatabaseConnection{
    void connect();
    void readData();
    void exportData();
    void insertData();
    void updateData();
}
public class MySQLConnection implements DatabaseConnection{
    @Override
    public void connect(){}
    @Override
    public void readData(){}
    @Override
    public void exportData(){}
    @Override
    public void insertData(){}
    @Override
    public void updateData(){}
}</code></pre> Ở đây class MySQLConnection chỉ làm đúng một nhiệm vụ là connect tới Database nhưng nó lại phải override tất cả các method của interface DatabaseConnection. Từ nay, mình nên chia tay cách coding này nha các bạn. Hãy tách ra thành nhiều interface khác nhau mỏi interface nên tuân thủ nguyên lý SRP để tránh việc tách quá nhiều interface.<h2 style="text-align:justify;">6. Dependency inversion principle (DIP/DI)</h2>Nguyên lý cuối cùng chính là chữ D trong SOLID có nội dung như sau:“High-level modules should not depend on low-level modules. Both should depend on abstractions.Abstractions should not depend upon details. Details should depend upon abstractions.”<img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-ZEVOnRLEk6dO86V0cXpp8h0HG1agGNX2MYhrhFwX.png">Free source: <a href="https://www.expertreviews.co.uk/">https://www.expertreviews.co.uk/</a>Các module cấp cao không phụ thuộc vào module cấp thấp, cả hai phụ thuộc vào các abstraction (abstract classes và interfaces). Các abstraction không phụ thuộc vào chi tiết mà chi tiết mà nên phụ thuộc vào các abstraction Trời ơi, nó còn hại não hơn Liskov Substitution Principle (LSP). Cái gì mà abstraction rồi low-level rồi high-level. Thật ra đây mới chính là chân lý mà các tiền bối đi trước đã để lại cho thế hệ của chúng ta. Mục đích chính của nguyên lý này là giảm sự phụ thuộc giữa các class với nhau. Vậy câu hỏi đặt ra là tại sao lại cần giảm sự phụ thuộc làm gì? Giảm sự phụ thuộc sẻ giúp chúng ta dễ dàng thay đổi, đem lại tính flexible cho chương trình.  Lấy ví dụ trên chính cái laptop của chúng ta. Ngày nay, hầu như tất cả các laptop đều tương thích với hầu hết các loại mouse khác nhau. Mình có thể dùng mouse của thương hiệu Logitech, hoặc mouse của thương hiệu Razer…Cả hai đều chạy tốt với laptop của chúng ta. Dễ dàng nhận thấy rằng giữa laptop và mouse không có một sự ràng buộc cố định. Mình có thể dễ dàng kết nối mouse vào laptop vì nó chỉ quan tâm tới interface (ở đây chính là giao thức kết nối). Nó không quan tâm tới implementation. Trong lập trình cũng vậy, cần vận dụng triệt để interface và abstract class vào quá trình thiết kế code để tạo tính flexible cho source code. Sau này nếu cần thay đổi thì mình chỉ việc coding cho phần implementation. Các bạn đừng nhầm lẫn giữa Dependency Inversion và Dependency Injection. Mình sẽ có một bài chi tiết về  Dependency Injection sau nhé. Qua bài viết mình đã giới thiệu về năm nguyên lý của SOLID:<ul><li style="text-align:justify;">Single Responsibility Principle</li><li style="text-align:justify;">Open-Closed Principle</li><li style="text-align:justify;">Liskov Substitution Principle</li><li style="text-align:justify;">Interface Segregation Principle</li><li style="text-align:justify;">Dependency Inversion Principle</li></ul>Nắm vững kiến thức về SOLID chắc chắn sẽ giúp anh em dev trở nên chuyên nghiệp trong lĩnh vực lập trình và hy vọng với bài viết này mình có thể góp thêm chút kiến thức vào cộng động lập trình và hơn hết chúng ta cần phải “lận lưng” vài nguyên lý nhằm mục đích trở thành lập trình viên chân chính với slogan “requirement đến là đón, requirement change là code”. Hẹn gặp lại trong chủ đề tiếp theo nha!</body></html>

<html><body><h2 style="text-align:justify;">1. Giới Thiệu Về EC2</h2>Mình đã có một bài giới thiệu tổng quan về Amazon Web Service. Các bạn có thể xem lại ở đây <a href="https://docs.google.com/document/d/1rv_FUMNt585OLYVLFG41IX03fYDZljjbXVrIxS4Stzs/edit#heading=h.yjayaup0tlbk">[AWS] Bài 01: Giới Thiệu Về Amazon Web Service (AWS)</a>Trước hết anh em coder mình cùng nhau tìm hiểu về Elastic Compute Cloud để biết xem em nó là gì. Elastic Compute Cloud hay còn được gọi với một cái tên thân mật là EC2. Đây là một service rất thông dụng và nổi tiếng của AWS, cung cấp hệ thống máy tính ảo theo nhu cầu của người sử dụng. Với EC2 chúng ta có thể dễ dàng tạo ra một máy tính ảo chạy một hệ điều hành bất kỳ. Ngoài ra, người dùng cũng có thể dễ dàng tăng hoặc giảm tài nguyên của máy ảo như CPU, RAM…<h2 style="text-align:justify;">2. Điểm Mạnh Của EC2</h2>          Như mình có đề cập ở phần trên thì EC2 cung cấp cho chúng ta các máy tính ảo hóa. Dĩ nhiên đối với các bạn developer, ít nhiều trong quá trình làm việc cũng cần phải thao tác trên một hệ điều hành nào đó, khác với hệ điều hành đang chạy trên máy host. Lấy một ví dụ như sau: mình coding một application bằng ngôn ngữ Java trên hệ điều hành Window. Nhưng khi deploy thì lại phải deploy lên một con server chạy hệ điều hành Ubuntu. Tuy nhiên, mình lại không có kinh nghiệm trên Ubuntu và mình cần tìm hiểu về cách sử dụng hệ điều hành đó trước. Hoặc một ví dụ khác là mình đang sử dụng Macbook nhưng lại cần phải thao tác trên Window…cuộc sống đúng là khó khăn mà. Giải pháp cho vấn đề trên là mình có thể cài đặt máy tính ảo trên VirtualBox hoặc mình cũng có thể sử dụng Docker. Ở đây, mình muốn giới thiệu thêm cho các bạn một giải pháp khác nữa, đó chính là sử dụng EC2 của AWS.Vậy nếu sử dụng EC2 thì nó có gì sang xịn mịn hơn VirtualBox hoặc Docker? Thật ra thì cũng tùy thuộc vào nhu cầu của người sử dụng, nếu chỉ cần một máy ảo với tài nguyên nhỏ hoặc vừa, kiểu như cần một máy ảo Ubuntu với RAM khoản 4G, nhằm mục đích mày mò học hỏi CLI lúc đó dùng VirtualBox or Docker thì vẫn cực kỳ tốt và tiện lợi.  Nhưng với nhu cầu cao hơn thì sao? Mình cần một máy server Ubuntu, RAM là 32G để triển khai một hệ thống micro-services siêu to khổng lồ cho công ty Saigon Technology. Rõ ràng các phần mềm ảo hóa chạy trên máy host sẻ khó có thể đáp ứng được yêu cầu này. Lúc này, giải pháp có thể là mình đi thuê hoặc mua một máy chủ vậy lý. Tuy nhiên với giải pháp này mình lại phải tự setup các phương thức để bảo mật server, rồi khi cần nâng cấp resource cũng là một vấn đề lớn, chưa kể tới việc có khi mình cần nhiều hệ điều hành như Ubuntu, Centos… Amazon EC2 hoàn toàn có thể giúp anh em mình giải quyết những vấn đề trên.<ul><li style="text-align:justify;">Mình có thể dễ dàng tạo ra một hoặc nhiều máy chủ ảo hóa nhanh chóng với thông số resource như CPU , RAM và hệ điều hành được chỉ định.</li><li style="text-align:justify;">Khi không có nhu cầu sử dụng nữa, thì mình có thể stop máy chủ lại hoặc xóa hẳn khỏi EC2.</li><li style="text-align:justify;">Thông tin đăng nhập vào máy chủ được bảo mật và sử dụng cơ chế keypair (public và private key).</li><li style="text-align:justify;">EC2 còn cung cấp tính năng giúp mình thiết lập rank IP Private.</li><li style="text-align:justify;">Chúng ta cũng có thể cấu hình Security Group và Network ACLS để kiểm soát inbound và outbound cho từng instance EC2.</li><li style="text-align:justify;">EC2 cung cấp IPv4 tĩnh.</li><li style="text-align:justify;">Virtual Private Clouds (VPC): Giúp cho bạn có thể cô lập hoặc kết nối các máy chủ ảo hóa với nhau.</li></ul><h2 style="text-align:justify;">3. Hạn Chế Của EC2</h2>          Hạn chế thứ nhất mình muốn đề cập là là về chi phí. Cái này cũng không hẳn là hạn chế, nếu bạn cần một máy ảo mạnh mẽ thì dĩ nhiên bạn phải chịu chi phí hàng tháng khá cao. Mọi thứ hầu như đã được support tận răng rồi, mình chỉ sử dụng thôi mà, nên tốn thêm chi phí thì cũng hợp lý. Tuy nhiên nếu mình cần một máy ảo nhỏ gọn kiểu để học hỏi là chính thì mình có thể dùng Free-Tier, tuy nói là free nhưng nó support khá tốt cho anh em. Chổ này anh em cần chú ý là nếu không sử dụng thì nên stop hoặc xóa Instance của EC2 luôn để tránh AWS charge phí lưu trữ nha.           Hạn chế thứ hai đó là khi mình stop instance đi do không có nhu cầu sử dụng, thì lúc mình start lại instance đó, địa chỉ IPv4 đã sẽ bị thay đổi. Này là một câu chuyện buồn của mình, khi mình tìm hiểu về EC2 do cũng muốn tiết kiệm chi phí nên mình stop instance lại khi nào cần thì start lên. Lúc đó, start lên thì mình lại không connect lại được bằng CLI. Kết quả là tốn hết một ngày mới mò ra lý do. Buồn dễ sợ.           Nếu mình chưa có kinh nghiệm trên VPC hoặc cách cấu hình Security Group, IAM…thì đây cũng là một hạn chế dẫn đến nhiều khó khăn trong việc sử dụng EC2           EC2 là một IaaS (Infrastructure as a service) nên việc sử dụng EC2 còn phụ thuộc vào network. Do đó nếu network của bạn không ổn định hoặc đường truyền internet yếu thì việc kết nối đến EC2 cũng không được mượt mà. Qua bài viết mình đã giới thiệu về EC2, điểm mạnh và những hạn chế của công nghệ này, hy vọng có thể support được mọi người có thêm kiến thức bước vào thế giới “mênh mông” của AWS. Tiếp theo mình có làm một video hướng dẫn mọi người cài đặt một máy EC2 chạy hệ điều hành Window.<h2 style="text-align:justify;">4. Hướng dẫn Setup một EC2 với Hệ Điều Hành Window</h2>          Mình có làm một video để hướng dẫn mọi người cách cài đặt một máy chủ Window trên nền tảng AWS EC2. Mọi người có thể xem qua video ở <a href="https://drive.google.com/file/d/1M6CGzoUmGTdjCM2mz7arov6-uVZZveIY/view">setup-ec2-window </a>. Tùy vào từng thời điểm có thể giao diện của AWS Console khác đôi chút so với video của mình. </body></html>

Bài viết này mình tập trung chủ yếu vào Elastic Compute Cloud (EC2).  Nhằm hướng dẫn cho anh em lập trình viên nhà mình có một cái nhìn tổng quan nhất về EC2 chẳng hạn như: EC2 là gì? Lợi ích của EC2?
Qua bài viết hy vọng có thể support được mọi người có thêm kiến về AWS EC2.
OK Let’s Go.

[AWS] Bài 02 - Hướng Dẫn Cài Đặt Elastic Compute Cloud (EC2) Window

<html><body><h2 style="text-align:justify;">1. AWS Là Gì</h2>Trước tiên anh em mình cùng nhau tìm hiểu để biết xem AWS là gì nhé. Amazon Web Service hay còn được gọi với cái tên thân mật là AWS.  Thật ra có hàng trăm thậm chí là hàng ngàn câu hỏi liên quan đến AWS khi mình tự tập tành tìm hiểu về nó và sau một thời gian tìm hiểu cũng như làm thực tế trên các dự án liên quan đến AWS mình xin mạo muội làm một series về AWS để chia sẻ với anh em đang có mong muốn tìm hiểu về nền tảng đám mây này. Ông bà ta có câu: Răng với tóc là gốc con người, cái tên nói lên tất cả. Amazon Web Service là dịch vụ điện toán đám mây (Cloud Services) nó cung cấp rất nhiều dịch vụ từ việc lưu trữ như: Storage, rồi thì Networking, Virtualization đến cả Machine Learning, AR &amp; VR…Mình sẽ liệt kê ra cho mấy bạn những service thông dụng mà anh em lập trình viên cũng như DevOps thường dùng. Mình có thể thao tác với AWS thông qua hai công cụ chính là AWS Web Console hoặc là AWS CLI. Sẽ bật mí với mấy bạn về hai công cụ hữu ích này sau nha, giờ mình sẽ list ra những dịch vụ cơ bản của AWS.Common Services Của AWS <ul><li style="text-align:justify;">Storage: AWS S3, Databases, Elastic Container Registry (ERC)</li><li style="text-align:justify;">Virtualization:  Elastic Compute Cloud (EC2)</li><li style="text-align:justify;">Programming: Elastic Container Service (ECS), Code Pipeline, Code Build</li><li style="text-align:justify;">Networking: Virtual Private Cloud (VPC), Route53, Load Balancing</li><li style="text-align:justify;">Identity: IAM</li><li style="text-align:justify;">Monitoring: CloudWatch</li></ul> Anh em có thể đăng ký một tài khoản AWS từ <a href="https://portal.aws.amazon.com/billing/signup#/start/email">website chính hãng</a> để khám phá tất tần tật các dịch vụ của em nó. Ok giờ mình thảo luận tí về lợi ích và thế mạnh mà AWS mang lại.<h2 style="text-align:justify;">2. Điểm Mạnh Của AWS</h2> Rõ ràng lợi ích đầu tiên mình thấy được đó là số lượng dịch vụ mà AWS cung cấp. Có khoản 200 dịch vụ và hầu hết các dịch vụ này đủ sức đáp ứng được nhu cầu phát triển cơ sở hạ tầng cũng như nền tảng công nghệ cho các doanh nghiệp trong nhiều lĩnh vực trong đó các doanh nghiệp về lĩnh vực công nghệ thông tin chiếm đa số. Nhưng số lượng dịch vụ nhiều chỉ là một trong những điểm mạnh của AWS bên cạnh đó chất lượng của từng dịch vụ có thể mô tả trong hai từ “tuyệt vời”. Do đó có rất nhiều công ty kể cả chính phủ tin tưởng vào AWS. Xin cả nhà một phút quảng cáo, công ty <a href="https://saigontechnology.com/">SaiGon Technology</a> đã và đang phát triển rất nhiều sản phẩm dựa trên nền tảng AWS.  Để nói về các điểm mạnh cũng như tiện ích của AWS, mình sẽ lấy một ví dụ cụ thể để từ đó anh em DEV có cái nhìn thực tiễn và khách quan. Đặc biệt đối với mấy anh em bắt đầu tìm hiểu về AWS cũng có thể hình dung ra được những tính năng mà AWS mang lại. Lấy ví dụ như thế này. Công ty <a href="https://saigontechnology.com/">SaiGon Technology</a> muốn xây dựng một trang web về e-commerce giống như Shopee or Lazada…Mình sẽ list ra những công việc ở mức high level cần phải được hoàn thành như sau: Phát triển những tính năng của trang web: Authorization, Authentication, Purchasing Product, Account Management, Product Management… Xây dựng cơ sở dữ liệu:<ul><li style="text-align:justify;">Lựa chọn hệ quản trị cơ sở dữ liệu: SQL-Server, MySQL, PostgreSQL, No-SQL…</li><li style="text-align:justify;">Cài đặt DBMS vào máy chủ</li><li style="text-align:justify;">Thiết lập các phương án backup dữ liệu</li></ul> Build Server tạo môi trường cho việc kiểm thử và vận hành:<ul><li style="text-align:justify;">Xây dựng các máy chủ như: UAT, Staging, Production</li><li style="text-align:justify;">Build các docker image</li><li style="text-align:justify;">Publish các docker image lên repository</li><li style="text-align:justify;">Deploy docker image</li><li style="text-align:justify;">Xây dựng hệ thống log để monitor trong quá trình vận hành</li><li style="text-align:justify;">Mua tên miền và mapping tên miền vào server</li></ul> Ngoài ra, vào những dịp lễ tết, trang web của chúng ta thường chạy các event giảm giá sập sàn, siêu sale, flash sale…dẫn đến việc quá tải. Lúc đó mình lại phải cấm đầu vào cái việc load balancing để chia tải cho hệ thống.Chốt: rất nhiều công việc mà anh em Dev phải chạy bằng cơm.Vậy thông qua ví dụ trên, mình sẽ liệt kê ra các tính năng hữu ích của AWS cho các bạn.<h3 style="text-align:justify;">Tính Tiện Dụng</h3>AWS là một web service, là một dạng của SaaS do đó chỉ cần trong điều kiện có kết nối đến internet là chúng ta có thể truy cập và sử dụng mọi lúc, mọi nơi.Ngoài ra, cá nhân mình cảm thấy giao diện của AWS được thiết kế gọn gàng, trực quan, tạo cho người dùng cảm giác thân thiện, dễ sử dụng<figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-o6bIfFXJ5P6nJBnndHOmFOr6IQ4sHMK1fC4AeMsZ.png"></figure>Quay lại với ví dụ trên, việc lập trình các tính năm của trang web thì chủ yếu liên quan đến nhánh lập trình bạn có thể sử dụng các ngôn ngữ như: <a href="https://www.facebook.com/SaigonTechnology.HCM.Careers">Java, .Net, Python</a>…Nên mình sẽ không bàn về nó tại thời điểm này.  Mình chuyển sang bước tiếp theo là xây dựng CSDL. Giả sử rằng mình chọn PostgreSQL làm CSDL cho trang web. Vậy theo cách thông thường mình phải setup PostgreSQL vào máy rồi sau đó tạo một connection từ application đến CSDL. Giờ đây với tính năng Relational Database Service (RDS) của AWS mình có thể skip qua việc setting up PostgreSQL. Chỉ một vài cái click chuột mình đã có thể tạo một hệ quản trị CSDL PostgreSQL riêng cho mình. Ngoài ra RDS còn support cả: SQL-Server, MySQL, MariaDB, Oracle <figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-ciEOv3BzNeATVh4G0rIpQk6mqPFvBcRpp2fnzWf5.png"></figure>Free source: <a href="https://scandiplan.dk/en/aws-rds-snowflake">https://scandiplan.dk/en/aws-rds-snowflake</a> Nhưng nếu mình muốn sử dụng Nosql thì sao? Yên tâm bạn có thể sử dụng DynamoDB từ AWS nhé. Tiếp theo là việc build server tạo môi trường cho việc kiểm thử và vận hành trang web của mình. AWS hỗ trợ rất tốt các hệ điều hành Linux, do đó việc tạo và maintain một máy chủ trên AWS có thể được thực hiện thông qua Elastic Compute Cloud (EC2). Với EC2 bạn có thể xây dựng một máy chủ với hệ điều hành mà bạn mong muốn: Fedora, Ubuntu, Window Server, AWS Linux…<figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-uOMEYXqBcGLWobdTRJJ1RH8vhaxuOEExzZ4McM0C.png"></figure>Free source: <a href="https://docs.aws.amazon.com/images/AWSEC2/latest/UserGuide/images/overview_getting_started.png">https://docs.aws.amazon.com</a>Ngoài ra những năm gần đây với sự phát triển và phổ biến của Docker thì AWS cũng ra đời Elastic Container Registry (ERC) hỗ trợ cho việc host các docker image.AWS Code Build, Code Pipeline hỗ trợ rất tốt trong việc build và deploy ứng dụng.<figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/CKEDITOR-cvdfpnfDPGlXTnCBiGjEXqRsmRMqKigBruY39Krc.png"></figure>Free source: <a href="https://skdevops.files.wordpress.com/2022/03/62.image-1.png?w=656&amp;h=300&amp;crop=1">https://skdevops.files.wordpress.com</a> Trên trang web của chúng ta không thể nào thiếu các hình ảnh liên quan đến sản phẩm, hình ảnh đại diện của user…thay vì mình lưu những file hình đó vào CSDL hoặc lưu trực tiếp vào ổ đĩa thì mình có thể tận dụng Simple Storage Service (S3). Một service của AWS hỗ trợ việc lưu trữ và transfer file khá tốt.Như mình có đề cập trong ví dụ là cần một domain name gắn vào server. Ví dụ mình cần một tên miền: <a href="https://www.facebook.com/SaigonTechnology.HCM.Careers">saigontechnology-career.com</a> Vậy thì mình có thể đăng ký tên miền này thông qua AWS Route53. Chi phí thì tùy vào tên miền mình chọn, trung bình khoản 15$/năm. Việc cấu hình tên miền cũng được thực hiện dễ dàng thông qua AWS Web Console.<h3 style="text-align:justify;">Khả Năng Mở Rộng</h3>Khả năng mở rộng cũng chính là một điểm mạnh khi sử dụng Cloud nói chung và AWS nói riêng. Thử hình dung xem, một ngày nào đó lượng dữ liệu mà mình phải chứa trong csdl lên đến hàng TB/ngày thì anh em Dev mình phải cuốn cuồng xử lý. Dĩ nhiên, điều này dẫn đến rất nhiều vấn đề tuy nhiên mình chỉ đề cập ở khía cạnh dung lượng lưu trữ. Hoặc trong các event flash sale, lượng người truy cập quá lớn, lúc đó có thể gây quá tải trên hệ thống. Hoặc đơn giản là mình cần nâng cấp RAM cho máy chủ.Tất cả những vấn đề trên, nếu mình tự build một server vật lý thì anh em Dev phải rất vất vả đi xử lý tuy nhiên mình hoàn toàn có thể được giải quyết nhanh gọn bằng các service của AWS. <h3 style="text-align:justify;">Tính Bảo Mật Cao</h3>Không chỉ riêng về AWS, bảo mật là tính năng cần thiết hàng đầu đối với tất cả các ứng dụng, đặc biệt là các ứng dụng về Cloud. Và AWS đã đạt được các chứng nhận về việc tuân thủ khung đảm bảo quyền riêng tư.<ul><li style="text-align:justify;">ISO 27017 về bảo mật đám mây.</li><li style="text-align:justify;">ISO 27701 về quản lý thông tin quyền riêng tư.</li><li style="text-align:justify;">ISO 27018 về bảo vệ thông tin cá nhân trên đám mây.</li></ul>Nãy giờ mình cũng chém gió về điểm mạnh, giờ mình xin phép chia sẻ một vài cái mình  cảm thấy hạn chế khi sử dụng AWS. <h2 style="text-align:justify;">3. Hạn Chế Của AWS</h2><h3 style="text-align:justify;">Chi Phí</h3>Đầu tiên mình muốn đề cập là vấn đề chi phí. AWS là một dạng Cloud Services do đó nó không chỉ tính chi phí trên nguồn tài nguyên mình sử dụng mà nó còn tính cả chi phí về thời gian lưu trữ. Do đó, có những lúc chi phí phát sinh rất cao mà mình không thể kiểm soát được. AWS có cung cấp tính năng gửi notification khi chi phí vượt quá mức giới hạn cho phép. Tuy nhiên nó chỉ là notification bạn nhé. Vì vậy, trong quá trình sử dụng, các bạn nên chú ý và tắt đi những service thật sự không cần thiết.<h3 style="text-align:justify;">Internet</h3>Là một cloud services nên mình chỉ có thể sử dụng AWS ở những địa điểm có kết nối internet. AWS không hỗ trợ offline nên anh em chú ý nhé.<h3 style="text-align:justify;">Thiếu Chuyên Gia</h3>AWS có cơ sở hạ tầng vô cùng phức tạp, nó cung cấp hàng trăm service trãi dài hầu hết nhiều lĩnh vực. Do đó, còn khá ít các chuyên gia có kỹ năng về AWS. Vì vậy, một tổ chức hay cá nhân muốn phát triển AWS thì đây là một điểm bất lợi khá lớn.Mình xin phép kết thúc bài viết tại đây. Hy vọng nhận được nhiều đóng góp của mọi người để cộng đồng lập trình ngày càng phát triển và đặc biệt để những bài viết sau được tốt hơn. </body></html>

Bài viết nhằm hướng dẫn cho anh em lập trình viên nhà mình có một cái nhìn tổng quan nhất về Amazon Web Service (AWS) chẳng hạn như: AWS là gì? Có gì trong AWS? Lợi ích của AWS? Nên tìm hiểu AWS từ đâu.
Qua bài viết hy vọng có thể support được mọi người có thêm kiến thức về AWS.
OK Let’s Go.

[Design Pattern] Bài 04: Sử Dụng Factory Trong Java

Related articles

OTHER ARTICLES FROM WIND