CODEWITHSUNDEEP
c#design-patterns
Tony The Lion
Tony The Lion

Reputation: 63190

class design question

Suppose I have two classes 

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

}

For every one object of A, there is a related object B.

Now I want to do some operations on data from class A & B, is it better to create a new class or do the operations in Class A or in the collections class?

EDIT:

I need to use data from Class A and use it with data of Class B to create an end result. The data is seperate, so I don't want to merge them in one Class. That wouldn't make sense.

Mostly string operations, as data is string data.

What is the best design practice for this? If there is one?

Upvotes: 0

Views: 189

Answers (5)

user366312
user366312

Reputation: 16884

Although I am not clear about the aim of your question, you can do things like this:

One-to-many relationship

A company can have only one country of origin. But a country can have many companies.

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() {} 
}

Master-Detail relationship

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){}
}

Upvotes: 1

jball
jball

Reputation: 25014

Wouldn't it be simpler to include the list in object B?

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

Then you would do the operations in class B.

Edit:

Based on your comments above, you should do the operations in class A, as it always contains the reference to the object B that it will use in conjunction with it's own state to generate whatever output you need it to.

Upvotes: 2

JonH
JonH

Reputation: 33141

If you did what you mentioned in your edit then your classes would suffer as they would become too tightly coupled. A shouldn't become too intimate with B, but a good idea might be to seperate the class into another class that can handle both instances of A and B.

For example assume the following:

Issue->Action Item

Classic example of one to many...

You could do this:

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

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

But then an Issue might have to know too much about an Action Item.

It might be best to introduce an intermediate:

class IssueActionItems
{
//define props / methods
Issue i;
List<ActionItems> l;
}

Upvotes: 1

Chris Arnold
Chris Arnold

Reputation: 5753

I would create a separate classic ala the Service model in DDD. You would then pass your A and B objects to the service class and it would do work on them.

Upvotes: 0

cyborg
cyborg

Reputation: 5748

Well it looks like you're forming a composited structure where B is a helper for A, so A should be the primary point of interaction for other objects.

Upvotes: 1

Related Questions