Olá Pessoal,
Estava dando uma olhada em umas documentações para arquiteto java, e me deparei com esse exercício, como não tenho mta experiência em patterns, gostaria da ajuda de vocês para essa pergunta abaixo:
Você está encarregado de coordenar o desenvolvimento de um sistema complexo, em um tempo curto. Para isso, você planeja dividir o desenvolvimento entre equipes e permitir o andamento de atividades em paralelo. Cite e justifique que padrão de desenho seria mais o importante a ser empregado na fase inicial do projeto
O exercício não dá nenhuma dica sobre qual seria o problema? O design pattern á uma solução recorrente, ou seja, alguém já teve um problema parecido e resolveu de tal forma, o design pattern nada mais é do que uma formalização da solução
Por exemplo, eu quero que o meu sistema seja independente do banco de dados utilizado, ou então eu quero arrumar uma forma de trafegar objetos pela rede de uma forma mais eficiente, existem design patterns para resolver um problemas específicos
Vlw por responder,
Então cara, o exercício quer saber qual seria o designer patterns mais adequado para esse tipo de problema e não dá nenhuma dica. O que ele frisa é que tem q justificar dando uma idéia o porquê do design patterns escolhido.
Oi, isso para mim lembra o design pattern mais utilizado em computação, chama-se POG… brincadeira… rs
Na minha opinião você planeja dividir o desenvolvimento entre equipes e permitir o andamento de atividades em paralelo pode ser resolvido usado algum controle de versão como o CVS, Subversion, Source Safe…
Como eu falei - eu pelo menos - não consigo ver no enunciado que situação seria interessante para usar um pattern, talvez ele queira dizer quais padrões seriam recomendados em um desenvolvimento inicial de um sistema…
Alguns acho que são sempre bem-vindos e você normalmente acaba usando como o DAO que deixa a sua aplicação independente do Banco de Dados, outro é o Service Locator que te proporciona uma interface única para buscar serviços vindos de EJB, JMS, etc. Outro bastante usado é o Session Facade que esconde de você lógica de negócio e te proporciona uma lógica mais simples…
Na minha opinião esta parte “padrao de desenho” não está nada relacionado com o contexto exposto no exercício, ou seja, necessita de esclarecimento por parte de quem teve a coragem de perguntar uma coisa dessa, quem sabe desta resposta (certa é claro) com certeza tá com bastante dinheiro no bolso.
Isto pra mim tem à ver com estratégia, e a resposta não é pra duas linhas. Como (na minha opinião) isto está relacionado com estratégia vou dizendo logo que isso nos leva a crer que é uma coisa do tipo DEPENDE, para cada projeto, problema etc… requer uma, várias ou até combinação de estratégias diferentes a serem abordadas.
Vai ver o cara que escreveu isso está pensando que Design Pattern é pra isso ou escreveu “padrao de desenho” querendo dizer outra coisa rsrsrsrsr, ainda bem que é um exercício :? .
Concordo com todo mundo aí em cima que falou que o exercício parece mal formulado. Se isso fosse uma entrevista de emprego, eu não daria uma resposta direta, mas ao invés disso, eu responderia com mais perguntas.
Mas vamos tentar entender o pensamento do cara que escreveu isso aí. Ele provavelmente quer dividir sua equipe em subsistemas. Neste caso, provavelmente a resposta é o Session Façade, para diminuir o acoplamento dos subsistemas e permitir que cada equipe trabalhe em um deles de maneira isolada.
Bem, como “prova” é “prova” então não significa que a questão SEMPRE terá alguma relevância no mundo real. Mas voltando a vaca fria da questão, você deve notar que tem uma mistura de “bumba-meu-boi” --> projeto complexo com pouco tempo, arquitetura --> design patter, e ainda processo de desenvolvimento.
Uma resposta possível para este problema seria uma arquitetura inicial dividida em camadas ( layers ), com interfaces bem definidas entre elas ( aí podem entrar façades, remote façades, service layer, etc.), e com esse design inicial vc poderia dividir o seu time por área funcional (GUI, Database Access, Server Side, etc) e realizar a implementação das user stories/use case.
Como tb foi citado “equipes”, cada uma poderia ficar com uma story/use case diferente e as implementações ocorrerem em paralelo, e akilo que fosse comum a dois ou mais times você poderia fazer um intercâmbio de membros de cada time para realizar a integração/alinhamento do desenvolvimento de ambas as funcionalidades.
Como eu disse anteriormente, isto é uma idéia de uma possível resposta para este exercício esquisito. Eu lembro q quando eu fiz a prova de vez em quando eu achava umas questões bem bizarras, do tipo “oque você faria para zuar a máquina de seu amigo e deixá-la lenta gradativamente ?”
[quote=domingos.neto] Mas vamos tentar entender o pensamento do cara que escreveu isso aí. Ele provavelmente quer dividir sua equipe em subsistemas. Neste caso, provavelmente a resposta é o Session Façade, para diminuir o acoplamento dos subsistemas e permitir que cada equipe trabalhe em um deles de maneira isolada.
[/quote]
Vc falou “Session Façade” e me lembrei de uma coisa que estou tentando deixar um pouco de lado (é possivel que apareçam muitos trabalhos de manutenção bem remunerados rsrsrs), os padrões J2EE. Aqueles que uma parte da galera chamam de BOLOVO e coisa e tal rsrsrsr.
Utilizando estes padrões vc consegue dividir a equipe em grupos e até fazer com que os profissionais trabalhem de forma isolada sem até conversar um com o outro.
Mas é ai que vem a pergunta: Isso é bom para o projeto como um todo (incluido a equipe)? Eu acho que não, os maiores problemas que vejo nessa estratégia são: redundancia de código enorme, falta de comunicação, aumento enorme do retrabalho e por ai vai.
As metodologias àgeis tem várias respostas para essas questões.
Vai ver a ideia éra essa mesma que vc disse, que sabe? rsrssrs
Você tocou num ponto interessante. Concordo com o que você falou aí em cima, mas deixa eu me explicar Eu toquei no pattern Session Façade porque o nosso amigo aí em cima falou que estava estudando uma documentação para Arquiteto Java. Eu apenas liguei os pontinhos para tentar entender o que o formulador da pergunta estava pensando
Sobre BOLOVO (haha gostei do termo). Dei uma pesquisadinha para entender do que se tratava. Vade retro cruz credo satanás! Isso aí é pior que mula sem cabeça! Mas não sei se TODO o livro Core J2EE patterns deve ser jogado no lixo! Talvez seja um pouco extremo, não acha? Tem coisa boa lá, se soubermos quando usar.
É que o Session Façade leva lógica de negócio dentro dele, e o Remote Façade é apenas uma casca fina para prover uma camada de remote, que neste caso rola um Session Bean mesmo.
Domain Logic tem que ficar no DOMAIN MODEL, e não existe outro lugar melhor pra colocar, quebrar a lógica de negócio entre várias classes periféricas só vai criar um design bizarro. Um último ponto neste assunto são os DTO’s, que no caso de se trabalhar com um Remote Façade servem para transportar os dados do servidor para o cliente em uma forma “light”, sem termos q mandar aquela teia enorde de objetos do domain model. Outro ponto de utilização do DTO no estilo não remote, é para desacoplar a camada de apresentação do domain model, onde é uma maneira de isolar o domain model da camada de apresentação, então nesse sentido podemos mudar o domain model sem ter ter que mexer na GUI, ou ainda mudar a apresentação sem ter q “martelar” o domain model para refletir essas alterações.
O Martin Fowler levanta essa discussão no capítulo 15 do PEAA, na seção de Data Transfer Object.
Eu sei que eu saí do assunto inicial que era a questão da prova, mas achei válido levantar essa bola.
Vc tem a certeza que é “padrão de desenho” ? O que está lendo é em português ? ou está traduzindo ?
É que Design Patterns, embora a tradução verdadeira é Padrões de Desenho é normalmente traduzido para Padrões de Projeto.
Por outro lado qual é o escopo desses padrões ?
A resposta que faz mais sentido é o Principio de Separação de responsabilidade, em particular o Encapculamento e o “Programa para interfaces”. Mas nenhum destes são padrões de projeto.
Nenhum padrão de projeto pode ser aplicado numa fase incial do projeto porque eles se aplicam na fase de desenvolvimento/modelagem que não é uma das iniciais.
[quote] The Pragmatic Programmer, From Journeyman To Master - Andrew Hunt, David Thomas - Addison Wesley - 1999
Have you noticed how some project teams are efficient, with everyone knowing what to do
and contributing fully, while the members of other teams are constantly bickering and don’t
seem able to get out of each other’s way?
Often this is an orthogonality issue. When teams are organized with lots of overlap,
members are confused about responsibilities. Every change needs a meeting of the entire
team, because any one of them might be affected.
[/quote]
Essa parte explica muito também:
Eu estava lendo o livro e lembrei desse tópico, um degin pattern que aumenta a ortogonalidade de um sistema é o MVC. Pelo que entendi auxiliaria na modularização do sistema auxiliando na divisão de tarefas da equipe e tornado a trabalho pouco dependente a mudanças de implementação que podem surgir.
