5

Here's something I keep struggling to figure out the best solution to. I've had this problem while working with PHP and Java so it's a fundamental understanding of OOP issue. Examples are in PHP.

Let's say I have a few object's here. Song, Artist, ArtistProfile, User.

So in some instances I want the ArtistProfile and an array of User objects (subscribers) when I call the Artist (e.g. the artist's profile page), in other instances I only want the Artist info, like when viewing a page of the song.

Should I be nesting one object as part of another or should I be creating more specific objects for different usages.

Option 1: Nested

Class Song {
   private $songId;
   private $songName;
   private $year;
   private $Artist; //Artist object
}

Class Artist {
   private $artistId;
   private $name;
   private $age;
   private $subscriberArr; //Array of User objects which then have more nested objects such as a Role object, Profile object
   private $profile; //Profile object which could also have more nested objects
}

Class User {
   private $userId;
   private $name;
   private $age;
   private $role; //Role object
   private $profile; //UserProfile object
}

Option 2: Build more objects

Class Song {
   private $songId;
   private $songName;
   private $year;
   private $artistId;
}

Class Artist {
   private $artistId;
   private $age;
   private $name;
}

Class User {
   private $userId;
   private $name;
   private $age;
   private $roleId;
}

Class SongWithArtist {
   private $song; //Basic Song object
   private $artist; //Basic Artist object
}

Class ArtistWithProfile {
   private $artist; //Basic artist object
   private $profile; //Profile object
   private $subscriberArr; //UserDisplay object containing basic User object
}

 Class UserWithProfile {}

Option 1 means wasting a lot of time/resources grabbing information I may not need for that page but easier to manage. Option 2 is messy and requires keeping track of which object is what but faster and far less db calls. Which is the 'correct' option and/or is there a 3rd correct option?

user103555
  • 51
  • 1
  • 2
  • I think the keyword you are looking for is "aggregation". Your Option 1 seems to define an aggregate with Song being the aggregate root. Option 2 has no aggregation. – COME FROM Sep 30 '13 at 07:15
  • @COME, I was thinking of the word: "composition", but I looked up "aggregation" and found out that they aren't exactly the same thing: https://en.wikipedia.org/wiki/Object_composition#Aggregation See also "containment". – Kaydell Sep 30 '13 at 12:37
  • @Kaydell: In this case we are talking about aggregation rather than composition, I think. A User or an Artist shouldn't probably be removed when a Song is removed from the DB. There's a lot of material out there about choosing aggregates when modelling, so I thought that the keyword could help finding answers. – COME FROM Sep 30 '13 at 12:54
  • @COME, I meant to say that I learned something from your answer. – Kaydell Sep 30 '13 at 13:40

2 Answers2

3

Should I be nesting one object as part of another or should I be creating more specific objects for different usages.

  1. Follow OO principles first which means "more specific objects." In doing so your classes may "line up" with your database schema or not but do not let DB schema trump good OO design.

  2. Single Responsibility Principle will help guide you in what classes to build. SRP means, for example, that a Song is a song. It is not an artist, it is not a list of subscribers, so it should not have artist or subscriber stuff in it. Only song stuff.

  3. The above means that you will have lots of small, independent, fully functional things - classes. By "fully functional" I mean, if a Song is a name, date, and id then that's what's in it. period. The fact that a certain artist sings that song does not inherently, fundamentally define what a Song is. This means other classes to model relationships like "an artist's song repertoire" for example.

  4. Small functional classes leads to good DAO's and flexibility for your user interface.

Option 1 means wasting a lot of time/resources grabbing information I may not need for that page but easier to manage. Option 2 is messy and requires keeping track of which object is what but faster and far less db calls

  1. You are falling victim to premature optimization. How can you know up front that option 2 will have "fewer DB calls?" What does that mean anyway?

  2. This is simply the wrong way to think about your domain classes/model. This is why you end up duplicating your DB schema:

.

Class SongWithArtist {
  private $song; //Basic Song object
  private $artist; //Basic Artist object
}

When what you should have is something describing the real world:

Class ArtistPortfolio {
    private Artist $theArtist;
    private List<Song> $portfolio;  // list of songs (s)he sings 
}

Class ArtistSubscribers {
    private Artist $theArtist;
    private List<User> $subscribers;  // list of people who like this artist
}

// And it would probably make sense to combine the above 2 classes:

Class ArtistProfile {
    // an Artist object, not just an id. We're doing OBJECT oriented programming.
    private Artist $theArtist;

    private List<Song> $portfolio;  // list of Song objects 
    private List<User> $subscribers; // list of User objects
}

// and if you need a list of profiles...
Class ArtistProfiles {
    private List<ArtistProfile> $profiles; // a list of type ArtistProfile

    public ArtistProfile GetProfileByArtist (Artist thisArtist){}
    public ArtistProfile GetProfileByName (string name) {}
    public ArtistProfile GetProfileById (string id) {}
}

// I'd say a ArtistProfile could be part of an Artist..

Class Artist {
    private $id;
    private $name;
    private ArtistProfile $profile; // this is composition.
}


//In lieu of the above, an DAO oriented Artist composition ...
// Just go with the refactoring flow!
Class Profile {
    private $id;
    private $name;
    private $birthdate
}

 Class Repertoire {
    // a Profile object, not just an id. We're doing OBJECT oriented programming.
    private Profile $theArtist;

    private List<Song> $portfolio;  // list of Song objects 
    private List<User> $subscribers; // list of User objects
}

Class Artist {
    private Profile $me;
    private Repertoire $myStuff; 
}

Too Many DB Calls!

NOT. You can instantiate a Artist object without populating the $myStuff and in turn, defer populating $subscribers / portfolio lists until needed. This is called lazy loading.

radarbob
  • 5,808
  • 18
  • 31
1

I believe that what you want to do when programming in general is to avoid duplicating data.

When designing a relational database, there are 4 types of relationships:

  • one-to-one
  • one-to-many
  • many-to-one
  • many-to-many

For a many-to-many relationship, you have a "link table" in a database where usually just has the two IDs of the two records being linked to each other.

In addition to the two linked record IDs, a link table can have any other data associated between the two database tables with the many-to-many link table.

For example,

class DBRecord {
    private $recordID; // a BIGINT, auto-incrementing field, the primary key
}

class Product extends DBRecord {
    private $productID; // an ID that the user can set
    private $productName;
    private $suggestedRetail;
    ...
}

class Vendor extends DBRecord {
   private $vendorID; // an ID that the user can set
   private $vendorName;
   private $contactID;
   ...
}

class ProductVendors extends DBRecord {
   private $productRecordID; // this ID never changes
   private $vendorRecordID;  // this ID never changes
   private $wholesaleCost;   // the cost of a product can be different by vendor
}

In this example, objects of the classes: Product, Vendor, and ProductVenders are much like the records that are in the database. You could possibly read an entire database table into an array.

$products = readAll();
$vendors = readAll();
$productVendors = readAll();

Depending upon the size of your dataset in the number of records, you may not want to read them all into RAM.

When you have too many records to read them all into RAM, you can setup your relations between your objects to mirror the relations between your database tables in your relational database:

// database code is encapsulated in this class
class DB {
   ...
}

// this class implements functionality common to all subclasses
abstract class DBTable {
   private $db;
   private $internalName; // the SQL name for this database table
   private $displayName;  // the name that the user sees for this db table
   public lookup($productID) {
       ...
   }
}

class Products extends DBTable {
   ...
}

class Vendors extends DBTable {
    ...
}

class ProductVendors extends DBTable {
   ...
}

That's how I've done many-to-many relationships, and it works even for very large datasets such as maybe having 100,000 product record.

  • One-to-many and many-to-one are just the flip-side of each other

    class PurchaseOrderLineItem extends DBRecord {
    }
    
    class PurchaseOrder extends DBRecord {
        private $lineItems;
        public loadLineItems() {
           ...
        }
        public saveLineItems() {
           ...
        }
    }
    

A line-item of a purchase order can only be on one purchase order document, but a purchase order document can have many line items on it. This generally isn't a huge number of line-items, so I just load them all into RAM, into an array.

  • One-to-one relationships

    class Product extends DBRecord {
        private $itemRecordID;
        private $inventoryOnHand;
        ...
    }
    
    class InventoryCount extends DBRecord {
        private $itemRecordID;
        private $inventoryCounted;
    }
    

These two records are a one-to-one relationship. When counting all of the inventory in a store, for each product there is only one count, and for each count, there is only one product.

So, those are the four types of relationships. I think that the most general solution is to mirror your relational database, but I don't always do that such as in the case of purchase orders which "contain" their line-items.

Watch out for multi-user problems The famous lost-update problem.

Don't duplicate data See "Normal forms".

Store date-of-birth -- not age Generally it's best to not store an age, but a date-of-birth and have an accessor called "getAge()" to calculate and return an age.

gnat
  • 21,442
  • 29
  • 112
  • 288
Kaydell
  • 139
  • 6