PROGRAMA?ÃO OO NA PR?TICA - DICA (PEDINDO UMA)
Caro JABA,
Isso que você falou, seria uma permissão? Já fiz um sistema usando permissões com esta intenção. Se o camarada passa a vender produtos, ele irá ter acesso aos formulários de vendas, fazer coisas de vendedor como cotar, fazer pedidos, cancelar itens, etc. Neste caso eu apenas inseri o camarada no grupo de vendedores.
Eu sei que seu exemplo não tem nada a ver com banco, mas é só assim que consegui pensar quando vc escreveu. Desconfio que ainda não entendi.
Desculpe a minha insistência e persistência. Eu não consigo enxergar sem ter exemplos profundos, bem detalhados, falando do que acontece no sistema e no código. Senão eu me confundo.
Por exemplo: [Ô]A classe funcionário herda os atributos da classe PessoaFisica. Assim o objeto ele poderá fazer tal coisa, de tal forma, na tela tal do sistema, por que....[Ô] e por aà vai.
Vc não tem um exemplo real aà nos seus sitemas? Não precisa do código fonte. Só uma explicação textual é suficiente.
Abs.
Isso que você falou, seria uma permissão? Já fiz um sistema usando permissões com esta intenção. Se o camarada passa a vender produtos, ele irá ter acesso aos formulários de vendas, fazer coisas de vendedor como cotar, fazer pedidos, cancelar itens, etc. Neste caso eu apenas inseri o camarada no grupo de vendedores.
Eu sei que seu exemplo não tem nada a ver com banco, mas é só assim que consegui pensar quando vc escreveu. Desconfio que ainda não entendi.
Desculpe a minha insistência e persistência. Eu não consigo enxergar sem ter exemplos profundos, bem detalhados, falando do que acontece no sistema e no código. Senão eu me confundo.
Por exemplo: [Ô]A classe funcionário herda os atributos da classe PessoaFisica. Assim o objeto ele poderá fazer tal coisa, de tal forma, na tela tal do sistema, por que....[Ô] e por aà vai.
Vc não tem um exemplo real aà nos seus sitemas? Não precisa do código fonte. Só uma explicação textual é suficiente.
Abs.
O que eu disse não tem nada a ver com permissões. Acho que a tua dificuldade vem por se amarrar na ideia de códigos diretamente nos formulários. Eu lhe aconselho a procurar aprender sobre o conceito de camadas primeiramente, como por exemplo a camada de negócio (Business Logic Layer - BLL), pois assim novos horizontes se abrirão pra você.
Quando eu citei o caso do Vendedor, eu estou tratando apenas da parte referente a lógica de negócios, pois é ali que está o coração da sua aplicação. Esqueça um pouco a ideia de fazer tudo diretamente nos Forms. Quando você firmar esses conceitos, aà a POO vai começar a fazer mais sentido pra você. Não adianta muito você pegar exemplos prontos sem entender os conceitos.
Quando eu citei o caso do Vendedor, eu estou tratando apenas da parte referente a lógica de negócios, pois é ali que está o coração da sua aplicação. Esqueça um pouco a ideia de fazer tudo diretamente nos Forms. Quando você firmar esses conceitos, aà a POO vai começar a fazer mais sentido pra você. Não adianta muito você pegar exemplos prontos sem entender os conceitos.
Pois é JABA, nos treinamentos sobre POO não vi BLL. Vou dar uma pesquisada.
Sobre os exemplos, eu discordo de vc. Tem muitos exemplos que assumem que sabemos determinados assuntos. Aà está o problema para quem não tem todos os conceitos. Por isso falei em um exemplo textual, bem detalhado. Não necessariamente com código pronto. Mas se tiver os dois, aà ajuda bastante.
Um dia ainda vou preparar um artigo destes...
Mais uma vez obrigado!
Abs.
Sobre os exemplos, eu discordo de vc. Tem muitos exemplos que assumem que sabemos determinados assuntos. Aà está o problema para quem não tem todos os conceitos. Por isso falei em um exemplo textual, bem detalhado. Não necessariamente com código pronto. Mas se tiver os dois, aà ajuda bastante.
Um dia ainda vou preparar um artigo destes...
Mais uma vez obrigado!
Abs.
Os exemplos são sempre bem-vindos sim, mas a questão é que você está muito cru com relação a POO. Você mesmo disse que fez vários cursos sobre o assunto e não conseguiu descobrir o verdadeiro benefÃcio. Sendo assim, eu sugiro que procure entender o conceito de camadas primeiro, pois isso já vai lhe dar uma base melhor para entender POO.
FBUR, como prometido.
Fiz o exemplo em C#. Há 6 projetos, onde 4 são dlls e 2 são WinForms (assumindo o papel de 2 sistemas diferentes ok).
A base é o seu cadastro de clientes simples que está na dll Cadastros. Depois criei uma dll CadastrosVip onde adicionei 2 campos herdando a classe que está na dll Cadastros.
Nas outras 2 dll estão o CRUD. No DbCadastros eu faço a manipulação dos dados referentes ao projeto Cadastros. O comportamento de CadastrosVip no projeto DbCadastrosVip herda e implementa as funções relativas aos clientes vip (aqui assume o limite de crédito e a validade).
Há um banco de dados compartilhado pelos 2 projetos.
Não fiz muitas validações. Nem fiz também a função de alteração, esta vou deixar você fazer, ok.
Espero que tenha entendido o conceito que foi utilizado e ao mesmo tempo ajudado nas suas dúvidas.
Qualquer coisa posta ai.
Fiz o exemplo em C#. Há 6 projetos, onde 4 são dlls e 2 são WinForms (assumindo o papel de 2 sistemas diferentes ok).
A base é o seu cadastro de clientes simples que está na dll Cadastros. Depois criei uma dll CadastrosVip onde adicionei 2 campos herdando a classe que está na dll Cadastros.
Nas outras 2 dll estão o CRUD. No DbCadastros eu faço a manipulação dos dados referentes ao projeto Cadastros. O comportamento de CadastrosVip no projeto DbCadastrosVip herda e implementa as funções relativas aos clientes vip (aqui assume o limite de crédito e a validade).
Há um banco de dados compartilhado pelos 2 projetos.
Não fiz muitas validações. Nem fiz também a função de alteração, esta vou deixar você fazer, ok.
Espero que tenha entendido o conceito que foi utilizado e ao mesmo tempo ajudado nas suas dúvidas.
Qualquer coisa posta ai.
FFCOUTO... show.
Pelo que vi, já clareou minhas idéias. Era disso que eu estava falando
Vou completar com os conceitos de BLL que o JABA falou e vamos ver no que dá.
Fico muito agradecido!
Abs.
Pelo que vi, já clareou minhas idéias. Era disso que eu estava falando
Vou completar com os conceitos de BLL que o JABA falou e vamos ver no que dá.
Fico muito agradecido!
Abs.
Com o VB6, ainda que desde 1997 era perfeitamente viável a construção de classes, o mais usual era desenvolver cada formulário como sendo responsável pela conexão aos dados, pela manutenção das informações, pela validação, pelas regras de negócio e ainda pela apresentação ao usuário.
A OOP não [Ô]chegou chegando[Ô], só para [Ô]acabar com essa farra[Ô]. Ela é uma ferramenta extremamente útil e importante, permitindo [Ô]materializar[Ô] conceitos que serão refletidos para os modelos de tela e para os serviços de dados. Normalmente, quando se está começando com a OOP, focamos a atenção ao [Ô]banco de dados[Ô]: BLL e a DAL, mas em relação á interface com o usuário, acabamos por esquecer, ou imaginar que não será necessária nenhuma implementação OOP para esse fim.
Nada mais equivocado. e o exemplo pode ser bem simples: Temos uma classe chamada USUARIO, que por sua vez tem quase uma dúzia de propriedades direras, como Nome, Sobrenome, Apelido, Senha, Cadastro, StatusDeAcesso e outras. Mas no meu formulário de Login, eu somente vou precisar de duas dessas propriedades (Apelido, Senha) e somente de uma sublista de usuários (onde StatusDeAcesso seja = [Ô]Desconectado[Ô]). Então, além da classe USUARIO, eu posso criar uma outra, a USUARIOViewModel, apenas com as propriedades necessárias, com os métodos [Ô]Autenticar[Ô] e [Ô]Lista[Ô]. Essa nova classe não é idêntica á primeira: Ela se reporta exclusivamente á esse formulário de acesso especificamente, e nada mais. No entanto, internamente, ela administra a coleção de usuarios baseados na entidade USUARIO. A OOP, portanto, me permitiu definir a classe que será o [Ô]reflexo[Ô] dos dados armazenados em banco (entidade), mas também a classe que será responsável por [Ô]transitar[Ô] os dados entre o formuiário (interface) e a entidade.
Bom, além disso, a OOP aponta a herança como um caminho para a customização de classes. Mas como eu disse, a OOP sozinha não é de fato suficiente para a elaboração de um sistema corporativo para os dias de hoje. As metodologias derivadas da aplicação de camadas, se você observar, parecem à primeira vista ser uma redundância, pois, por exemplo, podemos ter uma classe para Pessoa na camada de entidades, e outra no modelo (pattern) de visualização (ViewModel).
Mas quando você observa atentamente, percebe que não se trata de redundância, mas sim de adaptabilidade. Assim, o [Ô]Pessoa[Ô] da camada de entidades, posto que há ao menos uma situação onde não se requer que o campo CPF seja preenchido, não será requerido e essa camada é [Ô]imutável[Ô]. Mas no modelo de visualização (seja WebForms, MVC, WPF, Winforms, Desktop x86 etc.), um [Ô]flag[Ô] de configuração do aplicativo determina que, na entrada de dados, esse item seja requerido. E com isso, sua aplicação passa á ser customizável, sem a necessidade de alterar cófigos-fonte.
O que estou colocando é que a OOP é apenas uma das [Ô]ferramentas[Ô] para você ter um [Ô]desenvolvimento feliz[Ô] da aplicação ou sistema, mas que muitas vezes requer algo mais, um modelo de padronização, similar por exemplo á um Model-to-View ou um Domain Driven.
é importante ter em mente uma regra básica: A manuseabilidade de uma classe é inversamente proporcional á quantidade de suas propriedades. Assim, procure sempre criar classes pequenas, objetivas e de responsabilidade exclusiva. Quando for necessário, implemente por meio de herança, ou use interfaces para categorias similares. Por exemplo, Professor, Aluno, Responsável e Usuário, podem ser todos implementações da interface IPessoa, ou ainda, serem herdados desde a classe Pessoa.
Outro ponto, é sempre discutir cada entidade muito bem antes de implementar. Só para exemplificar, no caso do campo [Ô]Idade[Ô] citado no tópico, ele pode ser uma propriedade calculada (com base na data de nascimento) e assim, jamais será gravado. Não estou apontando um caminho especÃfico: Estou apenas dando um exemplo, onde, ainda que as classes de base (Core) se mantenham inalteradas, cada aplicativo é responsavel por apresentar essa ou aquela informações, desse ou daquele modo. E com isso, PODE SER que o seu problema não seja alguma falta de conhecimento na orientação á objetos, mas, por exemplo, pode estar relacionado á programação em camadas.
Espero não ter sido tão chato ao ponto de estarem todos dormindo de babar á essa hora.
A OOP não [Ô]chegou chegando[Ô], só para [Ô]acabar com essa farra[Ô]. Ela é uma ferramenta extremamente útil e importante, permitindo [Ô]materializar[Ô] conceitos que serão refletidos para os modelos de tela e para os serviços de dados. Normalmente, quando se está começando com a OOP, focamos a atenção ao [Ô]banco de dados[Ô]: BLL e a DAL, mas em relação á interface com o usuário, acabamos por esquecer, ou imaginar que não será necessária nenhuma implementação OOP para esse fim.
Nada mais equivocado. e o exemplo pode ser bem simples: Temos uma classe chamada USUARIO, que por sua vez tem quase uma dúzia de propriedades direras, como Nome, Sobrenome, Apelido, Senha, Cadastro, StatusDeAcesso e outras. Mas no meu formulário de Login, eu somente vou precisar de duas dessas propriedades (Apelido, Senha) e somente de uma sublista de usuários (onde StatusDeAcesso seja = [Ô]Desconectado[Ô]). Então, além da classe USUARIO, eu posso criar uma outra, a USUARIOViewModel, apenas com as propriedades necessárias, com os métodos [Ô]Autenticar[Ô] e [Ô]Lista[Ô]. Essa nova classe não é idêntica á primeira: Ela se reporta exclusivamente á esse formulário de acesso especificamente, e nada mais. No entanto, internamente, ela administra a coleção de usuarios baseados na entidade USUARIO. A OOP, portanto, me permitiu definir a classe que será o [Ô]reflexo[Ô] dos dados armazenados em banco (entidade), mas também a classe que será responsável por [Ô]transitar[Ô] os dados entre o formuiário (interface) e a entidade.
Bom, além disso, a OOP aponta a herança como um caminho para a customização de classes. Mas como eu disse, a OOP sozinha não é de fato suficiente para a elaboração de um sistema corporativo para os dias de hoje. As metodologias derivadas da aplicação de camadas, se você observar, parecem à primeira vista ser uma redundância, pois, por exemplo, podemos ter uma classe para Pessoa na camada de entidades, e outra no modelo (pattern) de visualização (ViewModel).
Mas quando você observa atentamente, percebe que não se trata de redundância, mas sim de adaptabilidade. Assim, o [Ô]Pessoa[Ô] da camada de entidades, posto que há ao menos uma situação onde não se requer que o campo CPF seja preenchido, não será requerido e essa camada é [Ô]imutável[Ô]. Mas no modelo de visualização (seja WebForms, MVC, WPF, Winforms, Desktop x86 etc.), um [Ô]flag[Ô] de configuração do aplicativo determina que, na entrada de dados, esse item seja requerido. E com isso, sua aplicação passa á ser customizável, sem a necessidade de alterar cófigos-fonte.
O que estou colocando é que a OOP é apenas uma das [Ô]ferramentas[Ô] para você ter um [Ô]desenvolvimento feliz[Ô] da aplicação ou sistema, mas que muitas vezes requer algo mais, um modelo de padronização, similar por exemplo á um Model-to-View ou um Domain Driven.
é importante ter em mente uma regra básica: A manuseabilidade de uma classe é inversamente proporcional á quantidade de suas propriedades. Assim, procure sempre criar classes pequenas, objetivas e de responsabilidade exclusiva. Quando for necessário, implemente por meio de herança, ou use interfaces para categorias similares. Por exemplo, Professor, Aluno, Responsável e Usuário, podem ser todos implementações da interface IPessoa, ou ainda, serem herdados desde a classe Pessoa.
Outro ponto, é sempre discutir cada entidade muito bem antes de implementar. Só para exemplificar, no caso do campo [Ô]Idade[Ô] citado no tópico, ele pode ser uma propriedade calculada (com base na data de nascimento) e assim, jamais será gravado. Não estou apontando um caminho especÃfico: Estou apenas dando um exemplo, onde, ainda que as classes de base (Core) se mantenham inalteradas, cada aplicativo é responsavel por apresentar essa ou aquela informações, desse ou daquele modo. E com isso, PODE SER que o seu problema não seja alguma falta de conhecimento na orientação á objetos, mas, por exemplo, pode estar relacionado á programação em camadas.
Espero não ter sido tão chato ao ponto de estarem todos dormindo de babar á essa hora.
Concordo plenamente PROFESSOR!
Um dia tudo vai fazer mais sentido 
Obrigado pela contribuição PROFESSOR.
Abs.
Obrigado pela contribuição PROFESSOR.
Abs.
Tópico encerrado , respostas não são mais permitidas