Mostrando postagens com marcador Design Patterns. Mostrar todas as postagens
Mostrando postagens com marcador Design Patterns. Mostrar todas as postagens

27 de janeiro de 2012

Lançamento do livro Introdução à Arquitetura e Design de Software - Caelum

Hoje foi o Lançamento Oficial do Livro de Introdução à arquitetura e Design de Software feito pelo pessoal da Caelum, uma ótima escolha de leitura.
O Lançamento foi feito no Shopping Pátio Paulista, dentro da Livraria Saraiva, foi muito divertido rever os amigos.

 
Foto tirada pela Loiane







Sérgio Lopes um dos autores com Sr. Carlos.

Grande Família Silveira: Guilherme Silveira, Maria Lúcia Silveira, Carlos Silveira, Paulo Silveira.

Grande amigo Luiz Bassi.

Wryel Covo e Roberto Enomoto.


A dedicatória no meu livro feita pelos amigos e autores Guilherme Silveira, Sérgio Lopes e Paulo Silveira.

Não posso esquecer outros amigos que também escreveram o livro, mas por motivos de não estarem em SP não puderam comparecer: Guilherme Moreira, Nico Steppat e Fábio Kung.
Também o grande Jim Webber.

Foi muito divertido ir no lançamento, parabéns pessoal da Caelum.

11 de agosto de 2008

Red Code

Red Code

From: juliano.claiton, 1 minute ago




Palestra ministrada no último evento IMES(USCS).java
Códigos mal escritos e anti-patterns. O caminho do sucesso para o Blue Code.


SlideShare Link


13 de agosto de 2007

The best of the best practices - Java EE aplications.

A Big Blue divulgou em Janeiro passado um documento falando sobre as melhores práticas de mercado para aplicações Java EE.

Segue abaixo a lista com as 19 top best practices elencadas por eles

A materia completa está disponível em

http://www.ibm.com/developerworks/websphere/techjournal/0701_botzum/0701_botzum.html


The best of the best practices
1. Always use MVC.
2. Don't reinvent the wheel.
3. Apply automated unit tests and test harnesses at every layer.
4. Develop to the specifications, not the application server.
5. Plan for using Java EE security from Day One.
6. Build what you know.
7. Always use session facades whenever you use EJB components.
8. Use stateless session beans instead of stateful session beans.
9. Use container-managed transactions.
10. Prefer JSPs as your first choice of presentation technology.
11. When using HttpSessions, store only as much state as you need for
the current business transaction and no more.
12. Take advantage of application server features that do not require
your code to be modified.
13. Play nice within existing environments.
14. Embrace the qualities of service provided by the application server
environment.
15. Embrace Java EE, don't fake it.
16. Plan for version updates.
17. At all points of interest in your code, log your program state using a
standard logging framework.
18. Always clean up after yourself.
19. Follow rigorous procedures for development and testing.

Factory Method

Bom dia, hoje postarei algo sobre o padrão Factory Method, vamos lá...

Design Pattern: São uma coleção de padrões de desenho de software, que são soluções de problemas ocorridos no dia a dia de desenvolvimento de um software (são boas idéias).

Factory Method: este padrão é bem recomendado como por exemplo quando você utiliza vários tipos de bancos de dados em seu projeto, ele é uma fábrica que retorna uma das várias fábricas.


Vamos para um exemplo prático: Criarei uma factory para retornar um dos vários objetos DAO's do meu projeto, considere o seguinte diagrama:










Segue a implementação no código deste diagrama:

Esta classe abstrata é a Factory que retorna instancia de outras factories:

public abstract class DAOFactory {

public abstract UserDAO getUserDAO();

public static DAOFactory getInstance(int whichFactory) {
switch (whichFactory) {
case 1:
return new MySqlUserDAOFactory();
case 2:
return new PostgresUserDAOFactory();
default:
return null;
}
}
}

Factory para MySql
public class MySqlUserDAOFactory extends DAOFactory {

@Override
public UserDAO getUserDAO() {
return new MySqlUserDAO();
}
}

Factory para Postgres
public class PostgresUserDAOFactory extends DAOFactory {
@Override
public UserDAO getUserDAO() {
return new PostgresUserDAO();
}
}

Interface UserDAO, contém os métodos que os DAO's devem implementar.
public interface UserDAO {
public void save(Object o);
}

DAO para MySQL
public class MySqlUserDAO implements UserDAO {
public void save(Object o) {
// TODO Auto-generated method stub
}
}

DAO para Postgres
public class PostgresUserDAO implements UserDAO {
public void save(Object o) {
// TODO Auto-generated method stub
}
}

Vamos ver como chamariamos as nossas classes:

public static void main(String[] args) {
DAOFactory daoFactory = DAOFactory.getInstance(1);
// retorna a factory para MySql
UserDAO userDAO = daoFactory.getUserDAO();
userDAO.save(new Object());

DAOFactory daoFactory2 = DAOFactory.getInstance(2);
// retorna a factory para Postgres
UserDAO userDAO2 = daoFactory2.getUserDAO();
userDAO2.save(new Object());
}

Com isso a nossa implementação termina, um detalhe importante que deve-se notar é que se por um acaso um dia sua empresa decicidir incluir o oracle basta apenas criar uma nova factory OracleUserDAOFactory e estender a classe DAOFactory e pronto, com esse padrão fica muito flexível incluir e excluir qualquer nova implementação.


É isso ae...

[]'s