[Resolvido] Estrutura de um projeto de Marketing MultiNível com php e mysql

[lucianfpaula 0]

Olá meus amigos, eu não sei onde colocar minha duvida então vou postar aqui para que vocês possam me ajudar.

Estou iniciando um projeto baseado em venda de produtos e pagamento de comissões por indicação dos consumidores, essas comissões serão pagas em Multinivel, ou seja a pessoa indica joão e ganha x% da compra feita por ela, mas se joão indicar maria a pessoas vai ganhar também da maria um x%, ou seja vai ganhar por indicação direta e indireta, mas eu não tenha minima ideia de como fazer isso.

[paulinhosupriano 103]

11 horas atrás, lucianfpaula disse:

Olá meus amigos, eu não sei onde colocar minha duvida então vou postar aqui para que vocês possam me ajudar.

Estou iniciando um projeto baseado em venda de produtos e pagamento de comissões por indicação dos consumidores, essas comissões serão pagas em Multinivel, ou seja a pessoa indica joão e ganha x% da compra feita por ela, mas se joão indicar maria a pessoas vai ganhar também da maria um x%, ou seja vai ganhar por indicação direta e indireta, mas eu não tenha minima ideia de como fazer isso.

 

Olá meu amigo,

bom primeiro precisa organizar seu projeto e se usar OO e muito melhor para fazer o calculo.

 

então se João recebe X por indicação e X por venda direta então no caso João iria ganhar de 2 formas assim como todos os usuário do sistema. então seria o ganho por code do mesmo. ou por uma url especifica que ele ganharia na indicação, ele ganharia quando o usuário se cadastra-se receberia uma porcentagem não sei, mas se e por venda teria promocao e o code de promoção seria o código do indicador.

 

 

Ex.

Seu preço de venda e 10,00

 

João ganha por indicação 0.1

João ganha por venda direta 0.2

 

Então 

O preço mostrado seria Preco + .4%

e na indicação seria Preco + .2%

 

o código seria como promocional onde ao incluir receberia % de desconto seria pouco claro, porem seria por produto ou indicação, estou colocando uma % pequena. 

Calculo seria: %/100*Preco

 

João o codigo dele é: 5

 

Deu para entender?

 

 

 

 

 

[lucianfpaula 0]

Sim, mas é praticamente o eu falei,  gostaria de saber como seria isso na pratica, sei que provavelmente vai ser com uso de array, mas como ? 

[paulinhosupriano 103]

Em 14/11/2017 at 11:45, lucianfpaula disse:

Sim, mas é praticamente o eu falei,  gostaria de saber como seria isso na pratica, sei que provavelmente vai ser com uso de array, mas como ? 

 

Sim, porem os dados recuperados seria do SEU banco de dados. 

Como seria a ideia do mapeamento do seu banco de dados? Coloque abaixo para tentarmos ajudar.

 

[lucianfpaula 0]

a ideia é a seguinte

ter o controle de todos os indicados como tipo um array, exempl

1 indicou 2 logo 2 é do primeiro nível

2 inicou o 3 logo 3 é do primeiro nível do 2 segundo nível do 1 e assim por diante

1

/2

//3

///4

////5

 

será uma organização em piramide, em trheeview ou em arvore geneologica

 

no cadastro vai ter:

id_cliente

id_indicador (aqui irá o id da pessoa que o indicou para o sistema)

nome_cliente

 

essas pessoa irão efetuar compras no sistema e o sistema irá pegar parte do valor da compra e distribuir para todos abaixo daquele cliente que efetuou a compra e assim por diante. essa seria a ideia geral encurtada é claro.

 

[paulinhosupriano 103]

16 minutos atrás, lucianfpaula disse:

a ideia é a seguinte

ter o controle de todos os indicados como tipo um array, exempl

1 indicou 2 logo 2 é do primeiro nível

2 inicou o 3 logo 3 é do primeiro nível do 2 segundo nível do 1 e assim por diante

1

/2

//3

///4

////5

 

será uma organização em piramide, em trheeview ou em arvore geneologica

 

no cadastro vai ter:

id_cliente

id_indicador (aqui irá o id da pessoa que o indicou para o sistema)

nome_cliente

 

essas pessoa irão efetuar compras no sistema e o sistema irá pegar parte do valor da compra e distribuir para todos abaixo daquele cliente que efetuou a compra e assim por diante. essa seria a ideia geral encurtada é claro.

 

 

sim, o que você tem no momento? o que já foi desenvolvido até o presado momento? iria ficar muito grande esse trheeview dessa forma, seria um infinito imagina 1000000 de registros indicado pelo primeiro nível, seria muito grande.

[lucianfpaula 0]

Obrigado pela atenção amigo, eu tenho somente o cadastro, a questão do treeview foi apenas um exemplo, a exibição dos dados não teria que seguir esse formato, mas de qualquer forma a exibição seria limitada tipo uma matriz de 5x5 ou seja comoçaria com 5 pessoas que teria no maximo 19.530 na matriz, isso para a view do cliente né, do lado da empresa que seria diferente. a minha grande duvida é realmente como modelar esse sistema com segurança e robustez. 

[Matheus Tavares 167]

@lucianfpaula, consigo pensar em duas saídas plausíveis para solucionar esse problema:

 

- Utilizar um banco de dados baseado em grafos.

Veja: https://imasters.com.br/banco-de-dados/graphdb-series-o-que-e-um-banco-de-dados-de-grafos/?trace=1519021197&source=single

 

- Utilizar um banco relacional (como o Mysql), onde a tabela de usuários/indicados se auto-referencia com uma chave estrangeira, assim:

usuarios( #id, nome, &indicador )

 

O problema do banco de dados relacional é exatamente esse loop recursivo de buscas até encontrar o indicador raíz (pois pelo que entendi, o primeiro indicador pode estar a uma disância de 100 registros, por ex, do usuário final). Me acompanhe nesse exemplo prático:

CREATE TABLE `usuarios` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `nome` varchar(255) NOT NULL,
  `indicador` int(11) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `indicador` (`indicador`),
  CONSTRAINT `usuarios_ibfk_1` FOREIGN KEY (`indicador`) REFERENCES `usuarios` (`id`) ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `usuarios` (`id`, `nome`, `indicador`) VALUES
(1,	'Usuário raíz!',	1),
(2,	'Indicado pelo raíz',	1),
(3,	'Mais um da raíz',	1),
(4,	'Indicado pelo 2',	2),
(5,	'Indicado pelo 3',	3);

 

Caso queiramos extrair os dados do usuário com ID 5 pra cima:

SELECT u1.*, u2.*, u3.* FROM ( SELECT * FROM usuarios WHERE id = 5 ) u1
    INNER JOIN usuarios u2 ON u2.id = u1.indicador
        INNER JOIN usuarios u3 ON u2.indicador = u3.id

Entendeu a recursão de busca de registros? Essa consulta retornaria isso:

 

id	nome	indicador	id	nome	indicador	id	nome	indicador
5	Indicado pelo 3	3	3	Mais um da raíz	1	1	Usuário raíz!	1

 

Uma forma de diminuir a complexidade da consulta é utilizando Functions ou Stored Procedures do banco de dados ou utilizando o próprio PHP para buscar os registros em loop (mas imagine 100 consultas sendo executadas só para buscar todo o caminho de usuários em uma árvore maior...).

 

Agora, caso você queira limitar a quantidade máxima de "beneficiários" nessa hierarquia, seria bem mais fácil...

Pois nesse caso você poderia criar uma tabela assim:

usuarios( id, nome, indicador1, indicador2, indicador3, indicador4, indicador5 )

 

E depois extrair somente os dados desses 6 caras.

[lucianfpaula 0]

Muito bom meu amigo, depois de perder alguns fios de cabelo entendi o select que você passou, agora como que eu faria pra exibir isso na tela, de forma separada tipo:

 

 Indicados pelo 1

                               lista aqui

indicados pelo 2

                              lista aqui

Desde de já sou muito grato

 

 

[Matheus Tavares 167]

Você está se referindo aos indicados diretos ou indiretos?

Entenda que se estivermos falando dos indicados indiretos, não faz sentido exibirmos dessa forma (em lista), pois a aplicação exige uma árvore para entender sua hierarquia.

 

De qualquer forma, você teria diversas opções para solucionar o problema. As mais óbvias eu acho que seriam:

A. Um loop para exibir cada um dos usuários cadastrados, resolvendo diretamente com o banco, mas provavelmente precisaria de recursos mais avançados, como Functions ou Stored Procedures... OU

 

B. Implementar utilizando um banco de dados baseado em grafos, como eu citei anteriormente... OU

 

C. Elaborar um algoritmo que gere um array associativo ou objeto que represente a hierarquia que você deseja. O ideal nesse caso definitivamente seria resolver com orientação à objetos.

 

Eu iria pelas opções B ou C, mas daí você precisaria cumprir o requisito de estudar as tecnologias que citei.

Não sei se já tens ou não esse conhecimento, mas caso negativo, sugiro que pause seu projeto para estudar isso. Vai te dar mais visão para poder alcançar seus objetivos.

[lucianfpaula 0]

Grato meu amigo, eu consegui resolver com o jstree, bem funcional para o que eu precisava, uma solução leva ao próximo passo, agora que tenho o cadastro e views de acordo com a hierarquia dos vendedores, tenho uma outra duvida. vamos a simulação,

 

Maria -> indicou João, que indicou -> Carlos -> Anderson -> Julia -> Mario

sendo assim temos 5 níveis depois de Maria, Mario fez uma compra de R$ 100,00 e sistema sabe que a comissão é de R$ 10,00 em 5 níveis, logo ele tem que descer na arvore e distribuir R$ 10,00 para cada pessoa

Julia          = R$ 10,00

Anderson = R$ 10,00

Carlos       = R$ 10,00

João         = R$ 10,00

Mario        = R$ 10,00

 

Maria recebe um total de R$ 50,00

 

Como que isso seria feito todo vez que alguém efetuar uma compra, independente da posição, lembrando que é sempre do ultimo para o primeiro. Mais um vez muito grato

[Matheus Tavares 167]

Amigo, vou te dar o caminho das pedras... você estuda o código e implementa o que você precisa em cima dele, certo?

 

- Lembrando que essa é só uma implementação dentro de infinitas e me limitando ao Mysql como banco de dados, pois você está usando ele.

 

- É um código que fiz em algumas horas. Não tenho certeza sobre o impacto com uma hierarquia grande demais, mas tudo é contornável... basta analisar o contexto e otimizar.

 

- Fiz o código no PHP 7, sem me preocupar em deixar compatível com versões anteriores, mas eventuais adaptações seriam tranquilas.

 

- Leia atentamente cada linha no código. Se você não tem experiência com OO vai ser difícil, mas estude os pontos que não entender e releia o código quantas vezes necessário.

 

 

1 - Mmn/DataStructures/Binary/Node.php

Tudo começa por um nó, que *futuramente* será um usuário.Então vamos escrever um nó inicial, que é um nó abstrato para uma árvore binária. Esse não tem mistério:

 

Spoiler

 

<?php
namespace Mmn\DataStructures\Binary;

abstract class Node
{
    /**
     * @var self
     */
    public $left = null, $right = null;
    
    final public function isLastNode()
    {
        return !$this->right;
    }
    
    final public function isFirstNode()
    {
        return !$this->left;
    }
}

 

 

 

 

Simples, né? Uma classe, com atributos que representam seus irmãos e métodos que indicam se trata-se do último ou primeiro nó dentro do contexto de um dos níveis da nossa futura hierarquia/árvore.

 

2 - Mmn/DataStructures/Binary/Tree.php

Agora criamos nossa árvore binária. Por binária, entenda: 2 lados, esquerdo, direito.

- O método count() exibe a quantidade de nós (como a árvore é plana, esses nós são referentes ao nível do contexto em que a árvore se encontra. Não confunda com a quantidade total de nós em todos os níveis).- A classe implementa a interface Iterator, o que nos obriga a implementar current(), key(), next(), rewind(), valid(). Isso serve basicamente para podermos utilizar o foreach em cima dessa árvore. Facilita as coisas futuramente.

 

Spoiler

 

<?php
namespace Mmn\DataStructures\Binary;

class Tree implements \Iterator
{
    /**
     * @var Node
     */
    protected $first = null, $last = null;
    
    /**
     * @var Node
     */
    private $iteratorNode = null;
    private $iteratorPosition = 0;
    
    public function push(Node $node)
    {
        if ( $this->count() ) {
            $top = $this->getLast();
            
            $top->right = $node;
            $node->left = $top;
            
        } else {
            $this->first = $node;
        }
        
        $this->last = $node;
        
        return $this;
    }
    
    public function count()
    {
        if ( !( $i_node = $this->first ) ) {
            return 0;
        }
        
        $i = 1;
        while ( $i_node = $i_node->right ) {
            $i++;
        }
        
        return $i;
    }
    
    /**
     * @return Node
     */
    public function getLast()
    {
        return $this->last;
    }
    
    /**
     * @return Node
     */
    public function getFirst()
    {
        return $this->first;
    }
    
    public function current()
    {
        return $this->iteratorNode;
    }
    
    public function key()
    {
        return $this->iteratorPosition;
    }
    
    public function next()
    {
        $this->iteratorNode = $this->iteratorNode->right;
        $this->iteratorPosition++;
    }
    
    public function rewind()
    {
        $this->iteratorNode = $this->first;
        $this->iteratorPosition = 0;
    }
    
    public function valid()
    {
        return (bool)( $this->iteratorNode );
    }
}

 

 

 

 

3 - Mmn/DataStructures/OneParentMultipleChildren/Node.php

Agora vamos mais fundo e implementamos nosso nó específico. Essa é a parte mais importante.

Esse nó tem irmãos (nós de mesmo nível), pai (com exceção do primeiro/raíz) e filhos (que são representados por árvores de nós).Toda a lógica de inserção baseada no id/id_do_pai está aqui. Recomendo que leia bem para entender. É um código pequeno.

 

Spoiler

 

<?php
namespace Mmn\DataStructures\OneParentMultipleChildren;

use Mmn\DataStructures\Binary;

class Node extends Binary\Node
{
    /**
     * @var int
     */
    public $id, $parent_id;
    
    /**
     * @var self
     */
    public $parent;
    
    /**
     * @var Binary\Tree
     */
    public $children;
    
    public function push(Node $node)
    {
        $node->parent = $this->getNodeParent( $node );
        $parent_children =& $node->parent->children;
        
        if ( !$parent_children ) {
            $parent_children = new Binary\Tree;
        }
        
        $parent_children->push( $node );
    }
    
    public function isParentOf(Node $node)
    {
        return $this->id === $node->parent_id;
    }
    
    public function getNodeParent(Node $node)
    {
        if ( $this->isParentOf( $node ) ) {
            return $this;
        }
        
        if ( $this->children ) {
            foreach ( $this->children as $child ) {
                if ( $parent = $child->getNodeParent( $node ) ) {
                    return $parent;
                }
            }
        }
    }
    
    public function __toString()
    {
        return "#{$this->id} ({$this->nome})";
    }
    
    public function isLastOfLast()
    {
        if ( ( $node = $this )->children ) {
            return false;
        }
        
        do {
            if ( !$node->parent ) {
                return !$node->right;
            }
            
            if ( $node->parent->children->getLast() !== $node ) {
                return false;
            }
            
        } while ( $node = $node->parent );
        
        return true;
    }
}

 

 

 

 

4 - Mmn/Helper/Stringifier.php

Agora criamos uma classe auxiliar e totalmente opcional. Ela servirá apenas para exibir a hierarquia de uma forma bonita, para podermos verificar se os dados estão corretos.Apesar de estar um pouco confuso, por eu não ter dado tanta atenção a boas práticas nesse trecho da nossa pequena aplicação, ela servirá de exemplo para que você crie suas próprias soluções depois.

 

Spoiler

 

<?php
namespace Mmn\Helper;

use Mmn\DataStructures\OneParentMultipleChildren\Node;

abstract class Stringifier
{
    public static function parseOneParentMultipleChildrenHierarchy(Node $node, $hierarchy_level = 0): string
    {
        $last_of_last = $node->isLastOfLast();
        $str = $last_of_last ? '&boxUR;' : ( $node->parent ? '&boxVR;' : '&boxDR;' );
        
        $spaces = implode(
            $last_of_last ? '&boxHU;' : '&boxVH;',
            array_fill( 0, $hierarchy_level, str_repeat( '&boxH;', 4 ) )
        );
        
        $pointer_char = self::getFinalConnectorChar( $node );
        $indent = function ($string) use ($spaces, $pointer_char) {
            return $spaces . $pointer_char . '&boxH;&#9658; ' . $string;
        };
        
        $str .= $indent( (string)$node . "\n" );
        
        if ( $node->children ) {
            ++$hierarchy_level;
            foreach ( $node->children as $child ) {
                $str .= self::parseOneParentMultipleChildrenHierarchy( $child, $hierarchy_level );
            }
        }
        
        return $str;
    }
    
    private static function getFinalConnectorChar(Node $node)
    {
        if ( !$node->parent ) {
            return '';
        }
        
        $siblings = $node->parent->children;
        if ( $siblings->getFirst() === $siblings->getLast() ) {
            return '';
        }
        
        if ( $node->left ) {
            if ( $node->right ) {
                return '&boxVH;';
            } else {
                return '&boxVH;';
            }
        } else {
            return '&boxHD;';
        }
    }
}

 

 

 

 

5 - Mmn/Entity/Users.php

Show... agora criamos nosso usuário. Ele é um usuário, mas também é um nó da hierarquia.

 

Spoiler

 

<?php
namespace Mmn\Entity;

use Mmn\DataStructures\OneParentMultipleChildren\Node;

class Users extends Node
{
    public $id;
    public $nome;
    public $indicador;
    
    public function __construct()
    {
        $this->parent_id = $this->indicador;
    }
}

 

 

 

 

E acabou... vamos unir tudo agora e testar?

 

Primeiro insira os dados na sua tabela (a mesma tabela que postei anteriormente):

INSERT INTO `usuarios` (`id`, `nome`, `indicador`) VALUES
(1,	'Usuário raíz!',	1),
(2,	'Indicado pelo 1',	1),
(3,	'Mais um da raíz',	1),
(4,	'Indicado pelo 2',	2),
(5,	'Indicado pelo 3',	3),
(6,	'Indicado pelo 5',	5),
(7,	'Indicado pelo 3',	3),
(8,	'Indicado pelo 3',	3),
(9,	'Indicado pelo 3',	3),
(10,	'Indicado pelo 9',	9),
(11,	'Indicado pelo 9',	9),
(12,	'Indicado pelo 11',	11);

conexao.php

Spoiler

 

<?php
$hostname = 'host';
$database = 'base';
$username = 'user';
$password = 'senha';

$pdo = new PDO(
    "mysql:host={$hostname};dbname={$database};charset=utf8", $username, $password,
    [ PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'utf8'" ]
);
$pdo->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );

 

 

 

 

 

index.php

<?php
/**
 * Esses requires deveriam ser feitos por um autoloader...
 **/
require_once 'Mmn/DataStructures/Binary/Node.php';
require_once 'Mmn/DataStructures/Binary/Tree.php';
require_once 'Mmn/DataStructures/OneParentMultipleChildren/Node.php';
require_once 'Mmn/Entity/Users.php';
require_once 'Mmn/Helper/Stringifier.php';

require_once 'conexao.php';

/**
 * A ordem por ID é importante, pois garantimos a hierarquia da árvore.
 * Além disso fica evidente que o primeiro registro é o usuário raíz.
 */
$query = 'SELECT `id`, `nome`, `indicador` FROM `usuarios` ORDER BY `indicador`, `id` ASC';

/**
 * Executamos a Query com o PDO, que já está conectado e associado à variável $pdo
 * Observe o fetch mode definido para invocar nossa entidade/classe
 * em cada linha retornada e o uso do atributo PROPS_LATE.
 */
$stmt = $pdo->query( $query, PDO::FETCH_CLASS, '\\Mmn\\Entity\\Users' );

/**
 * Extraímos o usuário raíz
 * @var \Mmn\Entity\Users $root
 */
$root = $stmt->fetch();

/**
 * Agora alimentamos o raíz com seus nós-filhos
 */
while ( $node = $stmt->fetch() ) {
    $root->push( $node );
}

/**
 * Exibimos a árvore
 */
echo '<pre>' . Mmn\Helper\Stringifier::parseOneParentMultipleChildrenHierarchy( $root ) . '</pre>';

 

RESULTADO FINAL:

╔═► #1 (Usuário raíz!)
╠════╦═► #2 (Indicado pelo 1)
╠════╬═════► #4 (Indicado pelo 2)
╠════╬═► #3 (Mais um da raíz)
╠════╬════╦═► #5 (Indicado pelo 3)
╠════╬════╬═════► #6 (Indicado pelo 5)
╠════╬════╬═► #7 (Indicado pelo 3)
╠════╬════╬═► #8 (Indicado pelo 3)
╠════╬════╬═► #9 (Indicado pelo 3)
╠════╬════╬════╦═► #10 (Indicado pelo 9)
╠════╬════╬════╬═► #11 (Indicado pelo 9)
╚════╩════╩════╩═════► #12 (Indicado pelo 11)

 

[lucianfpaula 0]

Rapaaaaaaaaaaaaaaazzzzzzzzzzzzzzzzzz, tu é Piiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii, funcionou do jeito que passou, vou estudar a funda pra aplicar no projeto, muito gratooooooooooooooooooooooooooo

[Matheus Tavares 167]

Legal, @lucianfpaula.

 

Apenas corrija um pequeno deslize meu no código:

public function __toString()
{
    return "#{$this->id} ({$this->nome})";
}

 

Este método está presente na classe Node, que não deveria ter acesso ao atributo nome, pois este atributo é uma característica presente somente na nossa entidade usuário.

Funcionalmente dá na mesma, pois Users também é Node.... mas conceitualmente é um erro grosseiro.

 

Apenas transfira esse trecho da classe Node para dentro classe Users e estará tudo ok.

 

Abraço e bons estudos!

[Cabelaravel Capilaravel 0]

Parabéns @MatheusTavares muito bom o código, creio que vou utilizar num sistema em Laravel... Consegui rodar, mas não consegui utilizar o model do laravel pois ele estende o model eloquent... estou fazendo num objeto paralelo para funcionar. Será que é possível utilizar no model do laravel?

[Matheus Tavares 167]

Olá @Cabelaravel Capilaravel, seja bem-vindo.

 

1 hora atrás, Cabelaravel Capilaravel disse:

Parabéns @MatheusTavares muito bom o código

Obrigado! Fico feliz que ele esteja ajudando ainda mais pessoas.

 

1 hora atrás, Cabelaravel Capilaravel disse:

estou fazendo num objeto paralelo para funcionar. Será que é possível utilizar no model do laravel?

Com um pouco de persistência você poderia sim integrar diretamente o Model do Laravel com o código. Um caminho poderia ser utilizando Traits e Interfaces que conferissem o comportamento de um Node para o seu Model, uma vez que o PHP não dá suporte a herança horizontal de fato.

 

A questão é: um sistema que utilize esse código precisa escalar. Precisa suportar o máximo de participantes possível, certo? Cada referência a um objeto que você mantém na árvore é um objeto que você impede que o Garbage Collector remova para você.

É aí que tá o pulo do gato: quanto menor o objeto, melhor! Por isso é mais eficiente você:

 

1 - Fazer uma consulta e extração crua dos dados no banco (quanto menor a participação do Eloquent nessa etapa do processo, mais eficiente será a execução). O ideal é extrair em array mesmo e importar para um Node. Você poderia implementar dentro de node um método estático assim por exemplo:

//dentro do Node:
public static function importFromArray( array $node ) { /* Implementação... */ }

//depois chamar:
$Node = Node::importFromArray( $usuario_do_banco_em_array );

2 - Usar um objeto paralelo mesmo, isolando a biblioteca. Seus models são uma coisa, sua lib é outra.

Isso te dá como desvantagem uma pequena repetição de código, mas também te retribui com independência entre os pacotes, além de reduzir o desperdício de memória.

 

Cada caso é um caso, mas visando a performance, nesse aqui eu faria dessa forma...

[BrunoBit 82]

@Matheus Tavares O estilo que você constrói o código é muito loko, fica bem organizado. Guardei eles pra estudar.

[Matheus Tavares 167]

2 horas atrás, BrunoBit disse:

O estilo que você constrói o código é muito loko, fica bem organizado. Guardei eles pra estudar.

Legal, @BrunoBit, obrigado! Isso é graças à OO. Vale muito a pena estudar e praticar isso.

Somente a prática faz o programador deixar de apenas "usar classes" para programar orientado à objetos. São coisas distintas.

Aqui no fórum tem muito material interessante a respeito, mas imagino que você já tenha visto: https://forum.imasters.com.br/topic/402329-padrões-gof/

 

 

Hoje em dia estou utilizando mais outro paradigma (pois estou trabalhando mais com JS), mas tudo o que pratiquei em OO segue me ajudando. Todo conhecimento é válido. Mas isso é papo para outro tópico...

[BrunoBit 82]

Sim cara, to em busca disso, de literalmente programar orientado à objeto de forma eficiente.

Aquele "padrões de criação" é o estilo de codificar? Abstract Factory, Singleton etc. Já ouvi muito sobre Singleton naquelas lives que o joão fazia lá no canal da imasters, mas não entendia direito o que era, no caso é um padrão pra codificar o código?

[Matheus Tavares 167]

1 hora atrás, BrunoBit disse:

Aquele "padrões de criação" é o estilo de codificar

"Estilo de codificar" não é uma boa expressão para representar os padrões de projeto.

 

Padrões de projeto nada mais são do que "soluções" para problemas comuns (sim, entre aspas).

Quando você os conhece fica mais fácil criar caminhos para construção de códigos mais eficientes e mais manuteníveis.

No entanto, minha sugestão é: não se sinta atraído por nomes bonitos, por parecerem mais inteligentes. Estude sim os padrões, vale a pena à longo prazo, mas OO você aprende mesmo na prática, não na teoria.

 

Na Wikipedia há um excelente artigo a respeito. Lá você encontra as definições desses termos "padrão comportamental", "estrutural", etc, que você tem dúvidas.

Também encontra o seguinte trecho (que eu concordo):

Citar

Segundo alguns usuários, alguns "padrões de projeto" são apenas evidências de que alguns recursos estão ausentes em uma determinada linguagem de programação (Java ou C++ por exemplo). Nesta linha, Peter Norvig demonstra que 16 dos 23 padrões do livro 'Design Patterns' são simplificados ou eliminados nas linguagens Lisp ou Dylan, usando os recursos diretos destas linguagens.

Segundo outros, excessos nas tentativas de fazer o código se conformar aos 'Padrões de Projeto' aumentam desnecessariamente a sua complexidade.

 

O próprio João debateu a respeito desse aumento desnecessário de complexidade na sua brilhante palestra sobre o tema: https://www.youtube.com/watch?v=k7YgqITFaKk

 

Também não posso deixar de recomendar os livros:

- Código Limpo, do Robert C. Martin. Esse é fenomenal. Foi o próprio João que me indicou, inclusive.

- Padrões de Projetos, da Gang of Four.

 

1 hora atrás, BrunoBit disse:

Já ouvi muito sobre Singleton [...], mas não entendia direito o que era, no caso é um padrão pra codificar o código?

 

Singleton é o mais simples e provavelmente o mais controverso dos padrões de projeto. Eu particularmente sou contra o uso dele.

Existem diversos materiais a respeito, mas aqui há um simples de entender: https://wehavescience.wordpress.com/2012/11/01/singleton-um-exemplo-simples-e-pratico/

Também não custa mencionar argumentos contra o seu uso.

 

Mas o ideal é você criar um tópico para cada dúvida a respeito. Vamos tentar não poluir esse para quem cair aqui de paraquedas. Há muito material sobre os padrões de projeto, inclusive aqui no fórum.