Marcos Douglas wrote:
> João,
>
> Mas vcs chegaram a discutir a complexidade de ter muitas interfaces ou cada
> um foi pra um lado mesmo? Tavez pudesse ter uma versão mais simples e outra
> mais completa e, portanto, mais complexa, por exemplo.
Na época troquei dúzias de emails com o Marcos. Ele
Juliano Carvalho - Folhamatic wrote:
> Se a questão for somente propriedades fica mais fácil (ou menos dificil)
> resolver com interface. Ou estas propriedades são altamente complexas?
Neste caso elas sequer possuem implementação, nem precisam de getter ou
setter. São propriedades publicadas. I
Juliano Carvalho - Folhamatic wrote:
> Não sei exatamente do que vc ta falando mas parece que os aspectos são o
> approach mais indicado pra resolver esta questão.
Já que tocasse no assunto...
Preciso unir as propriedades de duas hierarquias de classes. Aspecto,
até aonde eu conheço, não vai a
Marcos Douglas wrote:
>> Concordo que interface, apesar de não ter nascido pra isso, resolve o
>> problema. Discordo que isto seja motivo para remover o recurso. É um
>> pouco mais complicado implementar herança múltipla com interface do que
>> implementar diretamente através das classes. Mas como
Marcos Douglas wrote:
> Deixar os forms sem implentação para deixar o código em outro lugar
> não acaba com o problema; pode até ficar mais complexo.
> Temos que pensar no _objetivo_ final, não na _forma_ como é feito.
Depende do seu conceito de complexo. MVP não "deixa o código em outro
lugar",
anderson wrote:
> Entendi, mas vamos supor entaum, eu posso suar ECO como OPF e usar uma
> camada MVP para desacoplar ao maximo possível DB / MODELO / APRESENTAÇÃO
> certo ?
Desacoplar do banco você pode fazer com ClientDataSet ou DBExpress.
Com OPF (ECO, por exemplo) além de desacoplar você tem
6 matches
Mail list logo
