Anh ơi, em cần anh giúp đỡ vấn đề liên quan đến web lừa đảo. Anh có thể liên hệ với em qua zalo 0973376774 không ạ?

@thangtd90 cách làm của bạn ko chạy đc với 100 số nguyên

hay

vãi cả dịch =))

🤩

Hay quá bác, hóng các bài viết tiếp theo )

cảm ơn bạn đã feedback mình sẽ kiểm tra lại và sửa lại chính tả

@refacore Oke bro

@Tafi Xem ra tôi nhầm lẫn giữa 2 biến thể của Factory Method. Vài dự án gần đây khi không thể chuyển Factory Method sang hướng Factory class, đã củng cố thêm ý tưởng rằng hai cách trên là hai mẫu khác nhau, và ngộ nhận Factory class thành Abstract Factory.

Một số tài liệu không giữ cái tên Factory Method mà đơn giản gọi các class Factory là Factory pattern. Hai biến thể nhưng khác nhau hoàn toàn trong cài đặt và ý đồ:

• Factory Method cài đặt qua thừa kế, người cài đặt biết chính xác cần tạo instance như thế nào.
• Factory không cần thừa kế, ẩn giấu đi sự phức tạp của việc khởi tạo instance.

Hai mẫu đều cung cấp 1 gói lợi ích theo ngữ cảnh, nhưng Factory phổ biến hơn, đồng thời tăng độ phức tạp nếu so với Factory Method.

Phần bình luận về Factory Method là sai. Đoạn code trên không phải Abstract Factory mà là một biến thể của Factory Method, hay gần nghĩa hơn, chỉ là Factory (trong khi Factory Method nhấn mạnh Method và cài đặt sử dụng một phương thức). Cả hai cách cài đặt dùng phương thức và class của Factory Method đều cung cấp một gói lợi ích theo ngữ cảnh, nhưng có sự khác nhau rõ rệt trong cách cài đặt:

• Factory không cần thông qua thừa kế, ẩn dấu đi sự phức tạp.
• Factory Method thông qua sự thừa kế, người cài đặt hiểu rõ sự phức tạp.

@teracom22 Vấn đề nằm ở chỗ helmet của Home có được tải về và run trước nên nhận Home làm chuẩn. Cách giải quyết là điểu chỉnh lazy load phù hợp để chỉ tải và chạy helmet của About.

làm blog bằng nó cần nhiều models 0

@phatlt.unit @PhongPhamdt đúng rùi ạ, cái này mình chưa đọc kỹ. Thanks mọi người nhiều, phần phía sau có vấn đề gì không mọi người nhỉ????

Dùng PUT hay PATH trong trường hợp chúng ta chỉ định những trường nào trong DB được Update thì nó cũng ko có ý nghĩa. Nhưng trong trường hợp để chỉ định phương thức nào cho phân quyền User hoặc thể hiện chuẩn của Restful thì nó mới có ý nghĩa.

Ông không tin vào tài liệu đấy thì tôi với ông trao đổi với nhau bằng tài liệu official của GoF
Design patterns Elements of Reusable Object-Oriented Software

1. Họ (families) trong abstract factory

Diagram trên có 2 họ: Motif và PM
Có 2 class cha là Window và Scrollbar

Motif Window và Motif Scrollbar hoàn toàn khác nhau, nhưng chung 1 họ là Motif
Tương tự PM Window và PM Scrollbar hoàn toàn khác nhau nhưng chung 1 họ là PM

Như vậy mối quan hệ giữa các class con chung 1 class cha không được gọi là họ, các class khác nhau nhưng có liên quan đến nhau mới được gọi là họ.
Mục đích của abstract fatory là giải quyết vấn đề này.

Intent của abstract factory

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Trích từ Design patterns Elements of Reusable Object-Oriented Software - GoF

Intent của factory method

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Trích từ Design patterns Elements of Reusable Object-Oriented Software - GoF

Rõ ràng các ví dụ trên không liên quan đến một họ nào cả, mà chỉ tập trụng vào việc client không cần biết instance của class con nào được tạo, nhiệm vụ của nó là tương tác với các method của class cha cung cấp.\

Scope của Factory method: các subclass
Scope của Abstract factory: các families của các class

2. Biến thể

Như đã trình bày ở trên, diagram này là diagram tổng quát, các biến thể khác có thể tồn tại, chỉ cần nó đáp ứng được ý đồ của pattern gốc đưa ra. Các ví dụ khác hoàn toàn đáp ứng được điều này

3. Về tác giả

Alexander Shvets là tác giả của 5 cuốn sách chuyên về design pattern và best practices. Các ví dụ trên được trích từ cuốn sách Dive Into Design Patterns xuất bản lần đầu 2018, được tái bản và dịch ra nhiều ngôn ngữ khác ngoài tiếng Anh như tiếng Nhật, tiếng Trung.

Nói về độ tin cậy thì tôi đánh giá tác giả uy tín hơn ông bạn rồi. Ông có tin không nếu cuốn sách có sai sót mà vẫn tái bản nhiều lần và được rate 4.7 sao trên goods read?

Tôi cũng là subcriber của ông một thời gian rồi, đọc các bài viết của ông thấy ông có hiểu biết rất sâu về những mảng này. Nhưng lần này có thể ông có nhầm lẫn gì rồi

Một bài khá hay về System of difference constraints https://atcoder.jp/contests/agc056/tasks/agc056_c

Bài flow fast ví dụ 2 thuật toán không đúng lắm, tác giả xem lại. Nói chung bài viết nói cũng rõ vài thứ cơ bản thôi. Góp ý thêm với tác giả, thuật toán quan trọng nhất là chứng minh. Tác giả nên chứng minh nó đúng rồi code. Thường mình dùng chứng minh phản chứng hoặc trao đổi (exchange argument) giống CF. Cảm ơn tác giả

@Tafi Điểm khác biệt của Factory Method và Abstract Factory là consumer sẽ viết đoạn code khởi tạo của Factory Method, còn Abstract Factory thì không, tức là người thiết kế để lại việc implement factory cho người sử dụng. Các factory này thường ở trong một ngữ cảnh cụ thể, hẹp hơn so với Abstract Factory (nhiệm vụ rõ ràng dễ hiểu hơn - để tạo instance của một họ class, mang tính tiện ích).

Các ví dụ trên không phải đều trả về các instance của một họ hay sao?

Tôi không thông thuộc về Java, nhưng với URLStreamHandlerFactory giống như một AbstractFactory hơn là FactoryMethod bởi những lý do sau:

• Trả về một họ instance.
• Ngữ cảnh dùng không có định. Khi nào consumer cần một streamHandler thì gọi Factory, có bản là có thể gọi bất cứ đâu.
• Class chỉ có một method Factory, chỉ có nhiệm vụ làm Factory.

Đối với Calendar hay NumberFormat, các method để làm việc factory lại là static, có nghĩa không phải để thừa kế, như thế là sai rõ ràng so với biểu đồ. Các method getInstance này là AbstractFactory.

Các Factory Method thường là một abstract method trong class cha và được class con override lại, tức là class cha để việc khởi tạo một instance nào đó cho class con. Một ví dụ:

public class ReportTemplate
{
  public string Render()
  {
    var components = GetComponents();

    return ParseComponents(components);
  }

  protected virtual Components[] GetComponents();
}

public class AccountBalanceReportTemplate : ReportTemplate
{
  protected overrides Components[] GetComponents()
  {
    yield return new HeaderComponent();

    yield return new AccountBalanceSheetComponent();

    yield return new FooterComponent();
  }
}

GetComponents() là một Factory Method mà ReportTemplate ủy quyền cho các dẫn xuất của nó lựa chọn việc khởi tạo các instance của component.

Factory Method cũng có thể implement theo kiểu class bằng cách tạo ra ComponentsFactory và chúng ta implement các loại Factory khác nhau cho từng dẫn xuất của ReportTemplate như là AccountBalanceReportComponentsFactory. Khi đó có thể inject factory vào AccountBalanceReportTemplate bằng constructor, HOẶC VIẾT MỘT ABSTRACT FACTORY để tạo họ instance cho ReportTemplate (ẩn dấu đi sự phức tạp của việc khởi tạo một instance của reportTemplate).

Có thể thấy phạm vi sử dụng của Factory Method là giới hạn và gắn với context cụ thể, trong khi Abstract Factory giống như một tiện ích. ComponentsFactory thì gắn với ReportTemplate, mỗi factory được sử dụng giới hạn trong các template cụ thể. Nhưng một Abstract Factory như là ReportTemplateFactory sẽ được sử dụng ở mọi nơi mà cần đến việc sử dụng một report.

Về trang refactoring.guru, đó cũng chỉ là một trang web do vài lập trình viên lập ra. Nó có sai thì cũng không có gì lạ. Bạn có thể tham khảo nhiều nguồn hơn để hiểu rõ về Factory Method cũng như Abstract Factory.

T cũng thấy cấn cấn đoạn này.

chuẩn