Classes especificas para crianças vazias

Acho que o motivo pelo qual você está tendo problemas com qual caminho seguir é porque há uma falha fundamental no design aqui. Você tem classes anêmicas aqui, que é em si um anti-padrão OO. A lógica externa que está ligando o tipo precisa ser trazida para a família de classes Product .

O cheiro do código para isso é que, não importa qual caminho você vá, você precisará verificar um membro de tipo ou instanceof em outros lugares em seu código. O outro cheiro é que você estará constantemente consultando um objeto Product para dados e tomando decisões com base nele (veja dizer-não -ask ). Isso significa que será difícil modificar ou adicionar comportamento, pois você precisará fazer alterações em muitos locais diferentes, em vez de em uma classe apropriada para manter esse comportamento para cada tipo.

Editar:

A adição dos detalhes do código mostra que há um pouco mais de nuance na sua pergunta. Vamos começar olhando para o que estamos falando por "tipo" de produto.

Tradicionalmente, sempre que ouvimos a palavra "type", saltamos para o conceito de objeto Type (o qual eu aproveito para diferenciar). Esse tipo é associado ao comportamento polimórfico, herança, encapsulamento e todos os outros conceitos orientados a objetos. Aqui, porém, não estamos necessariamente descrevendo um tipo. Estamos falando sobre o que parece ser um atributo de dados chamado tipo. O comportamento não muda realmente com base no tipo, apenas no valor .

Como um exemplo para comparar, podemos olhar para números inteiros. Temos int s 1 e 2 . Os comportamentos entre eles são exatamente os mesmos; apenas os valores são diferentes. Isso significa que não devemos ter um tipo abstrato para int que é implementado como int1 tipo concreto e int2 tipo concreto, etc. Precisamos de um tipo concreto para todos os int s, e um simples maneira de interagir entre eles (como comparação para classificação). Sua ideia de um tipo de produto é a mesma.

Se os seus produtos têm ou terão comportamentos distintos e polimórficos, a herança é uma solução válida. Aqui, no entanto, seu tipo é apenas um atributo de dados, como o preço e a marca, sem diferença de comportamento. Portanto, você deve ter um atributo de tipo, como se você tivesse um atributo de preço e um atributo de marca.

O ideal é que você queira tornar seu código mais aberto-fechado, portanto, deve haver uma maneira de fazer isso da maneira mais elegante possível. Podemos criar um enum contendo os diferentes tipos de produtos existentes, ordenados na ordem em que eles precisam ser produzidos (usando um std :: set estático ou similar em product pode ser mais fácil de trabalhar, se você preferir) . O atributo type do product apontará para um valor enum. Na sua classe product_manager , em vez de três vetores nomeados, você deve ter uma estrutura de tipo de mapa / dicionário para mapear do tipo enum para o respectivo vetor, gerado a partir dos elementos no enum. Dessa forma, essa estrutura adicionará automaticamente vetores para cada tipo na instanciação. Quando você adiciona um produto, selecione o vetor para adicioná-lo com base no tipo de produto. Em seguida, você pode percorrer o mapa e, em seguida, sobre cada vetor para imprimir os produtos, agrupados por tipo.

Pseudocódigo:

enum product_type { electrical, electronic, mechanical }

class product {
    //...

    get_type() {
        return this.type;
    }

    //...
}

class product_manager {
    map<product_type, vector<product>> products;

    product_manager() {
        foreach(p_type in product_type) {
            products.insert(p_type, new vector<product>);
        }
    }

    //...

    add_product(product p) {
        products.at(p.get_type()).append(p);
    }

    //...

    print_products() {
        foreach(p_type in product_type) {
            foreach(product in products.at(p_type)) {
                print_product(product);
            }
        }
    }

    //...
}

Se você nunca quiser usar o tipo em outro lugar, pode torná-lo privado e tornar o product_manager um amigo em product .

Eu também quero fazer um breve comentário sobre o código de exemplo que você postou.

//in real application we don't know instantiation proccess, so don't know what type of product comes to us.
test::electrical_product *ep = new test::electrical_product;
test::electronic_product *etp = new test::electronic_product;
test::mechanical_product *mp = new test::mechanical_product;

// set products' members values

pm.add_product(ep);
pm.add_product(etp);
pm.add_product(mp);

pm.print_electrical_products();
pm.print_electronic_products();
pm.print_mechanical_products();

Você usa sobrecarga de método com diferentes tipos de parâmetro para determinar qual implementação chamar. O problema é que, na sua aplicação real, todos os produtos seriam do tipo abstract_product * . O compilador roteia as chamadas de método com base no tipo de tempo de compilação do objeto, significando que quaisquer produtos sendo adicionados serão enviados para um método product_manager.add_product(abstract_product *) em vez dos métodos sobrecarregados, o que significa que ele não faria o que você pretende.

Minha opinião é que adicionar um membro do tipo é uma solução melhor. É mais simples de definir, permite tratar o tipo como um valor de primeira classe, permite codificar o Produto como uma estrutura de dados antiga simples (que é), funciona sem RTTI e você pode usar um switch em vez de vários if / else para ramificar eficientemente com base no tipo. Usando herança, seu código pode quebrar se alguém introduzir uma nova subclasse, já que você está esperando apenas um número finito de tipos de produtos.

Acho melhor ter uma classe Product com um campo de tipo, por alguns motivos:

• Se você precisar serializar / desserializar de uma maneira que a linguagem não suporta nativamente, existe apenas um construtor; você não precisa ativar o tipo e usar um dos vários construtores.
• Há um pequeno benefício para a legibilidade - se os leitores virem ElectricalProduct , talvez se perguntem se ela contém uma lógica especial e precisam abri-la para ver se não.
• Você pode fazer Product final (Java) ou selado (C #), o que é bom para eficiência - certas chamadas de método não precisarão passar por uma vtable.

Dito isso, se você acha que pode adicionar alguma lógica específica a determinados tipos de produto, as classes separadas podem ser melhores para que você possa fazê-lo sem um grande refatorador.

Se realmente você "deve ser capaz de diferenciar cada uma em algumas operações" como você diz, introduzir três classes intermediárias é perfeitamente idéia sensata.

Veja a ideia da Classe abstrata (por exemplo, Java ). Uma classe abstrata não pode ser instanciada em si (a maioria das linguagens OO tem uma construção respectiva que tecnicamente proibir instanciação), mas fornece variáveis e métodos aos seus filhos - e cada classe infantil ainda precisa adicionar um pouco para fazer uma aula completa, instanciável.

No seu caso, ElectricalProduct, ElectronicProduct e MechanicalProduct seriam classes abstratas.