Quebra do conceito de OOP

Por que é que quebraria o conceito?

De qualquer maneira, a API da Sun não é exatamente o melhor exemplo de uso dos conceitos de OO.

Não fique “pegando no pé” com essas coisas; preocupe-se com seu código.

Enio Carvalho:

Bom dia!
Analisando a classe java.awt.Color, vemos que a mesma possui vários métodos estáticos que retonam um objeto color. Ex: black,cyan,red, etc.
Isto quebra o conceito de OOP?

Na verdade não são métodos estáticos; são campos estáticos utilitários que visam facilitar o uso de cores mais comuns. Color.red por exemplo é uma constante que faz referência
a um objeto construído assim: new Color (255,0,0). Certamente ao construir essa classe os conceitos OO foram considerados menos importantes do que a facilidade que campos assim proporcionam.

imagina toda vez que eu quiser uma cor tipo amarelo, vermelho, verde ? vou ter que abrir meu photoshop pra descobrir o R G B ?
embora tem que não goste (eu sou um deles), use o import static se for o caso.

se você ta reclamando da classe Color, veja depois senão me engano a classe Date do java.util.Date, ja vi N pessoas chingando até a mãe do cara pelos metodos não funcionarem como deveriam. :lol:

[]'s

Não estou pegando nos pés dos caras. Até gostei da solução, visto que facilita bastante a nossa vida. Gostei tanto que queria utilizar este padrão para uma solução que estou desenvolvendo. Ex:

Tenho uma classe abstrata de Fábrica de conexões:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public abstract class ConnectionFactory {

	public abstract String getDriver();
	public abstract String getUrl();
	public void setUser(String user) {
		this.user = user;
	}
	public Connection getConnection() {
		try {
			Class.forName(getDriver());
			return DriverManager.getConnection(getUrl(), getUser(), getPwd());

		} catch (SQLException e) {
			e.printStackTrace();
		} catch (ClassNotFoundException e) {
			e.printStackTrace();
		}
		return null;
	}
	public abstract String getSgdbName();
	
	public String getUser() {
		return user;
	}

	public void setPwd(String pwd) {
		this.pwd = pwd;
	}

	public String getPwd() {
		return pwd;
	}

	private String user;
	private String pwd;

}

Tenho classes filhas que extendem a classe mãe. Ex.:

import java.util.*;

public class TeradataConnectionFactory extends ConnectionFactory {
	List<String> nodes = new ArrayList<String>();

	public void addNode(String ipAddress) {
		nodes.add(ipAddress);
	}

	@Override
	public String getDriver() {
		return "com.teradata.jdbc.TeraDriver";
	}

	@Override
	public String getUrl() {
		if (nodes.size() > 0) {
			return "jdbc:teradata://"
					+ nodes.get(new Random().nextInt(nodes.size()))
					+ "/database=" + getDatabase();
		} else {
			return null;
		}
	}

	public void setDatabase(String database) {
		this.database = database;
	}

	public String getDatabase() {
		if (database != null) {
			return database;
		} else {
			return getUser();
		}

	}
	private String database;

	@Override
	public String getSgdbName() {
		return "Teradata";
	}

}

Acho que seria de grande ganho ter como no caso da classe color, métodos estáticos que devolvessem tipos de conexões diferentes, ex.:

ConnectionFactorys.getTeradataConnectionFactory
ConnectionFactorys.getOracleConnectionFactory
ConnectionFactorys.getMySqlConnectionFactory
ConnectionFactorys.getSqlServerConnectionFactory

Entenderam?

Peço suas sugestões!

Não compreendo como a classe Color representa um exemplo de Abstract Factory. Poderia justificar?

EDIT - agora entendi que você estava se referindo à fábrica de conexões do Enio Carvalho.

Vejo que você reconheceu o padrão que utilizei, realmente é o Abstract Factory. Conheço o artigo, mas a questão colocada aqui está um passo adiante: É sobre campos/métodos estáticos que devolvam as diferentes implementações de uma classe.

Ninguém mais?

Bom chegando atrasado…
Eu concordo com o que o WRYEL disse, acho que nestes casos uma quebra de conceito de OOP não justifica o trabalho que vai dar depois, é uma solução simples, que eu acho util. Se vai ser um problema, isto depende do desenvolvedor que deseja adotar isto.
Mas não entedi o que vc quis dizer com isto:

[]'s

Alan Delgado:

Bom chegando atrasado…
Eu concordo com o que o WRYEL disse, acho que nestes casos uma quebra de conceito de OOP não justifica o trabalho que vai dar depois, é uma solução simples, que eu acho util. Se vai ser um problema, isto depende do desenvolvedor que deseja adotar isto.
Mas não entedi o que vc quis dizer com isto:

[]'s

É como eu havia citado acima:

Me fiz entender?

não acredito que quebrem o conceito de OO porque são campos constantes “final”, você só pode lê-los, não modificá-los.