Uso de Interface nos componentes do ACBr

[bnobre]

Olá a todos,

Aqui nos meus estudos sobre POO reparei que nos componentes do ACBr não se faz o uso das Interfaces do Delphi e muitos programadores sugerem que é mais interessante programar orientado a interfaces do que a objetos.

Tem algum motivo em especial para não se fazer o uso de Interfaces nos componentes?

Desde já agradeço a atenção

[Daniel Simoes]

Acho que é uma questão de preferência...

Eu particularmente, prefiro ter rotinas que criam e destroem seus objetos... 
E para evitar Memoryleaks, não uso métodos que retornam Objetos criados internamente, mas espera recebe-los como parâmetros, para deixar claro que a responsabilidade de quem deve criar/destruir o objeto, é da rotina chamadora do método

Mas há alguns componentes que usam Interfaces, observe a implementação do novo componente, SmartTEF...

E nesse caso, podemos ter métodos que retorno Objetos, e deixar que o contador de referência, elimine-os automaticamente

[bnobre]

37 minutos atrás, Daniel Simoes disse:

Acho que é uma questão de preferência...

Eu particularmente, prefiro ter rotinas que criam e destroem seus objetos... 
E para evitar Memoryleaks, não uso métodos que retornam Objetos criados internamente, mas espera recebe-los como parâmetros, para deixar claro que a responsabilidade de quem deve criar/destruir o objeto, é da rotina chamadora do método

Mas há alguns componentes que usam Interfaces, observe a implementação do novo componente, SmartTEF...

E nesse caso, podemos ter métodos que retorno Objetos, e deixar que o contador de referência, elimine-os automaticamente

Oi @Daniel Simoes,

Vou ver sim, mas a grande maioria pelo que reparei não usa.

Legal essa sua técnica de receber eles como parâmetros.

[Juliomar Marchetti]

10 horas atrás, bnobre disse:

Oi @Daniel Simoes,

Vou ver sim, mas a grande maioria pelo que reparei não usa.

Legal essa sua técnica de receber eles como parâmetros.

se olhar o ACBrNFSeX o mesmo faz uso, bem como os novos que foram criados de DFe.

eles fazem uso.

 

[bnobre]

1 minuto atrás, Juliomar Marchetti disse:

se olhar o ACBrNFSeX o mesmo faz uso, bem como os novos que foram criados de DFe.

eles fazem uso.

 

Oi... Legal

O que eu não gosto nos interfaces é a necessidade de criar métodos Get e Set para as propriedades.

Com o uso de classes tradicional dá pra fazer isso de forma mais pratica acessando direto os campos, por exemplo:

property GroupId: String read FGroupId write FGroupId;

Quando se tem muitas propriedades isso é muito prático;

[Juliomar Marchetti]

sim tem que ser feito isso.

mas se tu vai usar só pra tratar uma classe que irá usar de model por exemplo

não vejo o motivo de programar os fields 

dai no caso tu poderia só ter para os objetivos comuns e usar a tipagem para interface 

type
	IFace = interface
		function xpto:boolean;
	end;

	Tface = class(Tinterfacedobject, IFace)
	private	
		fnome :string;
		function xpto:boolean;
	public
		property nome :string read fnome write fnome;
	end;

.....


var
	LFace : IFace;
begin
	LFace := Tface.Create;

	Tface(LFace).nome := 'xxx';

e mesmo assim ainda se for só mesmo para isso não usaria dai interface

[bnobre]

3 minutos atrás, Juliomar Marchetti disse:

sim tem que ser feito isso.

mas se tu vai usar só pra tratar uma classe que irá usar de model por exemplo

não vejo o motivo de programar os fields 

dai no caso tu poderia só ter para os objetivos comuns e usar a tipagem para interface 

type
	IFace = interface
		function xpto:boolean;
	end;

	Tface = class(Tinterfacedobject, IFace)
	private	
		fnome :string;
		function xpto:boolean;
	public
		property nome :string read fnome write fnome;
	end;

.....


var
	LFace : IFace;
begin
	LFace := Tface.Create;

	Tface(LFace).nome := 'xxx';

e mesmo assim ainda se for só mesmo para isso não usaria dai interface

Se entendi bem o que você sugeriu é usar a interface só para declarar os métodos, dos quais deverão ser implementados nas classes derivadas... E as propriedades declaro apenas nas classes derivadas... Seria isso?

5 minutos atrás, Juliomar Marchetti disse:

dai no caso tu poderia só ter para os objetivos comuns e usar a tipagem para interface 

Não entendi o final quando disse "usar a tipagem para interface". O que quis dizer?

[Juliomar Marchetti]

47 minutos atrás, Juliomar Marchetti disse:

Tface(LFace).nome := 'xxx';

isso. 

43 minutos atrás, bnobre disse:

Não entendi o final quando disse "usar a tipagem para interface". O que quis dizer?

 

[Daniel Simoes]

por essas e outras, que não vejo muita vantagens em usar Interfaces...

Na minha opinião, as Interfaces são úteis apenas quando:
- o Método precisa retornar um Objeto
- deseja-se utilizar o estilo de codificação "Fluent Interface"

[bnobre]

Pra ser sincero eu não entendi bem essa frase ainda:

Citar

"dai no caso tu poderia só ter para os objetivos comuns e usar a tipagem para interface, e mesmo assim ainda se for só mesmo para isso não usaria dai interface"

Você não quis dizer "não usaria interface"????????

Porém a primeira parte entendi... Usar a "tipagem para interface" seria fazer o cast para acessar a propriedade... Putz, que volta isso!!!

Aí seria melhor usar o Fluent Interface sugerido pelo @Daniel Simoes. Acho que seria essa forma de programar presente no vídeo abaixo, onde o autor nomeia como Programação Funcional, estou correto?

 

[Juliomar Marchetti]

Sim tu pode usar para fluent interface.

mas não , a interface não é somente para essa finalidade. segue um trecho abaixo para lhe dar um norte @bnobre

Citar

Usar interfaces em Delphi é uma prática recomendada para criar código mais flexível, manutenível e escalável, pois definem um "contrato" de funcionalidades que diferentes classes podem implementar. Isso é especialmente útil para desacoplar a implementação da lógica, permitindo que você substitua partes do sistema sem alterar outras. Outras vantagens incluem a possibilidade de implementar herança múltipla e criar classes abstratas sem a complexidade de classes abstratas tradicionais. 

vai parecer falar de orientação a objetos mas auxilia

Citar

Principais benefícios

• Desacoplamento e flexibilidade: Interfaces permitem que uma classe use outras que implementam um contrato específico, sem precisar conhecer os detalhes internos da classe. Isso facilita a substituição de uma implementação por outra.
• Manutenibilidade e escalabilidade: Ao desacoplar as responsabilidades, torna-se mais fácil fazer alterações no futuro. É possível adicionar novas funcionalidades implementando novas interfaces, sem interferir no código existente.
• Herança múltipla: Embora o Delphi não suporte herança múltipla de classes, a implementação de interfaces permite que uma classe adote múltiplos "contratos" de funcionalidades, o que é uma forma de simular a herança múltipla.
• Abstração: O conceito de interface permite criar uma camada de abstração, onde o que importa é o que a classe pode fazer (o contrato), e não como ela faz (a implementação).
• Organização do código: Interfaces ajudam a estruturar o código de forma mais organizada, especialmente em projetos grandes e de longo prazo. Por exemplo, você pode definir um contrato de "salvamento de dados" e implementar essa interface em diferentes classes (banco de dados, arquivo, etc.).
• Simplicidade da implementação: Em comparação com classes abstratas, uma interface em Delphi é conceitualmente mais simples, pois não possui implementação. Ela apenas declara os métodos que uma classe deve implementar. 

 

[Daniel Simoes]

Esses benefícios (excluindo Herança múltipla) parecem estar presentes em uma estrutura de classes padrão de O.O... ou seja, não parecem ser tão exclusivos da técnica de uso de Interfaces...