вопрос дизайна класса - PullRequest
0 голосов
/ 18 декабря 2009

Предположим, у меня есть два класса

class A 
{
   b bInstance;

   public A ( b newb )
   {
      this.bInstance = newb;
   }

}

class B
{
   // some data and methods go here
}

class List<A> 
{

   // list of A objects also holding reference to a B object

}

Для каждого объекта A существует связанный объект B.

Теперь я хочу сделать некоторые операции с данными из класса A & B, лучше ли создавать новый класс или выполнять операции в классе A или в классе коллекций?

EDIT:

Мне нужно использовать данные из класса A и использовать их с данными класса B для создания конечного результата. Данные раздельные, поэтому я не хочу объединять их в один класс. Это не имеет смысла.

В основном строковые операции, поскольку данные являются строковыми данными.

Какова наилучшая практика проектирования для этого? Если есть один?

Ответы [ 5 ]

2 голосов
/ 18 декабря 2009

Не проще ли включить список в объект B?

class B 
{ 
   List<A> list;
   // some data and methods go here 
} 

Тогда вы будете выполнять операции в классе B.

Edit:

Исходя из ваших комментариев выше, вы должны выполнять операции в классе A, поскольку он всегда содержит ссылку на объект B, который он будет использовать вместе со своим собственным состоянием для генерации любого вывода, в котором он вам нужен.

1 голос
/ 19 декабря 2009

Хотя я не совсем понимаю цель вашего вопроса, вы можете сделать такие вещи:

Отношение один-ко-многим

Компания может иметь только одну страну происхождения. Но в стране может быть много компаний.

public class Country
{
    public int ID{get; set;}
    public string CountryName{get; set;}
    public List<Company> Items{get; set;}

    public int SaveOrUpdate(){}
    public static Country Get(int id){}
    public static List<Country> Get(){}
    public bool Delete(){}
}

public class Company
{
    public int ID {get; set;}
    public string CompanyName{get; set;}
    public int CountryID{get; set;}
    public Country Country{get; set;}

    public int SaveOrUpdate() {}
    public static Company Get(int id) {}
    public static List<Company> Get(){}
    public bool Delete() {} 
}

Отношение Мастер-Деталь

public class Order
{
    public int ID {get;set;}
    public DateTime OrderDate {get;set;}
    public List<OrderDetail> Items {get;set;}

    public int SaveOrUpdate(){}
    public static Order Get(int id){}
    public static List<Order> Get(){}
    public bool Delete(){}
}

public class OrderDetail
{
    public int OrderID{get;set;}
    public string ProductName{get;set;}
    public double Price{get;set;}{get;set;}
    public Order Order {get;}

    public static void Save(TransactionContext tc, int masterID, List<OrderDetail> items){}
    public static void Delete(TransactionContext tc, int masterID){}
    public static List<OrderDetail> Get(TransactionContext tc, int masterID){}
}
1 голос
/ 19 декабря 2009

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

Например, предположим следующее:

Issue->Action Item

Классический пример одного ко многим ...

Вы можете сделать это:

class Issue {
//define issue properties
List<ActionItem> ai;
}

class Action Item {
//define action properties
//methods
}

Но тогда Проблеме, возможно, придется слишком много знать об Предмете Действия.

Лучше всего ввести промежуточное звено:

class IssueActionItems
{
//define props / methods
Issue i;
List<ActionItems> l;
}
1 голос
/ 18 декабря 2009

Похоже, вы формируете составную структуру, где B является помощником для A, поэтому A должна быть основной точкой взаимодействия для других объектов.

0 голосов
/ 18 декабря 2009

Я бы создал отдельную классическую аля Сервис-модель в DDD. Затем вы передадите свои объекты A и B в класс обслуживания, и он будет работать с ними.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...