Qual é o padrão certo de estruturar o projeto e os pacotes em uma aplicação JAVA Desktop

Programação Java
#1

Galera, estava analisando alguns projetos java desktop e comei a me questionar se a forma da organização de pacotes estava correta,
hoje eu “utilizo o padrão MVC”, mas pesquisando na net cheguei a informação que o próprio Swing já implementa ele,
que o MVC é para o controle de tela.
Notei também que os exemplos que eu estava utilizando usavam um pacote Model que dentro na verdade tem POJOs.

A questão é a seguinte, qual é o padrão certo de estruturar o projeto e os pacotes em uma aplicação JAVA Desktop?
seria assim ?
dao
pojos
views

Nos projetos que eu peguei como exemplo estão assim :
Modelo -> contém na verdade POJOs
VIEW -> contém os JFrames
CONTROLLER -> que só fica fazendo trabalho de ponte para DAO
DAO -> contém os SQLs para cada POJO\entidade do banco

Se possível postem links de projetos com a estrutura correta do git

#2

É um debate interessante e não tenho como dizer o que é o correto, além disso esta abstração extrapola uma linguagem em específico.

Em minha visão, os pacotes devem armazenar classes que estão no mesmo nível.

Por que considerar o mesmo nível?

Se você observar, a indentação se assemelha com a divisão de classes em pacotes, uma vez que você consegue visualizar a hierarquia das instruções.

Mas saindo da indentação e voltando às classes, você pode perceber que faz sentido distribuir as classes em pacotes considerando a hierarquia.

image.png1168×527 9.18 KB

Uma coisa a ser considerada na orientação a objeto é que o espelho desta não é o programador, muito menos 0 e 1.

Citação:
A programação orientada a objetos tem como principais objetivos reduzir a complexidade no desenvolvimento de software e aumentar sua produtividade. … Além do conceito de objeto, a programação OO tem como alicerces os conceitos de encapsulamento, classe, herança e polimorfismo.
Fonte: www.training.com.br/lpmaia/pub_prog_oo.htm

Citação:
Um objeto é um elemento computacional que representa, no domínio da solução, alguma entidade (abstrata ou concreta) do domínio de interesse do problema sob análise. Objetos similares são agrupados em classes. No paradigma de orientação a objetos, tudo pode ser potencialmente representado como um objeto.
Fonte: www.dca.fee.unicamp.br/cursos/PooJava/objetos/conceito.html

A meu ver, a melhor fonte de compreensão da orientação a objeto deve ser os substantivos concretos, pois é mais fácil perceber as diferenças entre níveis hierárquicos.
Depois aquilo que é abstrato e por último os comportamentos compartilhados (essenciais à construção de interfaces).

Agora no campo da percepção, tratar um objeto como um elemento meramente computacional pode fazer você perder o foco em algo simplório, um objeto computacional deve ser a representação de uma entidade, logo, quem deve ser adaptado é o objeto computacional e não o objeto de estudo.

No esboço mal feito que fiz, eu poderia criar varias entidades independentes com foco em desacoplamento, cada entidade com responsabilidades limitadas.

Por exemplo, não cabe ao gerente, implementar a sua tela de consulta pois foge a sua responsabilidade, contudo ele pode ter quantas telas de consulta necessitar podendo explorar seus recursos.

Me limitei a OO, pela forma de abstrair mas creio que possa fazer o mesmo com outras linguagens, pois a implementação de um algorítmico deve independer de uma determinada linguagem.

Citação:
De fato, o paradigma “orientação a objeto”, tem bases conceituais e origem no campo de estudo da cognição, que influenciou a área de inteligência artificial e da linguística, no campo da abstração de conceitos do mundo real.
Fonte: https://pt.wikipedia.org/wiki/Orientação_a_objetos

Por fim, os pacotes estarão organizados de acordo com a abstração a ser realizada, na representação do mini mundo/universo a ser implementado.

Posso até estar errado em tudo, mas não o fiz com a intenção de errar, mas sim com a avaliação de que faz sentido e a chance de estar correto é maior do que estar errado.

Té+

1 curtida
#3

Acho que não existe uma receita de bolo pra isso! Eu, particularmente, gosto de organizar minhas classes em pacotes do mesmo nível funcional, ou seja, por responsabilidades específicas. Algo mais ou menos assim:

|projeto
-|models
-|services
-|client
-|util
-|repository
-|config
-|security
#4

Como estudante JAVA, recebi a orientação de buscar utilizar sempre o conceito MVC em minhas aplicações. E conforme o colega @addller mencionou, o ideal é dividir as classes em hierarquia, sem perder o foco do modelo MVC. Por exemplo:

“Funcionário” pode estar dentro da seguinte cadeia hierárquica:

Model (Package) -> 
          Funcionário (Package) -> 
               FuncionarioMain.Class 
               FuncionarioOperacional.Class
               FuncionarioAdministrativo.Class 
               FuncionarioGerencia.Class
               Resource(package) 
                    Atributos-do-funcionarioOperacional.class 
                    Atributos-do-funcionarioAdministrativo.class
                    Atributos-do-funcionarioGerencia.class

Desta forma, você pode trabalhar cada tipo de funcionário como uma interface, implementando-as em cada classe de atributos que será usada para tratar cada um.

#5

Sim, mas a questão é,
O que vai dentro do:
Model
Controller
View

Em um projeto desktop java

View eu sei que são os jFrames

mas vi conceitos e formas de utilizar diferentes para o modelo e controller
em alguns casos continha classes POJO em outros a estrutura de components da VIEW

e o controller em teoria contém os controles de tela, mas como isso seria implementado em desktop eu não encontrei um projeto exemplo

#6

Você está se preocupando tanto com arquitetura e vai criar um projeto novo no morto Swing?

Se não for, seja mais específico nas suas buscas pra poder encontrar mais fácil o que deseja aplicar prática.

#7

O fato de ser swing ou javaFX não muda a questão do MVC para Desktop,
o projeto que “vou criar” é meu TCC ai gostaria de organizar melhor, citei o swing porque li em minhas pesquisas que ele usava MVC internamente, que creio que o FX também faça isso seguindo o mesmo conceito.
Em meu serviço existe um sistema que dou manutenção criado em swing antes de eu entrar, ai também surgiu a dúvida quanto a forma que ele foi criado estar correta.

Na questão de especificar a questão é essa :
Como organizar os pacotes?
Modelo MVC funciona para Desktop ? Se sim como (exemplos de projetos)?

A impressão que tenho é que ele é mais voltado para sistemas WEB (sua implantação manual)
Compreende minha dúvida e curiosidade?

#8

Dentre os participantes, me vejo como o de menor conhecimento pois iniciei os estudos este ano, contudo, creio que questionamento não possui consenso, pois:

" Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano".

Pelo manifesto ágil, uma equipe, pode entender que a distribuição dos pacotes deve ser semântica.
Outros que a distribuição dos pacotes deve ser hierarquizada.
Outros que deve ser categorizada.
Etc.

No nível exposto, eu posso dizer que todos os projetos que você viu estão com a arquitetura correta, pois foram organizados de forma compreensível e aceitável.

Considerando responsabilidade limitada das classes eu discordo.
Eu posso separar a interface dos demais componentes com o intuito de prover uma separação em camadas de abstração distintas (pele, coração, sangue e ossos, cada quem com seu cada qual).

Sim, pois javaFX é basicamente MVC e ao meu ver a forma de construção da interface é muito superior no quesito flexibilidade, não tem nem comparação sustentável com o swing.
Do pouco que mexi com ele, só achei que o css está bem limitado, comparado com o que pode ser feito, com html5, claro, um no ambiente desktop e o outro na web, sem misturar as finalidades, apenas a construção gráfica.

https://github.com/search?utf8=✓&q=javafx&type= tem bastante coisa, mas em particular, não vi nenhum.

Isso é difícil, pois demanda análise e tecnicamente a participação de uma pessoa envolvida no projeto, pra dizer, olha, participei, aprovo e justifico.

Bom TCC, pois o meu tá longe, parece quase um Double.POSITIVE_INFINITY.
Té+

#9

galera tem um post com que levantou a mesma questão aqui no GUJ MVC em aplicativo Desktop

Vou me basear em algumas respostas encontradas lá, obrigado pelos comentários

#10

Dei uma olhada no link que você postou, é interessante, pois tem uma recomendação da Oracle e profissionais trocando experiência.
No fim, o que consegui compreender é que os fins justifica os meios. :joy:
A Maquiavel.

Fui.

1 curtida
#11

MVC e Desktop é uma discussão longa

#12

Tem este site também que propõe uma forma de utilizar http://www.gqferreira.com.br/artigos/ver/mvc-com-java-desktop-parte1

#13

Se ficar só na abstração não vai sair do lugar. O que você precisa atender afinal? Na prática tem diferença e você pode remar contra a maré se complicando pra empurrar uma arquitetura independente das necessidades reais.

#14

Segue minha contribuição ao assunto:

MVC não tem nada haver com organização de pacotes! Swing já faz MVC internamente.

A organização de pacotes de um projeto deve refletir as opções de organização arquitetural idealizada pelo responsável do projeto.

Não existe regra, tem arquiteto q faz por conta, tem arquiteto que usa modelos conhecidos como LARMAN, DDD, e et c tem outros q podem misturar varias vertentes juntas.

Para quem tiver interesse eu ensino o básico disso nesse curso - https://for-j.myedools.com/aqt-m1-introducao-a-arquitetura-de-software-com-java

#15

Isso é bem subjetivo e realmente não tem certo ou errado, já trabalhei em diversos projetos com organizações de pacotes diferentes. O mais comum que vejo por aí é o pacote por funções/camadas. (controller, model, service, dao, utils e etc…). Já peguei também alguns por recurso/contexto e também o hexagonal, fora alguns algumas organizações exóticas que não faziam o menor sentido. Huahahahahaha

Particularmente, quando eu tenho a liberdade de escolher a organização, utilizo o pacote por recurso. Quebro a aplicação em contextos, exemplo: administrativo, financeiro, atendimento, regiões, segurança, chamados e etc e agrupo as classes dentro deles. Normalmente com encapsulamento default e utilizando services apenas para a comunicação entre contextos/recursos. Algo próximo da convenção que vemos no Angular por exemplo.

Mas pra projetos de pequeno e médio porte isso não faz muita diferença. Enfim, espero ter ajudado e acrescentado algo ao debate.

#16

Exatamente.
Também tenho visto muitos professores de universidade ensinando que MVC é o ato de criar 3 pacotes model, view e controller e fazer as classes trocarem mensagens entre si e isso é um equívoco.

MVC representa a responsabilidade das classes e interfaces e não o pacote onde elas se encontram.

Se quer ter uma noção melhor de como organizar seus pacotes, sugiro dar uma olhada neste material do Robert C. Martin e leia sobre os seguintes princípios:

REP - The Release Reuse Equivalency Principle:
The granule of reuse is the granule of release.

CCP - The Common Closure Principle:
Classes that change together are packaged together.

CRP - The Common Reuse Principle:
Classes that are used together are packaged together.

1 curtida