> se eu declarasse como private eu nao poderia usar o override quando
> fizesse uma heranca dessa classe, é isso ?
É isso! E por que isto é bom? Porque o "private" ajuda a ocultar a
implementação (information hiding) o que é muito bom em termos de
programação, pois ajuda a diminuir a complexidade. Quando você torna
algo "private" você está ocultando a implementação até mesmo das
classes que herdam da sua. Já o "protected" você oculta a informação
apenas das instâncias, mas não das classes filhas. É por isto que
muitos estudiosos de Orientação a Objetos dizem que a herança viola o
encapsulamento: as classes descendentes sabem muito sobre a
implementação das classes ancestrais o que quer dizer que sempre que
você modifica uma classe ancestral você acaba tento de modificar as
classes descendentes.
O SDK do Flex, por exemplo, é muito ruim sobre este aspecto uma vez
que para desenvolver seus próprios componentes você usa a herança e
precisa saber como o framework de componentes funciona internamente
(os invalidates, updates e flags de controle).
Enfim, quanto mais informação você puder ocultar melhor será o seu
encapsulamento. E os namespaces podem lhe ajudar nisto.
[]'s
Beck Novaes
P.S.: Quando eu comecei a estudar Orientação a Objetos eu pensava que
o "protected" tinha alguma coisa a ver com a seguraça :-D
On 19 jun, 06:28, rramires <[EMAIL PROTECTED]> wrote:
> Outra coisa bacana que eu vi na documentacao () é que se vc tiver duas
> classes com o mesmo nome em pacotes diferentes e precisar utilizar
> instancias delas no mesmo local da pra criar apelidos:
>
> package acme.core
> {
> public class Widget { }
>
> }
>
> package mx.core
> {
> public class Widget { }
>
> }
>
> import AcmeWidget = acme.core.Widget
> import MxWidget = mx.core.Widget
>
> http://livedocs.adobe.com/specs/actionscript/3/wwhelp/wwhimpl/common/...
> new AcmeWidget
> new MxWidget
>
> Beck, valeu... finalmente acho que entendi o protected, hehehehe, ve
> se é isso:
>
> se eu declarasse como private eu nao poderia usar o override quando
> fizesse uma heranca dessa classe, é isso ?
>
> Ricardo
>
> On 19 jun, 08:24, Beck Novaes <[EMAIL PROTECTED]> wrote:
>
> > Uma boa maneira de compreender os namespaces é através dos
> > modificadores de acesso. Estes elementos controlam a visibilidade das
> > propriedades e métodos de uma classe. Muitas linguagens possuem três
> > modificadores de acesso: private, protected e public. Os modificadores
> > de acesso permitem ao programador limitar o acesso a determinados
> > elementos e assim garantir um bom encapsulamento. Quando você diz que
> > alguma coisa é "public", por exemplo, você está dizendo: "pessoas,
> > usem isto aqui a vontade porque isto não irá mudar". Por outro lado,
> > quando você torna algo "private" ninguém poderá usar e você é livre
> > para alterar como quiser. O "protected" está no meio do caminho ao
> > permitir que os elementos sejam alterados dentro de um escopo
> > (herança) mais limitado que o "public", porém menos rígido que o
> > "private". Por fim, cabe dizer que os modificadores de acesso ajudam a
> > fazer o que é mais importante em programação: lidar com a
> > complexidade. Quando todo mundo pode mexer em tudo, tais como
> > variáveis Globais, tica difícil para o programador ter que lembrar
> > quais os locais que determinado elemento foi utilizado. Mas quando
> > você limita o escopo/acesso dos elementos fica mais fácil de gerenciar
> > este tipo de coisa.
>
> > Agora o que os namespaces têm a ver com tudo isto? Bem, você pode
> > pensar nos modificadores de acesso padrão do ActionScript (internal,
> > private, protected e public) como namespaces pré-definidos. Isto
> > significa que você pode implementar seu próprio modificador de acesso
> > e assim estabelecer um nível de controle a mais, que lhe ajudará a
> > lidar melhor com a complexidade. Imagine que você possui um conjunto
> > de classes que fazem parte de um framework que você está
> > desenvolvendo. De repente você percebe que a classe "A" precisa chamar
> > o método "test" num objeto da classe "B" que está num pacote
> > diferente. Mas você não quer tornar o método "test" public porque ele
> > é de uso interno do seu framework. O que você faz? Bem, você pode
> > criar um namespace chamado "framework" e defini-lo como o modificador
> > de acesso do método "test". Na realidade é isto que a Adobe fez com
> > muitos elementos do SDK do Flex. Se você abrir a classe UIComponent
> > verá que existe um modificador de acesso "mx_internal". Isto permite
> > que os componentes do SDK tenham acesso a estes elementos mesmo
> > estando em pacotes diferentes ao mesmo tempo em que estes elementos
> > não são públicos "naturalmente". Eu digo "naturalmente" porque sei que
> > existe uma maneira de usar estes elementos mesmo eles não sendo
> > públicos. Porém não devemos usá-los, pois se não são explicitamente
> > públicos a Adobe poderá modificá-los amanha e o nosso programa que fez
> > o uso indiscriminado destes elementos "mx_internal" irá parar de
> > funcionar.
>
> > Existem outros cenários onde o uso de namespaces pode ser conveniente,
> > mas acho que já escrevi demais. :-D
>
> > On 18 jun, 17:49, Emanuel Mandelli <[EMAIL PROTECTED]> wrote:
>
> > > Olá pessoal, tudo bem?
>
> > > Alguém poderia me explicar namespaces? Estou lendo um livro em inglês
> > > mas não estou entendendo.
>
> > > --
> > > Abraços,
> > > Emanuel
> > > [EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
Você recebeu esta mensagem porque está inscrito na lista "flexdev"
Para enviar uma mensagem, envie um e-mail para [email protected]
Para sair da lista, envie um email em branco para [EMAIL PROTECTED]
Mais opções estão disponíveis em http://groups.google.com/group/flexdev
-~----------~----~----~----~------~----~------~--~---
