The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I created the Song object separate from a ChartEntry because I figured a Song doesn't need to know what were using it for, so it wouldn't hold it current chart position for example. I could also quite easily reuse the Song object to search for a matching Youtube video..... does that sound correct?

The interaction between ChartEntry and Song seems a little, well, lame. It merely adds information relating to position then wraps the Song object methods, is this the way composition should work?

By passing an object to another object I am adding dependency, what would happen if I renamed the methods in Song? How would I handle this because ChartEntry would then go pop! Or is this why I added ChartEntry as an intermediate layer between Song and MusicChart, so code changes wouldn't cascade to other objects?

When building the MusicChart object, It just seems a little messy to me, what about you?

Each object to me, just seems to be a container for data, or a glorified Array. It's probably just because this implementation is so basic, isn't it?

I feel I'm starting to understand elements of OO, and I'm assuming I'm going the right way about it, I just fear I'm doing it blindly...

I'd get rid of the ChartEntry class. Just store the entry info directly in the MusicChart class. And you're right that these classes seem like glorified arrays, but you'll undoubtedly move more behavior into them as time goes on. For starters, you can get the report building in there.

A couple things, though these are person preferences more than anything else.

Use protected for class' member variables and functions rather than private. The protected label will facilitate future inheritance chains.

By passing an object to another object I am adding dependency, what would happen if I renamed the methods in Song? How would I handle this because ChartEntry would then go pop! Or is this why I added ChartEntry as an intermediate layer between Song and MusicChart, so code changes wouldn't cascade to other objects?

Program to interfaces rather than to a class whenever permissible. On small projects this over complicates things, but as a project grows, it's an effective time saving tool.

Each object to me, just seems to be a container for data, or a glorified Array. It's probably just because this implementation is so basic, isn't it?

Use variables rather than arrays. It's cleaner and promotes code readability.

Objects and arrays share similarities and many times both can be used interchangeably. The benefit of an object over an array is that you have the ability to apply methods which may or may not be beneficial. I was reared in C++, so I tend to use classes as I would a Struct in C++.

In this case I think it would be best to use properties rather then a array of values. It doesn't seem as if your adding properties at run time so there isn't much of a point to using a array rather then defining distinct properties of the class.

imaginethis wrote

Use protected for class' member variables and functions rather than private. The protected label will facilitate future inheritance chains.

Perhaps extending classes should not inherit direct access to this property.

This essentially describes the same data structure, but is not a glorified array which makes it more concrete and easier to read.

Perhaps extending classes should not inherit direct access to this property.

One view on this (to which I ascribe), is that if you have this requirement, then it's a very sure sign that you are really dealing with two separate entities, clumped together in the same class. Split them into two classes and replace the inheritance with composition.