Associação entre classes

Sim, você está usando uma associação de classes, mais precisamente uma agregação, pois cada produto recebe um fornecedor.

Mas associação, agregação e composição não são coisas distintas? Um outro detalhe, como saberei quando utilizar cada coisa? Pois leio muito coisas do tipo - precisa de experiência para ver onde aplicar certos padrôes e tudo mais, ou seja, preciso errar/apreder errado para saber que pode ser feito certo depois?

Digamos que tenho isso:

class Pato {

 public function grasnar () { }
}

class PatoRei extends Pato {
// herdei aqui, ok !
}

class PatoBorracha extends Pato {
// Não gostaria de herdar coisas que não preciso, mas herdo, afinal pato de borracha não grasna !
}

// e por ai vai
Ai eu pergunto, porque surgem problemas desse tipo logo de cara com a herança que é um dos pilares do OOP?

Desculpe acho que misturei assunto, são muitas dúvidas !

Desculpe, eu confundi, eu quis dizer que você possui um relacionamento entre as classes e não uma associação.

Eu tenho quase certeza que você está usando agregação pelo seguinte motivo, um produto precisa de um fornecedor, porém ele não vai deixar de existir se não houver um fornecedor.

Ja que $fornecedor tem que ser do tipo fornecedor:

public function __construct($Id, $Nome, $Valor,Fornecedor $Fornecedor)

// Não gostaria de herdar coisas que não preciso, mas herdo, afinal pato de borracha não grasna !
Pensando bem, pato de borracha seria uma especialização de brinquedo ou coisa do tipo, e não de animal, veja

Animal

Se você possui essa relação, você precisa sim de um fornecedor para um determinado produto existir.

Veja bem, o MacBook, ele é um produto fornecido pela Apple, se a Apple deixar de existir, então não há mais fornecimento do mesmo.

Mas, se o MacBook deixar de existir, a Apple ainda poderá fornecer outros produtos, ou seja, ela ainda vai existir.

Isso é uma agregação.

Mas Andrey, fornecedor é diferente de fabricante.

Se a Apple deixar de existir o Macbook deixará de existir, mas neste caso a Apple é a fabricante e não o fornecedor.

Bom Leozitho, se a Apple é o fabricante, ela fornece pra alguém, certo ? e alguém fornece pra outro alguém, correto ?

Eu entendi o que você quis dizer, mas o lance é que se pararem de fabricar, alguém vai parar de fornecer.

Num ponto de vista de mercado, o fornecedor X pode deixar de fornecer, e você ainda ter o fornecedor Y e Z fornecendo.

O que eu quis dizer: você não costuma ter N níveis, se destruir o fabricante ou o fornecedor, independente de haver mais, o produto deixará de existir, seja regionalmente ou mundialmente.

No meu entendimento fornecedor é que o fornece o produto, ou seja, uma distribuidora, um revendedor autorizado, e até mesmo a própria Apple (fabricante), por que não?

Mas antes mesmo dele ser fornecido ele já foi fabricado, então já existe.

Se eu tenho um e-commerce por exemplo e para cada produto eu tenho um fornecedor, eu posso muito bem alterar o fornecedor quando bem entender, e o produto vai continuar existindo.

Está correto, mas como eu disse no meu comentário anterior: "você não costuma ter N níveis", no meu caso, e de alguns que eu já vi, o fornecedor funciona como categoria para compra de produtos, veja bem: existem trocentos fornecedores de MacBook por aí, e num eCommerce, você não cadastra trocentos, você cadastra o cara que te fornece, correto ? podem ser vários ? sim, mas normalmente é um, é uma questão de cotação, se um fornecedor X vende à 3000.00, porque eu compraria do fornecedor Y por 3500.00 ? entendeu ? então não tem vários fornecedores (isso não quer dizer que nunca existirá, e que não é possível, depende do caso).

No ponto de vista do lojista, ele cadastra o cara que vende pra ele os produtos Apple, cadastra pra ele o que vende os produtos Microsoft, cadastra o que vende pra ele os produtos Google, e não "os que vendem", bom, a não ser que você esteja trabalhando com uma "cotação".

:)