Có một chiến lược thiết kế cụ thể nào có thể được áp dụng để giải quyết hầu hết các vấn đề về trứng và trứng trong khi sử dụng các vật thể bất biến?

Đến từ nền tảng OOP (Java), tôi đang tự học Scala. Mặc dù tôi có thể dễ dàng nhìn thấy những lợi thế của việc sử dụng các đối tượng bất biến riêng lẻ, tôi gặp khó khăn khi xem cách người ta có thể thiết kế toàn bộ ứng dụng như thế. Tôi sẽ đưa ra một ví dụ:

Giả sử tôi có các vật thể đại diện cho "vật liệu" và thuộc tính của chúng (Tôi đang thiết kế một trò chơi, vì vậy tôi thực sự có vấn đề đó), như nước và băng. Tôi sẽ có một "người quản lý" sở hữu tất cả các trường hợp vật liệu như vậy. Một đặc tính sẽ là điểm đóng băng và nóng chảy, và những gì vật liệu đóng băng hoặc tan chảy.

[EDIT] Tất cả các cá thể vật chất là "singleton", giống như một Enum Java.

Tôi muốn "nước" nói rằng nó đóng băng thành "băng" ở 0C và "băng" để nói rằng nó tan chảy thành "nước" ở 1C. Nhưng nếu nước và băng là bất biến, chúng không thể lấy tham chiếu cho nhau dưới dạng tham số của hàm tạo, bởi vì một trong số chúng phải được tạo trước và không thể tham chiếu đến tham số khác chưa có trong tham số của hàm tạo. Tôi có thể giải quyết điều này bằng cách cung cấp cho họ cả tài liệu tham khảo cho người quản lý để họ có thể truy vấn nó để tìm phiên bản vật liệu khác mà họ cần mỗi khi họ được yêu cầu về các đặc tính đóng băng / tan chảy của họ, nhưng sau đó tôi gặp vấn đề tương tự giữa người quản lý và các tài liệu, rằng chúng cần một tài liệu tham khảo cho nhau, nhưng nó chỉ có thể được cung cấp trong hàm tạo cho một trong số chúng, vì vậy người quản lý hoặc tài liệu không thể thay đổi được.

Là họ không có cách nào xung quanh vấn đề này, hay tôi cần sử dụng các kỹ thuật lập trình "chức năng", hoặc một số mô hình khác để giải quyết nó?

Giải pháp là gian lận một chút. Đặc biệt:

• Tạo A, nhưng để lại tham chiếu đến B chưa được khởi tạo (vì B chưa tồn tại).

• Tạo B và chỉ ra A.

• Cập nhật A để trỏ đến B. Không cập nhật A hoặc B sau này.

Điều này có thể được thực hiện rõ ràng (ví dụ trong C ++):

struct List {
    int n;
    List *next;

    List(int n, List *next)
        : n(n), next(next);
};

// Return a list containing [0,1,0,1,...].
List *binary(void)
{
    List *a = new List(0, NULL);
    List *b = new List(1, a);
    a->next = b; // Evil, but necessary.
    return a;
}

hoặc ngầm (ví dụ trong Haskell):

binary :: [Int]
binary = a where
    a = 0 : b
    b = 1 : a

Ví dụ Haskell sử dụng đánh giá lười biếng để đạt được ảo tưởng về các giá trị bất biến phụ thuộc lẫn nhau. Các giá trị bắt đầu là:

a = 0 : <thunk>
b = 1 : a

avà blà cả hai hình thức bình thường đầu hợp lệ độc lập. Mỗi khuyết điểm có thể được xây dựng mà không cần giá trị cuối cùng của biến khác. Khi thunk được ước tính, sau đó nó sẽ trỏ đến cùng một bđiểm dữ liệu .

Do đó, nếu bạn muốn hai giá trị bất biến trỏ đến nhau, bạn phải cập nhật giá trị thứ nhất sau khi xây dựng giá trị thứ hai hoặc sử dụng cơ chế cấp cao hơn để thực hiện tương tự.

Trong ví dụ cụ thể của bạn, tôi có thể diễn đạt nó bằng Haskell như:

data Material = Water {temperature :: Double}
              | Ice   {temperature :: Double}

setTemperature :: Double -> Material -> Material
setTemperature newTemp (Water _) | newTemp <= 0.0 = Ice newTemp
                                 | otherwise      = Water newTemp
setTemperature newTemp (Ice _)   | newTemp >= 1.0 = Water newTemp
                                 | otherwise      = Ice newTemp

Tuy nhiên, tôi đang đẩy mạnh vấn đề. Tôi tưởng tượng rằng trong một cách tiếp cận hướng đối tượng, trong đó một setTemperaturephương thức được gắn vào kết quả của mỗi hàm Materialtạo, bạn sẽ phải có các hàm tạo trỏ vào nhau. Nếu các hàm tạo được coi là giá trị bất biến, bạn có thể sử dụng cách tiếp cận được nêu ở trên.

Trong ví dụ của bạn, bạn đang áp dụng một phép biến đổi cho một đối tượng nên tôi sẽ sử dụng một cái gì đó giống như một ApplyTransform()phương thức trả về một BlockBasethay vì cố gắng thay đổi đối tượng hiện tại.

Ví dụ: để thay đổi IceBlock thành WaterBlock bằng cách áp dụng một chút nhiệt, tôi sẽ gọi một cái gì đó như

BlockBase currentBlock = new IceBlock();
currentBlock = currentBlock.ApplyTemperature(1); 
// currentBlock is now a WaterBlock 

và IceBlock.ApplyTemperature()phương thức sẽ trông giống như thế này:

public class IceBlock() : BlockBase
{
    public BlockBase ApplyTemperature(int temp)
    {
        return (temp > 0 ? new WaterBlock((BlockBase)this) : this);
    }
}

Một cách khác để phá vỡ chu trình là tách các mối quan tâm về vật chất và biến đổi, trong một số ngôn ngữ tạo thành:

water = new Block("water");
ice = new Block("ice");

transitions = new Transitions([
    new transitions.temperature.Below(0.0, water, ice),
    new transitions.temperature.Above(0.0, ice, water),
]);

Nếu bạn sẽ sử dụng một ngôn ngữ chức năng và bạn muốn nhận ra lợi ích của sự bất biến, thì bạn nên tiếp cận vấn đề với suy nghĩ đó. Bạn đang cố gắng xác định loại đối tượng "băng" hoặc "nước" có thể hỗ trợ một phạm vi nhiệt độ - để hỗ trợ tính không thay đổi, sau đó bạn cần tạo một đối tượng mới mỗi khi nhiệt độ thay đổi, gây lãng phí. Vì vậy, cố gắng làm cho các khái niệm về loại khối và nhiệt độ độc lập hơn. Tôi không biết Scala (nó nằm trong danh sách cần học của tôi :-)), nhưng mượn từ Joey Adams Trả lời bằng Haskell , tôi đề xuất một cái gì đó như:

data Material = Water | Ice

blockForTemperature :: Double -> Material
blockForTemperature x = 
  if x < 0 then Ice else Water

hoặc có thể:

transitionForTemperature :: Material -> Double -> Material
transitionForTemperature oldMaterial newTemp = 
  case (oldMaterial, newTemp) of
    (Ice, _) | newTemp > 0 -> Water
    (Water, _) | newTemp <= 0 -> Ice

(Lưu ý: Tôi chưa thử chạy cái này và Haskell của tôi hơi rỉ sét.) Bây giờ, logic chuyển đổi được tách ra khỏi loại vật liệu, vì vậy nó không lãng phí nhiều bộ nhớ và (theo ý kiến ​​của tôi) nó khá một chút chức năng định hướng.