2013-12-12 20 views
8

Vì vậy, tôi đang viết một trò chơi và tôi đã đi qua một câu hỏi hóc búa nơi tôi tin rằng Reflection có thể là một giải pháp tốt hơn. Nhưng biết rằng Reflection không được khuyến khích và giải pháp khác của tôi trông không đẹp, tôi nghĩ tôi sẽ hỏi ở đây và xem cái gì thực sự là ý tưởng hay hơn trong kịch bản này.Tôi có thể làm điều đó đơn giản hơn nhiều với Reflection. Tôi có nên không?

Về cơ bản tôi có một lớp thẻ trừu tượng và sẽ có một số triển khai của nó. Tôi có một trường hợp mà tôi được cho một tên thẻ và cần phải xây dựng một đối tượng của nó, chỉ cần đưa ra tên.

Tôi biết tôi có thể sử dụng một trong hai cách:

a) Phản ánh và sử dụng choName và gọi. Nó sẽ là mã rất ngắn, có quy mô tốt và đủ dễ viết. Điều đó nói rằng, đó là Reflection, và tôi là tất cả để tránh nó khi tôi không đặc biệt cần nó.

b) Sử dụng mẫu thiết kế của Nhà máy và sau đó có kiểm tra có điều kiện khổng lồ, gọi cho lớp thích hợp dựa trên tên tôi cung cấp. Nó không khó để viết nhưng yêu cầu bảo trì liên tục và sẽ mất một thời gian để viết, cộng với nó sẽ không quy mô tốt. Điều đó nói rằng, đó là một giải pháp không phản chiếu.

Vậy giải pháp lý tưởng là gì? Tôi chỉ sử dụng Reflection vì nó giữ mã của tôi đẹp và ngắn?

+0

Phản ánh! Phản ánh! Phản ánh! –

+1

Sở thích cá nhân là "B". Nó thường là lựa chọn an toàn hơn và cho phép giải pháp có thể cấu hình (bạn có thể tải một 'Bản đồ' của các tên từ một tệp tương ứng với lớp cần được khởi tạo ví dụ). Bất cứ lúc nào bạn nghĩ phản ánh là câu trả lời đúng, bạn có vấn đề với thiết kế của mình. Tôi nói điều này khi tôi sử dụng sự phản chiếu ở một vài nơi và luôn tìm cách để giảm bớt nó ... 'Class.forName' không nhất thiết phải phản ánh;) – MadProgrammer

+0

Tại sao không sử dụng mẫu thiết kế Nhà máy, và bắt đầu với phản xạ của bạn thực hiện. Bản thân tôi có thể xem xét một thiết kế dựa trên một [Prototype] (http://en.wikipedia.org/wiki/Prototype_pattern) bản thân mình (kể từ khi một boong có một số lượng hạn chế của thẻ/phù hợp). –

Trả lời

1

Tôi sẽ đề nghị sử dụng một mẫu nhà máy và sử dụng một nhà máy dựng sẵn như Spring mà bạn có thể sử dụng để xác định các cá thể đậu có thay vì sau đó thực hiện nhà máy riêng của bạn. Nó sẽ mở rộng dễ dàng hơn vì bạn chỉ có thể định nghĩa các kiểu bean khác trong XML hoặc mã Java có chú giải. Chỉ cần chắc chắn rằng bạn sử dụng đậu non-singleton và mỗi khi bạn hỏi nhà máy mùa xuân của bạn cho một bean của một tên nó sẽ gọi constructor đúng. Nó thậm chí sẽ cho phép bạn làm tiêm phụ thuộc cùng một lúc miễn phí.

+0

Tôi nghĩ rằng một BeanFactory là nhiều hơn một chút so với tôi cần. Tôi đã biết những gì tôi cần các đối tượng này và đã biết làm thế nào tôi muốn xử lý chúng trong thời gian chúng được khởi tạo. Tôi chỉ biết mô hình thiết kế nhà máy có lẽ là một ý tưởng tốt để thực hiện vì nó gần như theo định nghĩa những gì tôi muốn làm. –

2

Đây là giải pháp thay thế (không chắc đó có phải là "giải pháp lý tưởng" như bạn đã đề cập hay không, nhưng tôi nghĩ nó đáng xem xét): các loại được liệt kê. Nó vẫn sẽ là một danh sách rất lớn, nhưng có lẽ một chút sạch hơn? Và bạn phải định nghĩa tất cả chúng ở đâu đó.

Một ví dụ về những gì tôi có nghĩa là:

enum CardType { 
    CARD_ONE(new Card(arg0, arg1, arg2, ..., argN)), 
    CARD_TWO(new Card(arg0, arg1, arg2, ..., argN)), 

    ... 

    CARD_N(new Card(arg0, arg1, arg2, ..., argN)); 

    private final Card card; 

    private CardType(Card card) { 
    this.card = card; 
    } 

    public Card getCard() { 
    return card; 
    } 
} 

Sau đó, khi bạn cần để có được một tên, chỉ cần làm:

public Card getCardByName(String cardName) { 
    return CardType.valueOf(cardName).getCard(); 
} 

này giả định các thẻ đang độc thân, nhưng bạn có thể cũng giống như dễ dàng làm cho phương pháp getCard làm một số loại logic nhà máy để tạo ra một cái mới.

+0

Điều này dường như không tốt hơn bất cứ điều gì tôi đã gợi ý, và chúng không phải là singleton, chắc chắn là không. –

Các vấn đề liên quan