Infalíveis 'n' Camadas ;)

Programação Arquitetura
#21

Olá…

Então dentre os quatro andares que citou (Serviços, Negócio, Controle e Apresentação) qual será a responsabilidade do andar de controle?
E obrigada pela explicação da comunicação explicita e implícita entre andares, não conhecia. :smiley: Até +[/quote]

Controle seria o intermediário entre a apresentação e os serviços (que, por sua vez, se comunica com a camada de negócio). Se ficar mais confortável, pode também adicionar o Façade aí (aí fica a camada de controle entre a apresentação e os façades). Eu não gosto muito do padrão Façade pois trabalho com SOA, e esse padrão tende a complicar mais do que facilitar pra mim.

[]´s[/quote]
Olá asaudate…
Legal, não conhecia esse andar que falou. Acreditava que a comunicação do andar de Apresentação com o andar de Negócio/Domínio era direta, ou seja, se o andar de Apresentação está implementado em MVP, os models que lá estão chamarão diretamente os métodos das classes do domínio. Se criar um Façade para as classes de domínio, esse Façade pertencerá ao andar de Domínio, não?

Obrigada :D[/quote]

Sim , pertence ao domínio. Na verdade, as fachadas são usadas só para facilitar o acesso entre as camadas (veja o post do André Fonseca), ou seja, é como se elas estivessem no topo da camada, mas ainda pertecem a ela.

[]´s[/quote]
Entendi… mas então qual é a especialidade do andar de controle?
Assim, até o momento estou entendendo assim: Cliente, Apresentação, Negócio/Domínio, Integração e Recursos.

Obrigada mais uma vez :D[/quote]

Peraí que isso tá virando uma salada =P

Antes de mais nada, cuidado com esse monte de camadas (juro que nunca tinha ouvido alguém falar o termo “andar”). Segundo, o Controle de que estou falando é o C do MVC , e tenho certeza de que isso não pode ser considerado como uma camada por si só. Dito isto, a comunicação, na estrutura que você citou, fica assim:

Desculpe o desenho tosco (fiz no paint, mesmo), mas a idéia é essa.

[]´s
[/quote]
Oi, desculpe pela “salada”. Agora entendi, você está falando de Controle do MVC, desculpe. Já a palavra ‘andar’ define uma camada lógica.
É que eu aprendi diferente. MVC, para mim, está lá no andar Cliente e o MVP está no andar Apresentação.
No MVP, as classes responsáveis pela comunicação com o andar inferior são os modelos, ou melhor, o M do MVP.

E tanto MVC quanto MVP estão no andar, ou seja, M-V-P ‘as três letras’ estão juntas no andar x e não espalhadas pelos andares x,y,z. Foi assim que aprendi, desculpe… eu sei que isso é um assunto muito discutido aqui no fórum como pode conferir neste tópico.

Obrigada pela sua ajuda… Até…

#22

[quote=ingridfarabulini]
Oi, desculpe pela “salada”. Agora entendi, você está falando de Controle do MVC, desculpe. Já a palavra ‘andar’ define uma camada lógica.
É que eu aprendi diferente. MVC, para mim, está lá no andar Cliente e o MVP está no andar Apresentação.
No MVP, as classes responsáveis pela comunicação com o andar inferior são os modelos, ou melhor, o M do MVP.

E tanto MVC quanto MVP estão no andar, ou seja, M-V-P ‘as três letras’ estão juntas no andar x e não espalhadas pelos andares x,y,z. Foi assim que aprendi, desculpe… eu sei que isso é um assunto muito discutido aqui no fórum como pode conferir neste tópico.

Obrigada pela sua ajuda… Até…[/quote]

Que é exatamente o que eu “tentei” desenhar =P (MVP e MVC são praticamente a mesma coisa, caso você tenha notado). No desenho que mandei, o MVC está na camada Cliente. O resto… bom, é o resto.

Espero que esteja fazendo um pouco mais de sentido para você.

[]´s

#23

[quote=asaudate][quote=ingridfarabulini]
Oi, desculpe pela “salada”. Agora entendi, você está falando de Controle do MVC, desculpe. Já a palavra ‘andar’ define uma camada lógica.
É que eu aprendi diferente. MVC, para mim, está lá no andar Cliente e o MVP está no andar Apresentação.
No MVP, as classes responsáveis pela comunicação com o andar inferior são os modelos, ou melhor, o M do MVP.

E tanto MVC quanto MVP estão no andar, ou seja, M-V-P ‘as três letras’ estão juntas no andar x e não espalhadas pelos andares x,y,z. Foi assim que aprendi, desculpe… eu sei que isso é um assunto muito discutido aqui no fórum como pode conferir neste tópico.

Obrigada pela sua ajuda… Até…[/quote]

Que é exatamente o que eu “tentei” desenhar =P (MVP e MVC são praticamente a mesma coisa, caso você tenha notado). No desenho que mandei, o MVC está na camada Cliente. O resto… bom, é o resto.

Espero que esteja fazendo um pouco mais de sentido para você.

[]´s[/quote]
Você está me ajudando, mas levantou uma questão curiosa.Desculpa mas não consigo entender o andar de apresentação dentro do andar cliente.
Veja este tópico, irá colocá-lo exatamente na postagem que fiz. Na postagem está a implementação completa da camada/andar de apresentação usando MVP para uma agenda. Se esse código pertence ao andar de apresentação, o que pertenceria ao andar de cliente, então?

Obrigada pela ajuda :smiley:

#24

Vc entendeu certo.

Parta do modelo standalone. Onde tudo está na mesma máquina, inclusive o banco que é embutido dentro da aplicação. Não ha qq comunicação de rede neste modelo.
Agora vamos colocar o banco na mesma máquina, mas ligado via TCP/IP. O banco não está mais embutido e o andar de recursos do nodo standalone não mais contém o banco. A aplicação não é mais standalone. Porque o banco está ligado À aplicação o andar de integração tem que compensar esse fato, já que, para o resto dos andares superiores as coisas não mudaram.

Agora imagine que colocamos um servidor de aplicação nessa historia. A aplicação que era standalone e 1-tier, e virou 2-tier, agora virou 3-tier. Movemos a logica de negocio (dominio) para o servidor. O andar dominio que tinhamos no standalone foi agora para o servidor de aplicação. Então o andar dominio na aplicação tem que compensar esse fato. Ele irá ser apenas uma fchada para o andar de intergração que se irá comunicar com o servidor de aplicação onde estão o dominio e o SA irá se comunicar com o banco.

Veja que cada nodo continua tendo os mesmo andares, mas a implementação deles muda. Normalmente muda para um esquema de delegação/comunicação remota.
Veja que ao incluir o servidor de aplicação ele é um novo nodo com os 5 andares. Mas a implementação é diferente. O andar cliente, por exemplo, não será swing, nem web, serão webservices, REST ou interfaces RMI. A apresentação será o andar que (como sempre) mapeia o dominio para o cliente. O andar apresentação original não mudou nada e continua controlando o funcionamentoe das telas swing.

Quando os andares estão bem separados, esta explosão para n-tier é natural e simples. (Se não é simples é porque os andares não estão bem separados).

Respondendo À sua outra pergunta sobre comunicação de camadas: o que está em causa não é a comunicação em si, mas o conhecimento da responsabilidade.
A camada ( estou falando genericamente aqui, pode ser nodo, andar,… qq tipo de camda) superior conhece a responsabilidade da camada inferior, mas a inferior não conhece
a responsabilidade da camada superior. A razão para isso é simples: uma camada pode ter N camadas superiores diferentes.Por isso é muito importante separar bem as responsabilidades e nunca usar logicas do tipo “aqui no dominio eu vou fazer assim porque lá na apresentação eu faço assado” A implementação da camada inferior não pode assumir nada sobre as camadas superiores. (Em particular pode nem haver um camada superior).

Repare que eu disse que a camada superior conhece a responsabilidade da inferiro, eu não disse que conhece a implementação. Por exemplo, se apresentação faz uso de um serviço de dominio, ela conhece o que o serviço faz, mas ela não sabe - nem deve saber - se o serviço é local ou remoto, se é EJB ou webservices,se usa List ou Set, etc…

O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.

#25

Olá Sérgio, tudo bem com você moço?
Obrigada + uma vez me ajudar :oops:

[quote=sergiotaborda]Parta do modelo standalone. Onde tudo está na mesma máquina, inclusive o banco que é embutido dentro da aplicação. Não ha qq comunicação de rede neste modelo.
Agora vamos colocar o banco na mesma máquina, mas ligado via TCP/IP. O banco não está mais embutido e o andar de recursos do nodo standalone não mais contém o banco. A aplicação não é mais standalone. Porque o banco está ligado À aplicação o andar de integração tem que compensar esse fato, já que, para o resto dos andares superiores as coisas não mudaram.

Agora imagine que colocamos um servidor de aplicação nessa historia. A aplicação que era standalone e 1-tier, e virou 2-tier, agora virou 3-tier. Movemos a logica de negocio (dominio) para o servidor. O andar dominio que tinhamos no standalone foi agora para o servidor de aplicação. Então o andar dominio na aplicação tem que compensar esse fato. Ele irá ser apenas uma fchada para o andar de intergração que se irá comunicar com o servidor de aplicação onde estão o dominio e o SA irá se comunicar com o banco.

Veja que cada nodo continua tendo os mesmo andares, mas a implementação deles muda. Normalmente muda para um esquema de delegação/comunicação remota.
Veja que ao incluir o servidor de aplicação ele é um novo nodo com os 5 andares. Mas a implementação é diferente. O andar cliente, por exemplo, não será swing, nem web, serão webservices, REST ou interfaces RMI. A apresentação será o andar que (como sempre) mapeia o dominio para o cliente. O andar apresentação original não mudou nada e continua controlando o funcionamentoe das telas swing.
[/quote]
Sérgio, preciso entender algumas coisas… :roll:

1 - Quando o banco de dados passa a ser ligado via TCP/IP na mesma máquina, transformando Standalone em 2-Tier, passamos a ter dois nodos : nodo cliente e nodo banco. Como o andar Integração do nodo cliente precisa compensar o fato da mudança ‘passa a interagir com o andar Cliente do nodo banco’ o andar Recursos, ainda do nodo cliente, simplesmente vai estar lá porém sem atividade alguma?
2 - Quando passamos do 2-Tier para o 3-Tier entra a existência de pelo menos três nodos : cliente, servidor de aplicação ‘SA’ e dados. Então passamos a ter a seguinte hierarquia : nodo cliente, andar Integração fala com nodo SA, andar Cliente. Nodo SA, andar Integração fala com nodo dados, andar Cliente. Se isso está certo, me resta repetir a mesma pergunta da nº1 : o andar Recursos dos nodos cliente e SA simplesmente vão estar lá, porém sem atividade alguma? Ou estou enganada e existe alguma atividade alí?
3 - O nodo banco pode ser, como exemplo, um SGBD? ‘Postgree, MySQL,…’

[quote=sergiotaborda][quote=ingridfarabulini]
E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?
[/quote]
O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.
[/quote]
Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?
Desculpa minha confusão, acabei não entendendo Sergio. Pensei que aquele MVP todo estivesse no andar Apresentação, agora eu nem sei o que deve estar no andar Apresentação… :shock:
Busquei ajuda no link do Java Building mas ainda assim fiquei confusa… :frowning:

Obrigada por me acompanhar :smiley: Vou aguardar pela resposta…
Por favor, nao quero atrapalhar… Até + :wink:

#26

[quote=FrancoC][quote=sergiotaborda]

Quando falamos de software temos que falar primeiro em plataformas e andares e entender que dentro dos andares termos camadas de API. Nas traduções se perde muito dos conceitos. Em inglês temos Platform (plataforma), store (andar), tier (nodo) e layer (camada). Cada um representa uma coisa diferente, mas é comum as pessoas chamarem tudo de layer. A culpa é principalmente do padrão Layer que popularizou essa nomenclatura. [/quote]

Achei um tanto quanto desgradavel tuas escolhas na tradução dos termos store e tier. É comum traduzirem node por nodo ou nó, mas de tier para nodo é novidade pra mim. E store remete ao conceito de armazenagem, estocagem, depósito, estas coisas. O que houve com a palavra floor para andar?
[/quote]

Desculpem, na realidade é um erro de escrita. A palavra certa é story (andar) (“How high is a three story building ?”)
Floor significa “piso” , o chão. Piso refere-se à area onde se pode andar, story se refere ao volume necessário ao piso e à estrutura do prédio que suporta esse volume.

Por isso que traduzo story por andar.

Essa fonte define tier como

Isso não é tier, é plataforma.

O termo tier realmente normalmente é fisico e pode ser usado para se referir a um conjunto de nodos. Contudo, numa arquiterura cada nodo sempre é um template para muitos nodos. E nessa prespetiva são equivalentes. eu não gosto muito de me referir a tier, mas no texto que citou foi necessário.

como vc mesmo disse é uma area controversa ( a tradução , não tanto os termos originais). A ideia é abolir o uso de layer e tier porque são ambiguos. Desambiguidade é a primeira diretiva para termos termos tecnicos mais , digamos, “cientificos”.

O que importa é que se tenha entendido o conceito.

Se vc identificar andar com camada lógica, vc terá o problema de não ter um conceito para camada de código e ai será forçado a usar o mesmo nome para tudo, que é muito ruim para a comunicação clara.

#27

correto.

É dificil o andar de recurso não estar lá. Arquivos de configuração, e os próprios jar estão neste andar.

O andar do nodo cliente antes usada uma configuração jdbc local. digamos que usava HSQL. Agora ele tem que usar uma configuração remota.
Como o JDBC é bem desenhado ( um dos melhores exemplos de desenho de API) na prática vc muda o url de definição,mas em outras tecnologias e plataformas (delhpi, .net) não é assim tão simples e têm que ser feitas alterações no codigo.

a sua lógica está certa. a unica coisa que vc está esquecendo é que "Recurso’ não é apenas o banco de dados e “Dado” não é apenas que é persistido no banco. Por exemplo, se seu sistema é i18n vc terá um properties com as mesnagems e textos, isso tb é um recurso. E como disse o proprio jar é um recurso. Mesmo se vc tiver apenas um banco remoto, vc tem que configurar os parametros de enderço em algum lugar. isso é um recurso.

A aplicação no nodo banco é um SGDB. O SGDB contém os andares necessários e ele corre sobre uma plataforma.
O SGDB não é o nodo todo, é um item no nodo.

O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.
[/quote]
Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?
[/quote]

Não sei como vc conclui isso. O MVP pertence na apresentação. O V é o elo de conexão ao andar cliente e o M ao andar dominio e inferiores.
O que eu disse é que o que se constroi com swing, telas, janelas, buttões, etc… isso é o cliente. Por exemplo, se vc decidir que quando o cara aperta um botão vc emite um som, isso é apenas responsabilidade do cliente. nenhuma outro andar sabe dessa feature.

#28

[quote=sergiotaborda][quote]

[quote=sergiotaborda][quote=ingridfarabulini]
E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?
[/quote]
O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.
[/quote]
Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?
[/quote]
Não sei como vc conclui isso. O MVP pertence na apresentação. O V é o elo de conexão ao andar cliente e o M ao andar dominio e inferiores.
O que eu disse é que o que se constroi com swing, telas, janelas, buttões, etc… isso é o cliente. Por exemplo, se vc decidir que quando o cara aperta um botão vc emite um som, isso é apenas responsabilidade do cliente. nenhuma outro andar sabe dessa feature.
[/quote]
Oi Sergio, obrigada pelas respostas. Entendi suas explicações e acho que agora vou saber até perguntar melhor o que realmente procuro entender. No nodo Cliente, andar Apresentação que é onde está o MVP, a porta de entrada desse andar é o V. Mas, o que conterá/estará no V? Telas em Swing é que não será, visto que isso pertence ao andar Cliente. O MVP deve estar mesmo no andar Apresentação ou no andar Cliente?

Obrigada :smiley:

#29

[quote=ingridfarabulini][quote=sergiotaborda][quote]

[quote=sergiotaborda][quote=ingridfarabulini]
E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?
[/quote]
O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.
[/quote]
Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?
[/quote]
Não sei como vc conclui isso. O MVP pertence na apresentação. O V é o elo de conexão ao andar cliente e o M ao andar dominio e inferiores.
O que eu disse é que o que se constroi com swing, telas, janelas, buttões, etc… isso é o cliente. Por exemplo, se vc decidir que quando o cara aperta um botão vc emite um som, isso é apenas responsabilidade do cliente. nenhuma outro andar sabe dessa feature.
[/quote]
Oi Sergio, obrigada pelas respostas. Entendi suas explicações e acho que agora vou saber até perguntar melhor o que realmente procuro entender. No nodo Cliente, andar Apresentação que é onde está o MVP, a porta de entrada desse andar é o V. Mas, o que conterá/estará no V? Telas em Swing é que não será, visto que isso pertence ao andar Cliente. O MVP deve estar mesmo no andar Apresentação ou no andar Cliente?
[/quote]

Do ponto de vista do MVP o V é conjunto pré-definido de classes e interfaces que o presenter pode manipular sem ter que saber o que está além do V.
Na prática, o V comunica diretamente com o cliente swing. Imagine que vc tem o swing implementando essas interfaces e classes do V.
São prespetivas diferentes da mesma coisa. A relação que vc tem com a sua mae é de relação é a mesma que ela tem consigo, mas na sua prespetiva é uma relação filha-mae, mas na dela é mae-filha. mas a relação é uma só.
No OO das camadas sempre existe uma fronteira onde , a partir dali, vc não conhece mais o que acontece , vc tem que confiar nos contratos dos objetos / interfaces. O presenter confiar que o V saberá comunicar com que interessa, o cliente implementa o V para que possa delegar ao presenter algumas decisões.

Acho que agora vai confundir de vez :slight_smile: Mas o truque está em entender cada camada por si e depois entender o que acontece na fronteira. Na fronteira vc tem interfaces de uma camada sendo implementada pela outra.

#30

quem aprende design patterns só estudando, se torna péssimo programador; o q complica coisas simples. durante sua experiencia naturalmente vai reconhecer a necessidade.
não precisa ir atrás de design patterns, eles vem até vc :wink:

editado:
lógico, estou dizendo isso partindo do principio q vc é inciante.

#31

[quote=bobmoe][quote=ingridfarabulini]
Faz pouquíssimo tempo que estudo Java ‘um ano e meio aprox.’ e sempre escrevi meus programas sem seguir nenhum pattern ou qualquer tipo de arquitetura. Mas de uns meses para cá estou interessada em seguir alguns padrões mínimos para um bom desenvolvimento ‘ou pelo menos que facilite a vida de qualquer programador(a) quando necessário realizar alguma manutenção neste código’. Pensando nisso iniciei meus estudos com o pattern Layers, ou camadas lógicas, como preferir.
[/quote]
quem aprende design patterns só estudando, se torna péssimo programador; o q complica coisas simples. durante sua experiencia naturalmente vai reconhecer a necessidade.
não precisa ir atrás de design patterns, eles vem até vc :wink:

editado:
lógico, estou dizendo isso partindo do principio q vc é inciante.

[/quote]

Tenho que discordar. O objetivo de estudar design patterns não é ser um bom programador. é ser um bom designer. E se o design é bom, a programação é trivial. Acontece que muita gente acha que qualquer tipo de design vale. Que se muda depois, KISS essa palermice toda… na realidade não é trivial conseguir um bom design e se a pessoa almeja um dia ser um bom designer, precisa sim aprender patterns.

Saber patterns é saber uma linguagem diferente. Ajuda a pensar. Ajuda a simplificar. Ajuda a se tornar um desenvolvedor melhor e mais eficaz.
Em particular os design patterns o tornam um melhor designer, mas outros tipos de patterns ajudam noutras areas ( arquiteura, requisitos, etc…)

Eu parabenizo a Ingrid e as pessoas que, como ela, entendem que o design é um passo importante para ser um bom desenvolvedor.
Não é possivel ser um bom desenvolvedor de software apenas sabendo programar. E até para programar bem - threads, por exemplo - vc precisa saber desenhar. Não é possível construir uma aplicação multithread usando o debuger e a força bruta…

Em particular, a Ingrid mostrou no outro tópico (neste tb, mas especialmente no outro) que embora com pouca experiência consegue entender conceitos como MVC e MVP e implementá-los. Coisa que muita gente aqui não conseguiu fazer em anos. Tem muitos que nem sabem o que é MVC e não é por falta de pessoas explicando…

Sinceramente esta conversa que padrões é ruim e não ha que se preocupar com eles é coisa de pessoas que não ou não entenderam até hoje o que é um design pattern e sua utilidade, ou que tentam avacalhar com a profissão dos outros. Patterns são importantes sim. Em todos os ramos, não apenas em software. Live with it!

Um péssimo programador só é péssimo exatamente porque nunca estudou. E estudar não significa ler. Significa entender e saber aplicar.
Não vale dizer que porque 90% dos desgraçados não sabem aplicar singleton ou <coloque um padrão aqui> então padrões é algo ruim e não merece a pena aprender.

Design patterns não é sobrengenharia. Parem de dizer que é.

#32

[quote=sergiotaborda][quote=ingridfarabulini][quote=sergiotaborda][quote]

[quote=sergiotaborda][quote=ingridfarabulini]
E uma pergunta: Como quero desenvolver minha agenda com Swing, dos cinco andares do meu nodo ( Arq. Standalone ), para minha agenda especificamente, posso dizer que o andar Cliente é o Swing em sí (o ‘menino bonito’, q lindo :P) e o andar Apresentação seria o MVP que me ajudou a fazer no outro tópico?
[/quote]
O Swing em si é apenas uma API java. Aquilo que vc constroi com ele, é que é o cliente. Ou seja, o cliente é aquele conjunto de telas, com botões num certo lugar com campos em certo lugar, etc… que vc criou. O cliente é montado em swing, mas não é o swing em si mesmo, é aquilo que vc montou com swing. Se eu usar o swing e montar diferente, terei um cliente diferente.
[/quote]
Então o MVP que me ajudou a criar no outro tópico não está no andar Apresentação e sim no andar Cliente?
[/quote]
Não sei como vc conclui isso. O MVP pertence na apresentação. O V é o elo de conexão ao andar cliente e o M ao andar dominio e inferiores.
O que eu disse é que o que se constroi com swing, telas, janelas, buttões, etc… isso é o cliente. Por exemplo, se vc decidir que quando o cara aperta um botão vc emite um som, isso é apenas responsabilidade do cliente. nenhuma outro andar sabe dessa feature.
[/quote]
Oi Sergio, obrigada pelas respostas. Entendi suas explicações e acho que agora vou saber até perguntar melhor o que realmente procuro entender. No nodo Cliente, andar Apresentação que é onde está o MVP, a porta de entrada desse andar é o V. Mas, o que conterá/estará no V? Telas em Swing é que não será, visto que isso pertence ao andar Cliente. O MVP deve estar mesmo no andar Apresentação ou no andar Cliente?
[/quote]

Do ponto de vista do MVP o V é conjunto pré-definido de classes e interfaces que o presenter pode manipular sem ter que saber o que está além do V.
Na prática, o V comunica diretamente com o cliente swing. Imagine que vc tem o swing implementando essas interfaces e classes do V.
São prespetivas diferentes da mesma coisa. A relação que vc tem com a sua mae é de relação é a mesma que ela tem consigo, mas na sua prespetiva é uma relação filha-mae, mas na dela é mae-filha. mas a relação é uma só.
No OO das camadas sempre existe uma fronteira onde , a partir dali, vc não conhece mais o que acontece , vc tem que confiar nos contratos dos objetos / interfaces. O presenter confiar que o V saberá comunicar com que interessa, o cliente implementa o V para que possa delegar ao presenter algumas decisões.

Acho que agora vai confundir de vez :slight_smile: Mas o truque está em entender cada camada por si e depois entender o que acontece na fronteira. Na fronteira vc tem interfaces de uma camada sendo implementada pela outra.
[/quote]
Oii Sergio, nossa muito obrigada por continuar ajudando… :smiley:
Entendi direitinho a explicação. :smiley:

Independentemente do design pattern que vou usar no andar Cliente ele sempre terá uma classe que fará o output de dados para o input dos mesmos no andar Apresentação. Sendo assim…
No caso do andar Cliente estar com o pattern MVC presente, o V ( que pode ser uma Janela Swing ) fará o input dos dados do usuário para este andar e o M ( que é o modelo onde estão os dados que V está apresentando ) fará o output dos dados desse andar para fora. Esse output do andar Cliente é quem fará o input no andar Apresentação. Se no caso do andar Apresentação estar com o pattern MVP presente, o V ( que pode ser uma interface implementada pelo M do andar Cliente ) fará o input dos dados ( dados do output do M do andar Cliente ) para este andar e o M ( que é o modelo onde estão os dados que V recebeu ) fará o output dos dados desse andar para fora. Esse output do andar Apresentação é quem fará o input no andar Domínio… e assim continuando a cadeia de andares.

Se isso estiver certo, o desenho dessa construção é simplesmente perfeita. Poderia executar atividades internas dentro de cada andar independente dele conhecer ou não o próximo andar. Claro que quando necessário ele vai precisar descer para a camada inferior mas caso não precise ele poderá se manter exercendo uma determinada atividade importante somente para aquele andar sem precisar passar pelos demais, não é demaiiisss??

Agora fiquei ansiosa pela resposta… Até +, obrigada :smiley:

#33

Bom, é isso ai. Não tenho mais nada a acrescentar.

#34

[quote=sergiotaborda][quote=bobmoe][quote=ingridfarabulini]
Faz pouquíssimo tempo que estudo Java ‘um ano e meio aprox.’ e sempre escrevi meus programas sem seguir nenhum pattern ou qualquer tipo de arquitetura. Mas de uns meses para cá estou interessada em seguir alguns padrões mínimos para um bom desenvolvimento ‘ou pelo menos que facilite a vida de qualquer programador(a) quando necessário realizar alguma manutenção neste código’. Pensando nisso iniciei meus estudos com o pattern Layers, ou camadas lógicas, como preferir.
[/quote]
quem aprende design patterns só estudando, se torna péssimo programador; o q complica coisas simples. durante sua experiencia naturalmente vai reconhecer a necessidade.
não precisa ir atrás de design patterns, eles vem até vc :wink:

editado:
lógico, estou dizendo isso partindo do principio q vc é inciante.

[/quote]

Tenho que discordar. O objetivo de estudar design patterns não é ser um bom programador. é ser um bom designer. E se o design é bom, a programação é trivial. Acontece que muita gente acha que qualquer tipo de design vale. Que se muda depois, KISS essa palermice toda… na realidade não é trivial conseguir um bom design e se a pessoa almeja um dia ser um bom designer, precisa sim aprender patterns.

Saber patterns é saber uma linguagem diferente. Ajuda a pensar. Ajuda a simplificar. Ajuda a se tornar um desenvolvedor melhor e mais eficaz.
Em particular os design patterns o tornam um melhor designer, mas outros tipos de patterns ajudam noutras areas ( arquiteura, requisitos, etc…)

Eu parabenizo a Ingrid e as pessoas que, como ela, entendem que o design é um passo importante para ser um bom desenvolvedor.
Não é possivel ser um bom desenvolvedor de software apenas sabendo programar. E até para programar bem - threads, por exemplo - vc precisa saber desenhar. Não é possível construir uma aplicação multithread usando o debuger e a força bruta…

Em particular, a Ingrid mostrou no outro tópico (neste tb, mas especialmente no outro) que embora com pouca experiência consegue entender conceitos como MVC e MVP e implementá-los. Coisa que muita gente aqui não conseguiu fazer em anos. Tem muitos que nem sabem o que é MVC e não é por falta de pessoas explicando…

Sinceramente esta conversa que padrões é ruim e não ha que se preocupar com eles é coisa de pessoas que não ou não entenderam até hoje o que é um design pattern e sua utilidade, ou que tentam avacalhar com a profissão dos outros. Patterns são importantes sim. Em todos os ramos, não apenas em software. Live with it!

Um péssimo programador só é péssimo exatamente porque nunca estudou. E estudar não significa ler. Significa entender e saber aplicar.
Não vale dizer que porque 90% dos desgraçados não sabem aplicar singleton ou <coloque um padrão aqui> então padrões é algo ruim e não merece a pena aprender.

Design patterns não é sobrengenharia. Parem de dizer que é.[/quote]

Cara, sou obrigado a concordar com tudo que você disse.
No ponto em que você citou MVC e chuto algo em torno de 80% das pessoas que dizem saber MVC não tem a menor idéia do que estão falando e acham que sabem.
Outro ponto:

Perfeito! É o que sempre digo, poxa, ta lá! qualquer um pode ler, estudar, perguntar, quebrar a cabeça, fazer errado e… aprender! Dedicação é a palavra chave!

Lógico que, como citei em outro tópico a pouco, há pessoas que não tem o menor feeling pra coisa, mas principalmente pessoas que não aprendem por que nunca tiveram um bom professor (no caso das não auto-didatas) que lhe desse um bom começo.

Digo isso por que toda vez que vou tentar explicar algo pra alguém parto de um princípio básico:
1- Explico da forma que gostaria que tivessem me ensinado;

Simples!

Ensinei/expliquei algumas coisas de orientação a objetos pra minha sogra que é advogada! Claro que o conhecimento de programação dela é nulo, mas sempre há meios que você possa usar, analogias existem para isso (se bem utilizadas).

#35

Olá rapazes :smiley: Olá Sérgio, tudo bem? Obrigada por me ajudar!

Hoje comprei uma revista que me fez notar que o MVP é um padrão da Camada/Andar de Apresentação. Ótimo 8)
E também já sei que a Camada/Andar de Apresentação está abaixo da Camada/Andar de Visualização/Cliente.
Hierarquia: [ Visualização/Cliente --> Apresentação --> Domínio/Negócio --> Integração --> Recurso ]
Estou fazendo minha Agenda em Swing…

A primeira pergunta: Qual será o pattern apropriado da Camada/Andar de Visualização/Cliente para trabalhar com o Swing?
A segunda pergunta: Quem é a classe responsável em fazer o output da Camada/Andar de Cliente/Visualização para a Camada/Andar de Apresentação?

Desculpem pelo meu desconhecimento… :frowning:
Obrigada :smiley: Ficarei no aguardo…

#36

humm… o swing em si já segue padrão como composite e observer.
Tlv o que vc precisa nesse ponto não são padrões per se mas formas de trabalhar. Coisas como Separation of Concerns , DRY (Dont repeat yoursefl), variáveis polimorficas ( aka Programar para interfaces) encapsulamento, são essenciais práticas OO presentes em qq camada/andar/nodo

Construir telas swing OO é um desafio no incio, mas rápidamente vc entende como.

Lembre-se que o swing será visto pelo presenter através de interfaces e objetos da view. Portanto o swing tem que ser utilizado como uma ferramenta para implementar a view que o presenter espera.

Esta eu não sei se entendi.
Suponho que vc esteja pensando em formulário que tem um botão salvar. Acho que a sua pergunta é :" quem responde a esse save?"
Resposta : O presenter desse formulário.

Entenda que o output do cliente e o input da apresentação se sobrepoem em um unico objeto ( por exemplo, no caso, o event handler do botão).

não sei se respondi…

#37

Tb concordo com vc. Mas eu chamo a esse felling : “Talento”.
Se a pessoa não tem algum talento natural para a área, ela nunca irá compreender. Estudando ela poderá até saber e aplicar,mas nunca poderá compreender o suficiente para inovar e/ou se aproveitar do que aprendeu em um “lado” para aplicar no 'outro".

O bom professor é aquele que o ensina a pensar, não aquele que dita a resposta.

O problema da área é que temos muitas pessoas tem talento. E as que o têm não têm opção para o desenvolver.
É comum que uma pessoa com talento que entra como estagiário ou junior (às vezes até mesmo como sênior) seja barrado pelo resto da equipa.
É o denominador comum que puxa as pessoas para baixo. Um cara assim, normalmente subjuga-se à pressão e aquele pouco talento que tinha se perde… ou o cara se revolta e parte “para cima da equipe”. Existem várias formas de fazer isso. A mais comum é o cara ir para outro lugar, tlv passando pelo mesmo processo de novo. Depois temos o cara que usa o seu talento para fazer a sua parte do trabalho bem feita e ainda corrige a dos outros sem reclamar ( para isto é essencial um ambiente de codigo compartilhado). E temos o lider silencioso. aquele que pelo exemplo força os outros a seguir as mesmas práticas. Finalmente temos o cara que tenta convencer verbalmente os outros … este se dá muito mal porque a primeira reação da equipa é achar que o cara é arrogante ( na minha experiência, arrogante é quem não tem talento - nem razão - mas impõe sua intenção no grito)

Isso implica que vc conheça do assunto o suficiente para saber como gostaria que lhe tivessem ensinado :wink:
Ter esse conhecimento é isso que destingue um Professor ( com P) de um cara que dita resultados…

#38

Olá Sergio, nossa mais uma vez obrigada! :wink:

Ou seja, a interface do Andar de Apresentação (que será o V do MVP) será implementada no Swing, certo?
Esse objeto da view nada mais é que a classe onde construi a tela do formulário, no caso?

[quote=sergiotaborda]

Esta eu não sei se entendi.
Suponho que vc esteja pensando em formulário que tem um botão salvar. Acho que a sua pergunta é :" quem responde a esse save?"
Resposta : O presenter desse formulário.

Entenda que o output do cliente e o input da apresentação se sobrepoem em um unico objeto ( por exemplo, no caso, o event handler do botão).

não sei se respondi…[/quote]

Essa sobreposição seria isso?

 public void addBotaoCadastrar(ActionListener al) {   
      bCadastrar.addActionListener(al);   
   }

Assim Taborda, acho que você vai entender melhor a minha pergunta: no Andar de Apresentação com MVP o ‘M’ se comunica com o Andar de Domínio, certo? ( Apresentação > Domínio )
No Andar de Cliente com Swing qual classe é responsável em se comunicar com o andar de Apresentação? É a mesma classe onde construi o formulário ( onde instancio os JComponents que são mostrados na tela )?

Porque assim: entendi que no Andar de Cliente existe a classe que é essa onde construo a tela e é onde injeto os listeners do Presenter ( da camada abaixo ) que capturam os events dos componentes no Cliente.

Para ficar melhor ainda: No MVP eu sei que o ‘V’ é o input, o ‘P’ realiza algo interessante para este andar e o ‘M’ é o output. Mas, e no andar Cliente com Swing? Quem é o output? O input eu sei que são as interações do usuário com a tela… mas e o output? Como MVP está na apresentação e não no cliente fiquei sem entender…

O problema é ligar o Cliente a Apresentação.
Vou estudar as dicas de OO que solicitou acima…

Obrigada por me aturar… não sei nem mais o que dizer :oops:
Me ajuda demaissss… além de ser um excelente profissional. Até + :smiley:

#39

[quote=ingridfarabulini]Olá Sergio, nossa mais uma vez obrigada! :wink:

Ou seja, a interface do Andar de Apresentação (que será o V do MVP) será implementada no Swing, certo?
Esse objeto da view nada mais é que a classe onde construi a tela do formulário, no caso?

Pode ser. No seu caso é. Para cada applicação é diferente.

Não. Essa classe não faz parte dos andares. Essa classe faz parte da aplicação ,mas não dos andares.

O M comunica com andar de dominio. Sim. E o andar cliente de comunica com o andar de apresentação. sim.
Mas vc precisa entender que cada andar contém muitiplas comunicações. Por exemplo o andar de apresentação contem diversos presenters , e por consequencia está lidado a difernetes modelos e views. A view é um objeto complexo e não ha um objeto unico que chame o presenter.

Por exemplo, vc quer ter um menu de “sair” que quando clicado termina a aplicação. Mas antes de terminar devemos perguntar o usuário se quer mesmo fazer isso, pois ele pode ter-se enganado. Isto implica que o botão swing, irá invocar um listener swing, que irá chamar o método X do presenter que usará um objeto de view para lançar a pergunta ao usuário, e conforme a resposta, procesguir para o termino ou não fazer nada.
Repare nesse “no meio do jogo volto para trás”. Quando o evento vai para o prenester a view corresponde ao listener que captura o evento do botão.
mas quando o presenter usa a view explicitamente, ele o faz através de uma interface e essa interfce é implementada com objetos swing, por exemplo


class PresenterA {

    private ViewA view;

 public   PresenterA (ViewA view){
      this.view = view;
}

    public void doExit(){
 
              if ( view.confirm("Quer mesmo sair?"){

                      // termina aplicação
                        System.exit(0);
               }

    }

}

interface ViewA {

   public boolean confirm(String message);

}

class Tela extends JFrame implements ViewA{

  
      // monta tela e botões e um deles tem o seguinte listener

       public Listener implements ActionListener{
    
                  public void onAction(...){

                             presenter.doExit();
                    }

     }

  @Override
    public boolean confirm(String message){

         // usa JDialog para perguntar ao usuário
   }

}


public class Montadora {

   public void monta(){
      ViewA viewA = new Tela();
      PresenterA presenter = new PresenterA(viewA );

  }

}

Agora imagine que além do botão vc quer que o mesmo aconteça quando aperta o x na tela. vc precisa de um windowlistener para isso.
Vc implementa isso na Tela e chama o doExit() da mesma forma. O presenter não sabe quem ou de onde foi chamado o método e nem interessa.

Repare que a view é a tela , cada tela será uma view, terá um presenter ou mais do que um presenter.
Agora imagine que todas as telas tem um botão de sair, todas elas invocarão o mesmo presenter, mas a view que o presenter vai invocar é diferente ( é uma tela diferente , mas ele não sabe isso,nem importa, porque a interface é a mesma

O MVP não é 1 para 1. Uma view pode chamar vários presenters, cada presenter ser usado por views diferentes. O mesmo para os models e presenters.

O ponto que precisa entender é que não ha correspondencia um para um. Lembre-se que o padrão observer é 1 para muitos, e isso está sempre implicito no MVP.

#40

[quote=sergiotaborda]

Não. Essa classe não faz parte dos andares. Essa classe faz parte da aplicação ,mas não dos andares.

O M comunica com andar de dominio. Sim. E o andar cliente de comunica com o andar de apresentação. sim.
Mas vc precisa entender que cada andar contém muitiplas comunicações. Por exemplo o andar de apresentação contem diversos presenters , e por consequencia está lidado a difernetes modelos e views. A view é um objeto complexo e não ha um objeto unico que chame o presenter.[/quote]
Entendi quando diz que vários Presenters podem estar usando várias Visões e vários Modelos desse mesmo andar. Mas para que o andar de cima ( andar Cliente ) possa se comunicar com o andar abaixo ( andar Apresentação ) ele precisa implementar ‘pelo menos uma’ ( das ‘n’ ) interfaces do andar abaixo. Até porque entendo que as Visões do andar Apresentação não passam de interfaces para que o andar Cliente possa implementá-las para prover comunicação entre ambos. Agora o que está difícil de entender é do que? o andar Cliente é composto? Quais são as responsabilidades desse andar, ou seja, qual é a função dele? O que deve estar contido nele?.. pensei que era deste andar a responsabilidade de manter as telas que serão exibidas ao usuário… mas já vi que não é. :frowning:

Então poderia dizer que…

  1. …a classe Montadora pertence a Camada de Aplicação ( camada mesmo ) e
  2. a classe Tela pertence ao andar Cliente e
  3. ViewA é uma das ‘n’ Visões do andar Apresentação e
  4. PresenterA é um dos Presenters do Andar Apresentação.

É correto dizer isso? :mrgreen:

Se ainda estiver entendendo algo errado, por favor me avise… :frowning:
Obrigada Sergio :smiley: Desculpa ficar atrapalhando… :frowning: Até mais moço…