Respeito à Propriedade Privada

6 Responses to “Respeito à Propriedade Privada”

1. Sebastian on March 17th, 2008 10:38 pm
   

   Ola Daniel.
   Acho interessante as postagens do seu blog.
   Gostaria, se possivel, que vc comentasse um pouco mais sobre as formas de desenvolvimento e ferramentas que utiliza…abraco! up the irons!

2. Malta on March 17th, 2008 11:26 pm
   

   Obrigado, Sebastian. Vou ouvir sua sugestão e escrever um pouco sobre minhas ferramentas e práticas.

3. Alexandre José on March 24th, 2008 11:01 pm
   

   Muito bom comentar sobre este recurso, repliquei ele no meu blog, muito boa a lembrança. Parabéns! :)

4. Gerson on April 6th, 2008 5:44 am
   

   Cara, Malta, mto engraçado a alusão que vc fez. Ainda mais que o tom irônico ampliou extremamente o sentido didático do ponto que vc pretendeu destacar ( kkkk … no bom sentido é claro .. hehehe).
   Ok, ok, ok …
   Cara, segundo fontes … o conceito de classes amigas foi revisto na VCL para compatibilidade com o .Net.
   Não sei até que ponto isso se confirma, mas se não me falha a memória desde o d2005 o “strict private” já estava valendo … a casa … hehheh.
   Sou solidário ao sentimento de indignação, quanto a privacidade devassada … hehhehhee.

   unit Unit2;
    
   interface
    
   uses
     Classes;
    
   type
     TMyAustralianWine = class(TComponent)
     strict private
       FName:    string;
       FRegions: string;
       procedure SetRegions(const Value: string);
       procedure SetName(const Value: string);
    
     strict protected
    
     public
       property Name: string Read FName Write SetName;
       property Regions: string Read FRegions Write SetRegions;
     end;
    
   type
     TMyGlassWine = class(TComponent)
     strict private
       FIsEmpty: boolean;
       procedure SetIsEmpty(const Value: boolean);
     strict protected
     public
       property IsEmpty: boolean Read FIsEmpty Write SetIsEmpty;
     end;
    
   implementation
    
   { TMyAustralianWine }
    
   procedure TMyAustralianWine.SetName(const Value: string);
   begin
     FName := Value;
   end;
    
   procedure TMyAustralianWine.SetRegions(const Value: string);
   begin
     FRegions := Value;
   end;
    
   { TMyGlassWine }
    
   procedure TMyGlassWine.SetIsEmpty(const Value: boolean);
   begin
     FIsEmpty := Value;
   end;
    
   end.

   Veja, não estou tentando afirmar que no copo vazio fica impossível verificar de que região é o vinho, um paladar apurado isso exige, mas com o “strinc private” é isso que acontece de fato … hhehehh
   Vlw Malta, abração!!!

5. Gerson on April 6th, 2008 6:04 am
   

   Ah!!! Outra coisa …
   o class complete do D2006 insiste na “private”, mesmo já existindo a “strict private” … isso é irônico também!!
   No contexo, vale lembrar do “strict protected” … para evitar que alguém desavisadamente deixe outras partes “à mercê da libido alheia” .

6. Malta on April 6th, 2008 1:59 pm
   

   Fala Gerson,

   Por isso que eu faço questão de só alocar vinhos em que a procedência é pública! :-)

   A verdade é que é sempre a necessidade de compatibilidade com novas tecnologias de terceiros que tem dirigido a implementação de novos recursos da linguagem Delphi.

   As “interfaces” surgiram no Delphi para tornar possível a integração com o modelo de objetos COM da Microsoft. Vários recursos foram acrescentados ao compilador para tornar o código portável entre Windows e Linux, na época do Kylix. “Strict private” e “strict protected”, como você mencionou, para compatibilizar com .NET. Assim também “generics” (por enquanto só no Delphi for .NET) e métodos em records.

   Isso mostra que a Borland/CodeGear está sempre correndo atrás do mercado, ao contrário de linguagens como Ruby e Python, que inovam espontaneamente por iniciativa do movimento open-source.

   Valeu pela sua contribuição!

   Abraços,

   Malta.

Deixe uma Resposta