Один пользовательский интерфейс для двух бизнес-объектов

Question

У меня есть экран редактирования правки и цитаты, которые очень похожи. Я хочу попытаться избежать таких кодов:

if (order is Order) 
    SetupScreenForOrder(); 
if (order is Quote) 
    SetupScreenForQuote(); 

Но сохранение двух экранов тоже не очень хорошо. Если я создаю некоторый общий интерфейс между цитатой и порядком, то как вы справляетесь с такими полями, как OrderNumber или QuoteDate?

Каков наилучший способ справиться с этим?

Answer 1

Я думаю, что общий интерфейс между этими двумя объектами будет хорошей идеей.

Возможно, определите необычные поля как nullable и проверите проверку экрана на нуль и определите, как отображать эти поля.

int? OrderNumber {get;set;} 

DateTime? QuoteDate {get;set;} 

EDIT: В ответ на комментарий JC в

Возможно рассмотреть попытку взять его на шаг дальше и, по крайней мере, логически, рассмотрим порядок и Quote быть такой же объект, но на разных этапах в «Жизненный цикл заказа». То есть «Цитата» - это заказ в начале жизненного цикла, тогда как «Заказ» - это заказ в середине или конце жизненного цикла.

У вас может быть свойство OrderState, определенное на вашем интерфейсе, и тогда ваш пользовательский интерфейс может использовать свойство OrderState, чтобы решить, как должен отображаться котировка/порядок, а не проверять каждую часть данных отдельно.

Если вы считаете, что проблема в том, что у вас слишком много утверждений в вашем пользовательском интерфейсе, то, возможно, подумайте о создании небольших пользовательских элементов управления, чтобы обрабатывать отображение кусков пользовательского интерфейса для цитаты или для заказа. Затем вы можете динамически добавить соответствующий элемент управления (элемент управления цитатой или контроль заказа) в пользовательский интерфейс или добавить оба элемента управления и просто показать/скрыть их соответствующим образом. Я бы предупредил, однако, что это звучит так, будто это может быть грязный подход, поэтому будьте осторожны, чтобы решение не оказалось более сложным, чем проблема, которую вы пытаетесь решить.

Answer 2

Foo foo = GetFoo(); 
if (foo is Order) 
    ... 
if (foo is Quote) 
    ... 

Если вы не хотите, чтобы написать эти условными, избежать ссылок на заказ экземпляры и экземпляры Quote их общего родительского типа (если таковые имеются).

Order order = GetOrder() 
SetupScreen(order); // resolves to void SetupScreen(Order order) 

Quote quote = GetQuote() 
SetupScreen(quote); //resolves to void SetupScreen(Quote quote) 

Answer 3

Часто, если дисплей экраны для двух классов похожи, это потому, что у них есть поля, которые похожи на функции, даже если они не имеют такое же имя.

Например, может случиться так, что каждый экземпляр (заказа или цитаты) будет иметь с ним дату. Таким образом, вы могли бы иметь интерфейс:

interface displayableInOrderAndQuoteList { 
    Date getDisplayDate(); 
} 

public class Order { 
    private Date orderDate; 

    public Date getOrderDate() { //used only when treating object as an order 
     return orderDate; 
    } 

    public Date getDisplayDate() {//used when displaying object via interface 
     return orderDate; 
    } 
} 


public class Quote { 
    private Date quoteDate; 

    public Date getQuoteDate() { //used only when treating object as a quote 
     return quoteDate; 
    } 

    public Date getDisplayDate() {//used when displaying object via interface 
     return quoteDate; 
    } 
} 

Другими словами, интерфейс представляет вопросы, которые вы хотите задать объект для того, чтобы построить экран. Каждый объект решает, как ответить на эти вопросы.

Если дисплей отличается от того, что вам нужно задать объектам совершенно разные вопросы, у вас, вероятно, должно быть два экрана.