TRATANDO-SE DE POO, COMO QUE VOCÊS FARIAM?

 Tópico anterior Próximo tópico Novo tópico

TRATANDO-SE DE POO, COMO QUE VOCÊS FARIAM?

C#

 Compartilhe  Compartilhe  Compartilhe
#489857 - 08/08/2019 12:15:26

WELISSON
CACHOEIRO DE ITAPEMIRIM
Cadast. em:Junho/2017


Última edição em 08/08/2019 12:17:24 por WELISSON

Fala pessoal, estou com uma dúvida a respeito de desenvolvimento c# com desktop,
gostaria de saber o que é melhor.

Por padrão o c# define todos os controles do formulário como private. Sei que existe
a opção de definir como publico, até fiz isso, porem: Isso não seria uma má prática?

Falando de POO é claro, no que tange o incapsulamento!

Se sim, como que faria para acessar esses objetos estão? Pois o sistema vai ter
formulários relacionados, por exemplo:

FrmListaProdutos, FrmCadastroProduto

A maneira que encontrei, é definindo as propriedades publicas ou então criar
get e set para cada objeto do formulário.

Antes de começar o sistema, eu pensei em uma arquitetura do tipo. Crio um
form principal por exemplo: FrmEstoque

E dentro dele criar abas que representaria as "classes do negócio em si". Por exemplo

==================================================
FrmEstoque
==================================================

--------------------    -------------------    ---------------------
Page Entradas  |  Page Saidas     |  Page Estoque
--------------------    -------------------    ---------------------


==================================================

Tudo isso dentro de um form principal, só que ai analisei... Com o tempo isso
pode tornar o formulário pesado de mais. Pois teria muitos componentes
em um único form, o que pode ser uma má ideia!

Já por outro lado, eu poderia acessar as propriedades sem torná-las publicas
para todo projeto...

O que vocês fariam, ou fazem?












#489860 - 08/08/2019 13:50:16

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
Um formulário é tão somente uma classe como qualquer outra e pode ter propriedades, métodos e eventos adicionados, sobre-escritos e sobrecarregados. Então se no form "FrmCadastroProduto", você vai lidar com uma entidade "Produto", você pode simplesmente colocar uma propriedade pública do tipo. No FrmListaProdutos, você vai ter algo parecido, também uma propriedade, mas de List<Produto>. Ao clicar no produto selecionado para editar, você simplesmente pega a instância do membro(no caso List<Produto>) e acha o selecionado(pela propriedade DataBoundItem) que se refere ao produto corrente. Repasse esse produto para a propriedade "Produto" do FrmCadastroProduto, seja por um overload do construtor, injeção de dependência ou qualquer metodologia que esteja usando

_______________________________________________________________________
Virei Oráculo!
The end is nigh, be ready for the nukes!


#489861 - 08/08/2019 14:45:04

JABA
CABO FRIO
Cadast. em:Agosto/2005


Última edição em 08/08/2019 14:45:45 por JABA

Em se tratando da camada de apresentação, não vejo por que ser tão rigoroso quanto aos princípios da POO, tudo vai depender do tamanho do projeto, equipe e grandes possibilidades de customizações.  No VB.Net os controles são declarados como FRIEND. Você pode fazer algo similar declarando-os como INTERNAL no C#.


_______________________________________________________________________________________________

Se a alma ou espírito são imateriais, como eles fazem para se localizarem quando o corpo está em movimento?



#489863 - 08/08/2019 15:16:19

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
Já não faço nada Desktop tem bem uma década(sem exagero) então geralmente sigo uma receitinha pra UI, coisa bem prática mesmo. Tenho aqui vários T4 que praticamente criam a aplicação completinha pra mim, baseada no banco de dados. Então faço o banco e rodo meus T4 que geram todo o modelo de dados(Entity Framework) e "compartimentado" se eu quiser(quer dizer, separado em pequenos microsserviços), uma WebAPI REST com todos os endpoints "replicados" para OData. Gera também toda a parte de autenticação, baseado em um duas(às vezes três) tabelas contendo logins e roles. A UI também gera automático, tanto versão Web mesmo(Angular ou React geralmente). Tem opcional também pra gerar Client mobile(ambos Android e iOS) que contêm todas as mesmas funcionalidades da UI Web. Também tem o opcional pra gerar um "encapsulado" pra windows(Cordova e Ionic, mas quero mudar isso pra React Native e Angular NativeScript). Então levo coisa de umas horas pra gerar aplicações básicas mas totalmente funcionais com tudo isso acima. Depois vou mudando e adaptando para coisas mais específicas. Geralmente umas duas semanas e entrego produto prontinho. Claro, isso pra aplicações mais básicas nos moldes CRUD. Quando se trata de coisas mais "deep core", daí é outra figura.

_______________________________________________________________________
Virei Oráculo!
The end is nigh, be ready for the nukes!


#489889 - 09/08/2019 10:12:46

FOXMAN
BARRETOS
Cadast. em:Janeiro/2001


Membro da equipe
Vamos falar de POO, "NO MEU CONCEITO É CLARO".

POO , é um conceito, um conceito de PROGRAMAÇÃO ORIENTADA A OBJETOS.
Nossa profissão é como a de um marceneiro(já citei isso aqui antes).
Escolhemos nossas ferramentas, e "fabricamos" algo.

Para fabricar uma cama, existe um conceito. E cada marceneiro, utilizará ferramentas e formas diferentes para realizar este conceito(IDÉIA).
Vamos trazer agora, para a nossa realidade e especificamente para o assunto abordado neste tópico.
Eu desenvolvo para desktop, e quando iniciei o projeto atual, defini uma classe Principal, que iria trabalhar em função do projeto como num todo.

No caso produtos, declaro o objeto produto, como uma propriedade privada no formulario.
E enquanto eu estiver no formulário, toda a classe produto e suas subclasses, estarão disponiveis para os componentes.
Com relação a quantidade de componentes, acredito não ser o problema.
Trabalho exatamente como vc está descrevendo, tenho o frmProduto, e nele diveras Pages, como por exemplo, Lista de Entrada/Saida.
A unica coisa que fiz para não sobrecarregar o formulário na exibição de dados, é criar eventos para as TabPages. Ou seja, só mostro os dados,
quando clico na tab especifica.

Ao pesquisar um item, eu alimento a classe produto, com o item escolhido.
Algo como :
Controle.Produto.RetornaProduto(txtPesquisaProduto.Text);
Se localizar o produto, faço um mapeamento da classe, populando os campos do formulário.
Segue um exemplo da tela





Grupo DotNet.Br no FaceBook

Grupo WhatsDev



#489890 - 09/08/2019 11:02:04

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
Algo ser um conceito, não significa "vou pegar algumas partes e fazer o resto de qualquer outro jeito". Usando a mesma analogia do marceneiro:
- Você quer fazer uma mesa com 4 pés e um tampo
- Você vai precisar de madeira, parafusos, cola e pregos
- As ferramentas que você tem são: um martelo e um alicate.
Como fazer:
1 - Fazendo as pernas: como você não está usando um serrote, você pega um pedaço de madeira e vai martelando e desbastando com o alicate até virar algo parecido com uma perna. Repita o procedimento mais 3 vezes, uma vez para cada perna.
2 - Fazendo o tampo: As tabuas que você tem, devem ser combinadas, colocando-as uma ao lado da outra para fazer um quadrado que será novamente desbastado à marteladas até ficar redondo
3 - Com o tampo recortado, coloque outras tabuas na parte inferior para unir às tabuas do tampo. Como você não tem uma trena, você precisa medir à olho e martelar até cortar a tábua no tamanho adequado

Acho que já deu pra entender. O fato de ser um conceito, não significa que vou pegar o que entendi e sair fazendo o resto "do jeito que sei". O conceito é o modo como a coisa funciona e não uma "guideline". Como todo conceito, ele é adaptável e pode ser unido à outros, mas não é bem isso que está fazendo.

_______________________________________________________________________
Virei Oráculo!
The end is nigh, be ready for the nukes!


#489892 - 09/08/2019 12:23:20

FOXMAN
BARRETOS
Cadast. em:Janeiro/2001


Membro da equipe

Última edição em 09/08/2019 12:29:31 por FOXMAN

Citação:
  - Você quer fazer uma mesa com 4 pés e um tampo
- Você vai precisar de madeira, parafusos, cola e pregos
- As ferramentas que você tem são: um martelo e um alicate.


Citação:
Escolhemos nossas ferramentas, e "fabricamos" algo.


Como citei na minha analogia. Escolhemos nossas ferramentas, e fabricamos.
Se vc escolher Martelo e Alicate para fabricar uma mesa, certamente irá sofrer mais do que eu . Que escolheria um Serrote, um martelo, e para facilitar ainda mais, uma plaina.
Desta forma , eu Escolhi as melhores ferramentas, para fabricar o mesmo produto.
Há ainda quem já adquire os pés prontos, o tampo plainado, e de quebra um manual, de como montar a mesa.

O produto FINAL, será MESA.
Independentemente de como ele foi fabricado.
Neste cenário, o conceito é uma idéa, e a idéia é fazer uma MESA.

Algum dia, alguém, em algum lugar. Definiu POO como um paradigma, que facilita o desenvolvimento de um sistema.
Esta pessoa é Alan Klay.
No entanto há no nosso universo, programadores renomados que fazem criticas a POO, num contexto de facilidade de desenvolvimento.
Abaixo algumas crítcas desse programadores :

Citação:
Joe Armstrong: "O problema com linguagens orientadas a objetos é que você tem todo esse ambiente implícito que elas levam consigo. Você queria uma banana mas o que você conseguiu foi um gorila segurando a banana e uma selva inteira."[5]

Alexander Stepanov: "Dizer que tudo é um objeto é simplesmente dizer nada."

Steve Yegge: "Por que alguém iria tão longe para colocar um só aspecto da fala [substantivos] em um pedestal?"[6]

Eric Steven Raymond: "A POO encoraja programas com muitas camadas e destrói a transparência."[7]

Rob Pike: "A POO constitui os números romanos da computação."[8]
  

A fonte das citações acima são do wiki.

É possível observar que não há um concenso geral, da aplicabilidade de POO.
Eu mesmo utilizo parte desse conceito.

Citação:
  Acho que já deu pra entender. O fato de ser um conceito, não significa que vou pegar o que entendi e sair fazendo o resto "do jeito que sei". O conceito é o modo como a coisa funciona e não uma "guideline". Como todo conceito, ele é adaptável e pode ser unido à outros, mas não é bem isso que está fazendo.  


Discordo  quando vc diz
Citação:
O conceito é o modo como a coisa funciona  

Conceito é uma IDEIA de como a coisa funciona.

Você pode aplicar o conceito, e até mesmo criar um NOVO conceito, tendo como base o conceito original.
Isso aconteceu com o conceito CAMADAS.
Que antes eram 3 camadas, depois 4, e hoje temos N-Tier.

No meu caso especificamente, eu sou o Analista, o projetista, o desenvolvedor, o dono, o tudo.
Eu determino o meu CONCEITO.

O meu conceito se baseia no PRINCIPIO DE KISS.
Citação:

Keep It Simple, Mantenha Simples em português (ou : KISS principle acrônimo em inglês de: Keep It Simple, Stupid e também um trocadilho de "princípio do beijo", ou seja, Mantenha Simples, Estúpido) é um princípio geral que valoriza a simplicidade do projeto e defende que toda a complexidade desnecessária seja descartada. Serve como fórmula útil em diversas áreas como o desenvolvimento de software, a animação, a engenharia no geral e no planejamento estratégico e táctico.


EDIT:
Algumas relações ao PRINCIPIO DE KISS....

Citação:

Este princípio provavelmente teve a sua inspiração nos princípios da Navalha de Occam, e das máximas de Leonardo da Vinci "Simplicidade é o último grau de sofisticação", Mies Van Der Rohe "Menos é mais", Albert Einstein "Tudo deve ser feito da forma mais simples possível, mas não mais simples que isso", de Antoine de Saint-Exupéry "A perfeição é alcançada não quando não há mais nada para adicionar, mas quando não há mais nada que se possa retirar").



Grupo DotNet.Br no FaceBook

Grupo WhatsDev



 Tópico anterior Próximo tópico Novo tópico


Para responder este tópico o login é requerido
Se você já possui uma conta de usuário por favor faça seu login
Se você não possui uma conta de usuário use a opção Criar usuário