Criação de tipos de Equipamentos (Herança?)

No seu caso eu faria uma classe produto, e outra classe caracteristica:

<?php

classe produto{

 protect $produto;

 // metodos e getters e setters

}

classe caracteristicas extend produto{

 public $carNome;
 public $carDescr;

 // metodos e getters e setters

}

?>

produto impressora

caracteristica nome: voltagem

caracteristica descrição: 110v

caracteristica nome: cor

caracteristica descrição: branca

produto projetor

caracteristica nome: voltagem

caracteristica descrição: 110v

caracteristica nome: lente

caracteristica descrição: tipo de lente

Espero ter ajudado.

Tenta com vetor associativo...

vetores seriam usados mais para uma programação sem orientação a objeto, se você esta utilazando classes e metodos no PHP, eu aconselho você trabalhar com objetos. Mais de qualquer forma tanto o vetor como objeto são usados mais para guardar informações e não a estrutura do seu sistema.

Valeu pela dica Kennedy. Boa ideia.

Seria um relacionamento do tipo composição no qual uma instância da classe Produto poderia ser composta por várias instâncias da classe Característica. Fiz um esboço (veja na imagem).

Ainda tenho dúvida com relação ao mapeamento para o banco de dados relacional, pois, em memória o atributo $valorCarac pode receber qualquer tipo de dados mas no banco o campo deve ter um tipo predefinido (varchar, int, BLOB).

Ainda não sei bem ao certo como eu restringirei e permitirei ao mesmo tempo a criação de características por Produto.

Mas vou pensar melhor, tornarei as ideias em algo mais concreto, colocarei as ideias em modelos e postarei aqui.

P.S. A ideia de array associativo é interessante também, mas acho que não ficaria elegante e termos de projeto. Mas pode ser útil.

Não faz muito sentido que "caracteristica" estenda "produto", pois uma característica NÃO É um produto. Na verdade, a relação é um produto POSSUI características, o que indica uma composição.

Talvez um design pattern que se aplique seja o Prototype.

Você pode ter um objeto-padrão que contenha as características básicas de todos os produtos. Para criar um novo produto, você cria um clone desse objeto e seta as propriedades que desejar.

Tente algo assim:

class Product {

 private $attributes = array();

 public function addAttribute($name, $value) {
 $this->attributes[$name] = $value;
 }

 public function removeAttribute($name) {
 if(isset($this->attributes[$name])) {
 unset($this->attributes[$name]);
 }
 }

 public function getAttribute($name) {
 if(isset($this->attributes[$name])) {
 throw new InvalidArgumentException("Unexistent attribute '{$name'}");
 }
 return $this->attributes[$name];
 }
}

$prototype = new Product();
$prototype->addAttribute('foo', 'bar');
$prototype->addAttribute('baz', 'bazzinga');

Quando for criar seus objetos, faça:

$switch = clone $prototype;
$switch->addAttribute('numberOfPorts', 20);
$switch->addAttribute('transmissionRate', '100 Mbps');

//...

$printer = clone $prototype;
$printer->addAttribute('driver', '/path/to/driver');
$printer->addAttribute('powerSourceType', '127V AC');
$printer->addAttribute('maxResolution', '1600 dpi');

E por aí vai.

Mui boa sua ideia, Barcelos. A ideia inicial não era que a classe 'Característica' estenda a 'Produto', mas criar previamente os tipos de equipamentos que poderiam ser registrados através de herança, com as propriedades genéricas nas classes pai e as específicas nas filhas. Por exemplo,

Equipamento

|

___________|___________

| |

Switch Impressora

. . .

Acho que o 'Prototype' se encaixa melhor para solucionar este problema, utilizando Composição (veja no post anterior).

Tenho algumas dúvidas de como isso ficará no banco de dados relacional (veja no post anterior).

Vou estudar este padrão e aplicar a esta solução. Obrigado.

com as propriedades genéricas nas classes pai e as específicas nas filhas.

Ai vem os objetos abstratos.

Ai vem os objetos abstratos.

Sim, Vinicius. Pode-se utilizar herança (com objetos abstratos assegurando as propriedades e métodos genéricos), mas acho que não é a melhor abordagem devido a grande quantidade de tipos específicos de objetos. Acho que a melhor solução é utilizar algo semelhante ao design pattern Prototype que o colega mencionou.

Pessoal, valeu pela ajuda até agora. Entendi as ideias que vocês colocaram e foram que foram muito úteis. Tinha uma dúvida de como seria o mapeamento dessa solução para o banco de dados relacional de modo que a criação de variados tipos de valores pudessem ser criados conforme as necessidades dos usuários e ao mesmo tempo manter um padrão nos cadastros.

Depois de pensar um pouco pensei nisso:

Modelo Relacional

Neste caso cada Resource (impressora, switch, monitor) poderá ter várias Characteristics (resolução, polegadas, nr de portas, driver) a qual deverá ter um tipo especificado por CharacTypes e finalmente armazenado de acordo com o tipo nas tabelas correspondentes Number, Text, Monetary e BLOB.

Já em PHP acho que a saída será algo semelhante a este modelo.

O que acham?

http://pt.wikipedia.org/wiki/Abstract_Factory

http://pt.wikipedia.org/wiki/Builder

Pessoal, acho que o caminho é por aí mesmo. Utilizando algo como o design pattern Prototype na aplicação e aquele modelo relacional no banco de dados.

Valeu pela ajuda, Pessoal. Espero poder contribuir também aqui.