Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Estou com dificuldades em entender quando um determinado trecho de código deve ser repetido em mais de uma classe afim de manter a independência da mesma, pois segundo artigos que leio sobre orientação a objetos - Um Objeto (classe) deve ser independente o suficiente para ser utilizada sem dependências. - Ter apenas uma funcionalidade, desempenhando apenas o seu papel (coesão).
Meu sistema é foi criado para vendas de comerciais, onde cada bloco/horário tem um preço diferente, calculado com base no preço médio + acréscimos - descontos.
O objetivo (funcionalidade ou papel) da classe VendasController é retornar para View Orcamentos, informações sobre produtos e valores para realização de um orçamento e posteriormente um contrato. Para retornar essas informações eu obtenho o preço médio de cada bloco e adiciono os acréscimos em alguns métodos dentro desta classe, ela tem o funcionamento independente.
Agora estou desenvolvendo outra classe que se chama DistribuicoesController, onde a sua funcionalidade é distribuir uma quantidade X de comerciais no blocos/horários disponiveis, e uma de suas opções seriam distribuir no blocos com menor custo médio.
Portanto a questão aqui é:
Tanto na Classe VendasController como na classe DistribuicoesController eu faço uso de preço médio dos blocos.
Qual seria o mais correto: eu repetir o código nas duas classes, fazer tudo dentro de uma unica classe, criar uma "super classe" e usa-la estendida dentro das classes VendasController e DistribuicoesController.
>
Citar
Pelo que você descreveu sobre o objeto VendaController, ele já está fazendo muito mais do que é de sua responsabilidade. Um controller, por definição, deve apenas receber uma requisição, acionar um model (caso necessário) e enviar os dados para uma view. Um controler sempre estará linkado a uma view, mas, pode nao estar linkado a um model.
Entendi, no caso o Controller serve apenas para receber e enviar (a grosso modo), então neste caso as demais funcionalidades, como está de aplicar acréscimos, montar os preços para serem retornadas pelo controller para a view é feita onde em um padrão MVC ?
>
Citar
O correto é nunca repetir. Se repetir, há possibilidade de refatoração e a criação em uma classe separada.
Então é isso que está me deixando preocupado com minhas classes...
Por exemplo, eu tenho a classe Clientes, onde no momento do Orçamento eu necessito retornar para View uma listagem de clientes, dentro do controller Orcamentos eu chamo o Model Clientes para retornar essa listagem (ja que para realizar um orçamento necessita de escolher um cliente), está correto esta prática ?
>
Citar
Crie um objeto que seja responsável por aquilo que você está trabalhando. Se você está exibindo dados de um orçamento, provavelmente você terá alguns integrantes, como: Orçamento; Itens do Orçamento (seja produto e/ou serviços).
Tenho uma situação distinta onde uso os valores médios dos produtos em cada bloco/horario (exemplo: spot 30", testemunhal, spot 15", no bloco das 15:00) em dois locais, que não tem ligação em si.
Neste caso teria que criar um objeto responsável por retornar esta tabela de preços e utiliza-la nos outros dois objetos (Controllers) distintos para serem retornados ?
>
4 minutos atrás, Daniel-Lopes disse:
Entendi, no caso o Controller serve apenas para receber e enviar (a grosso modo), então neste caso as demais funcionalidades, como está de aplicar acréscimos, montar os preços para serem retornadas pelo controller para a view é feita onde em um padrão MVC ?
O padrão MVC em si define apenas que, regras de negócio devem ser tratadas na camada (layer) Model . Ou seja, esse cálculo deve estar no model.
O model, por sua vez, pode ser compreendido como N camadas. Essas camadas podem ser:
-
Entidades (Entities), ex.: Orçamento, Cliente, Produto;
-
Controle de dados, ex.: DAO (Data Access Object), DataMapper, FileSystem;
-
Operacional, ex.: contábil, estoque, financeiro, etc...
Deve-se entender que o Model é um ecossistema que podem ser diversas camadas. Essas camadas não são definidas pelo MVC e sim por outros padrões. Eu costumo criar sempre as seguintes "camadas" no Model:
-
Model: os objetos que são acessados diretamente pelo controller;
-
DataMapper: conjunto de objetos específicos para o mapeamento de dados de uma base de dados para entidades;
-
Entities: entidades do sistema, são as entidades que são persistidas na base de dados;
-
Entidades de negócio: São entidades que não são persistidas, mas estão intrinsincamente ligadas as entidades e possuem regras complexas de negócio, como contabilidade, financeiro, estoque, etc..
A forma que você irá separar, vai depender do quão complexo é o seu sistema. Há também o DDD (Domain-Driven Design) que prove uma excelente abordagem para a arquitetura.
>
4 minutos atrás, Daniel-Lopes disse:
Então é isso que está me deixando preocupado com minhas classes...
Por exemplo, eu tenho a classe Clientes, onde no momento do Orçamento eu necessito retornar para View uma listagem de clientes, dentro do controller Orcamentos eu chamo o Model Clientes para retornar essa listagem (ja que para realizar um orçamento necessita de escolher um cliente), está correto esta prática ?
Sim, a prática está ok. Você pode verificar os seguintes tópicos sobre o assunto:
https://pt.stackoverflow.com/a/197651/5007
>
4 minutos atrás, Daniel-Lopes disse:
Tenho uma situação distinta onde uso os valores médios dos produtos em cada bloco/horario (exemplo: spot 30", testemunhal, spot 15", no bloco das 15:00) em dois locais, que não tem ligação em si.
Neste caso teria que criar um objeto responsável por retornar esta tabela de preços e utiliza-la nos outros dois objetos (Controllers) distintos para serem retornados ?
Existe uma abordagem chamda de Anemic Model, ela define que entidades devem ter nada ou o mínimo de regras de negócio possível e que outros objetos seriam responsávels por essa regra de negócio. Essa abordagem é muito criticada e, normalmente, o recomendado é inserir a regra de negócio, especifica de uma entidade, na entidade.
Caso uma regra de negócio seja compartilhada, essa regra deve ser separada em outro objeto (vide a minha camada de Entidades de negócio).
Mas isso fica a sua escolha, ambas as abordagens existem, só Anemic Model não é recomendada.
>
1 hora atrás, Daniel-Lopes disse:
[...]Um Objeto (classe) deve ser independente o suficiente para ser utilizada sem dependências.[...]
Essa definição está errada e não condiz com o paradigma orientado à objetos. Ou pode apenas estar fora de contexto. Objetos podem ser independentes, entretanto, não é ruim ter dependência. Apenas, a dependência deve ser bem construída.
Por outro lado, esta, está correta:
>
1 hora atrás, Daniel-Lopes disse:
[...]Ter apenas uma funcionalidade, desempenhando apenas o seu papel (coesão)[...]
O princípio da orientação a objetos, no seu estado mais bruto, é trazer a programação o mais próximo possível do mundo real.
Pelo que você descreveu sobre o objeto VendaController, ele já está fazendo muito mais do que é de sua responsabilidade. Um controller, por definição, deve apenas receber uma requisição, acionar um model (caso necessário) e enviar os dados para uma view. Um controler sempre estará linkado a uma view, mas, pode nao estar linkado a um model.
>
1 hora atrás, Daniel-Lopes disse:
Qual seria o mais correto: eu repetir o código nas duas classes, fazer tudo dentro de uma unica classe, criar uma "super classe" e usa-la estendida dentro das classes VendasController e DistribuicoesController.
O correto é nunca repetir. Se repetir, há possibilidade de refatoração e a criação em uma classe separada.
Crie um objeto que seja responsável por aquilo que você está trabalhando. Se você está exibindo dados de um orçamento, provavelmente você terá alguns integrantes, como: Orçamento; Itens do Orçamento (seja produto e/ou serviços).
O Orçamento e Itens do Orçamento, podem estar associados a outros itens, como o produto/serviço em si, clientes, etc...
Quando você separa desta forma, você isola as responsabilidades e entenderá que cada objeto tem o seu papel. No seu caso, se o cálculo de preço médio dos blocos é realizado para o produto apenas quando ele está em um orçamento, bem, isso é de responsabilidade do Item do Orçamento. Por outro lado, se o preço médio do bloco deve ser calculado considerando o orçamento, o cálculo é de responsabilidade do Orçamento.