The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

OOP Question

Hi,

I have a quick question for you all.
I have a product with the properties name, code and customer-code. The customer-code is only used in the context of a relation between the supplier of the product and the customer of the product.
What would be the best way to do this.

public class Product
{
    public string Name
    {
        get
        {
            return _name;
        }

        set
        {
            _name = value;
        }
    }

    public string CustomerCode
    {
        get
        {
            return _customerCode;
        }

        set
        {
            _customerCode = value;
        }
    }
}

Or

public class ProductDefinition
{
    public string Name
    {
        get
        {
            return _name;
        }

        set
        {
            _name = value;
        }
    }
}

public class Product
{
    public ProductDefinition ProductDefinition
    {
        get
        {
            return _productDefinition;
        }

        set
        {
            _productDefinition = value;
        }

    }

    public string CustomerCode
    {
        get
        {
            return _customerCode;
        }

        set
        {
            _customerCode = value;
        }
    }
}

Or

public class Product : ProductDefinition
{
    public long ProductDefinitionID
    {
        get
        {
            return _productDefinitionID;
        }

        set
        {
            _productDefinitionID = value;
        }

    }

    public string CustomerCode
    {
        get
        {
            return _customerCode;
        }

        set
        {
            _customerCode = value;
        }
    }
}

Thanks,

/eelco
eelco
Sunday, February 27, 2005
 
 
It looks to me that you have should have three objects. The product (name and code), the customer (you never say how you identify a customer?), and an aggregate with the Product, Customer, and Customer code. I don't see that in any of your examples.

But this whole thing looks like you're designing objects to fit a relational database schema to me (which is a religious war for another day).
Anony Coward
Sunday, February 27, 2005
 
 
If anyone else wants to consider this question, I've reformatted the code so that it's actually readable:

public class Product {

    public string Name {
        get { return _name; }
        set { _name = value; }
    }

    public string CustomerCode {
        get { return _customerCode; }
        set { _customerCode = value; }
    }
}

Or

public class ProductDefinition {

    public string Name {
        get { return _name; }
        set { _name = value; }
    }
}

public class Product
{
    public ProductDefinition ProductDefinition {
        get { return _productDefinition; }
        set { _productDefinition = value; }
    }

    public string CustomerCode {
        get { return _customerCode; }
        set { _customerCode = value; }
    }
}

Or

public class Product: ProductDefinition {

    public long ProductDefinitionID {
        get { return _productDefinitionID; }
        set { _productDefinitionID = value; }
    }

    public string CustomerCode {
        get { return _customerCode; }
        set { _customerCode = value; }
    }
}
Chris Nahr Send private email
Sunday, February 27, 2005
 
 
In addition you might want to create a struct from your product identifiers. This way you can always be sure that your product ids are formatted correctly. The struct itself might just capsulate a string with proper accessors.
Samuel
Monday, February 28, 2005
 
 
Your class names are somewhat misleading. Here's my take:

Product {
 get/setName() {...}
 add/removeCustomer(Customer customer) {...}
 List getCustomerList() {...}
}

Customer {
  get/setCode() { ... }
  add/removeProduct(Product product) {...}
  List getProductList() { ... }
}

CustomerProductAssoc {
  Customer getCustomer() {} 
  Product getProduct() {}
}
Dino
Monday, February 28, 2005
 
 
Not entirely sure what you mean here, but if CustomerCode mean "the code that a given customer uses to refer to a particular product" then I would suggest

 class Product {
  getName();
  getID();
 }

 class Customer {
  ...
  class CustomerCodeDB {
    CustomerCode getCustomerCode(Product &product);
  }
 }

CustomerCodeDB doesn't have to be a nested class, you jst have one per customer.
David Clayworth
Monday, February 28, 2005
 
 
I've made a mistake:

Product {
 get/setName() {...}
}

Customer {
  get/setCode() { ... }
}

CustomerProductAssoc {
  Customer getCustomer() {} 
  Product getProduct() {}
  associate(Customer customer, Product product) {...}
  disassociate(Customer customer, Product product) {...}
  List getCustomerList(Product p) {...}
  List getProductList(Customer c) {...}
}

This way Product and Customer are independent while dependencies are resolved in the Association class.
Dino
Monday, February 28, 2005
 
 
If you really expose all your private member to public via getter and setter, it already not OOP...

Try to prevent C struct like class as most as possible, sometime you have to, but most of the time won't

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Carfield Yim Send private email
Tuesday, March 01, 2005
 
 
"My point is that you should not program blindly" is IMO the most important statement in the article.

Now, as far as accessors are concerned ... ummm ... they do hide implementation details since they are themselves messages into the object. Allen's observation that accessors should be eliminated in most cases is correct. But it also applies to all other types of messages; in other words, if there's a way to simplify an interface then do it.

About structures. There's a lot of value in correctly designing the data structures in a program. Poorly structured data requires complex code. In fact, I cannot emphasize enough on how important correct data structuring is!

And since methods in a class are nothing but pointers to functions, getting your data structures right and putting the methods in the right place are equivalent.

We should not underestimate and demolish the structured concepts; instead we should learn to use them properly and apply them correctly.

One more thing: logon is not a use case because does not have an outcome in the problem domain? Really? IMO, businesses care a lot about system security, to the point where security is a business requirement and part of the problem domain. I let you figure out what the outcome of the logon (non)use case is.
Dino
Wednesday, March 02, 2005
 
 
JavaWorld.com... yikes! They have some real quacks out there writing articles about "best practices". Take what you read out there with a grain of salt. Some of that crap is written with blinders on.
matt
Wednesday, March 02, 2005
 
 
To be honest, your question doesn't have a quick answer, and most of the ones I've seen here I don't agree with. It all depends on what the problem domain is, which is where you should be starting, IMO. I recommend Eric Evans' "Domain-Driven Design" to get an idea of the approach.

Or you could read David West's "Object Thinking" to try to get a better idea of what OO *is* (others have differing views, but if you can understand what he saying, you will be in the right ball park, whether you eventually agree with it or not).

Dino's answer is based on the underlying data structures. This is a perfectly valid way of working, but it isn't OOP. Data-centric and object-centric are quite different approaches. If you don't get that yet, try West for some clarification. Once you clearly understand your problem domain, and understand the OO approach, the answer to your question will probably be clear. If it isn't, try some things out, and try to learn from the results. And if the project you're working on seems too simple for this lengthy approach, just get on and code it, and leave OO for another day! HTH.
Dave Hallett Send private email
Wednesday, March 02, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz