Elemar DEV

Tecnologia e desenvolvimento

Afinal, “sealed” tem algum valor semântico?!

Olá pessoal. Tudo certo!?

Este é outro post provocativo (ainda um formato experimental aqui no blog). Outro dia, durante um almoço no DNAD 12, entrei um uma discussão técnica/conceitual com o @juanplopes. Embora a experiência demonstre que, nesses casos, eu estou errado, ainda não estou 100% convencido.

A questão central foi: Afinal, sealed tem algum valor semântico?!

Para considerar:

  • Em .NET, classes geralmente são non-sealed. Ou seja, podem ser herdadas “livremente”;
  • Em .NET, métodos são, por default, sealed. Em Java, o oposto;
  • Métodos e classes sealed implicam em melhor performance de execução (dificilmente observável, mas real).

Para o Juan, sealed é um enfeite desnecessário, sem valor semântico, que permite ao compilador fazer uma otimização descartável (ou com resultado alcançavel de outras maneiras).

Para mim, sealed tem muita importância. Afinal, penso que devemos, ao escrever classe/método, considerar se este deverá ser “especializado” ou não (via heranças/overloads). Entretanto, reconheço que acabo lembrando de aplicar modificador quando o NDepend revisa meu código (Seria eu um “designer irresponsável?!”).

E você, o que acha?!

8 comentários em “Afinal, “sealed” tem algum valor semântico?!

  1. Fernando
    09/06/2012

    Acho o comentário do Juan um pouco extremista. O fato dele não encontrar utilidade não torna o recurso inútil (e parece que ele tem uma certa dificuldade pra entender isso).

    Concordo com você, Elemar. O modificador sealed é importante e tem o seu espaço. É fácil pensar em N absurdos que seriam possíveis se a classe String, por exemplo, não fosse marcada como sealed. Isso não quer dizer que o recurso deva ser utilizado “a rodo”, mas sim que devemos pensar com cuidado a respeito da extensibilidade de nossas classes.

    Uma correção: no .NET, os métodos não são sealed por padrão. Eles são “não virtuais”. Você pode marcar um método como sealed quando você faz um override.

    • Salve Elemar. Olha eu dando um pitaco aqui mais uma vez.
      Concordo contigo (sealed tem muita importância) e com o Fernando também quando ele disse que o comentário do Juan “extremista”.

      Mesmo com as considerações do .NET Framework, para GARANTIR que NÃO terá nenhuma mudança no comportamento de qualquer classe derivada com respeito a este método (contrário dos métodos virtuais) usamos de explicitamente e de fato.. sealed.

      Vejamos… selando um método damos permissão para que as partes da classe a serem sobrecarregadas, tornem os métodos sealed testáveis porém sem condições de serem personalizáveis…

      Meus 2 cents.
      Abraço meu rei.

    • elemarjr
      09/06/2012

      Por favor, poderia tornar mais clara a distinição entre sealed e não virtuais?!

      Pega leve com o Juan. O cara é muito bom, aprendo muito com ele, abigo. :D

      • Fernando
        09/06/2012

        Um método só pode ser sealed quando ele for um override. Isso permite que sua classe seja extensível, mas não permite que os filhos ela dêem um override nos comportamentos dos métodos em que você já havia dado override.

        Quando utilizado, o comportamento é semelhante ao de não ser virtual, mas a IL é clara na diferença:
        .method public hidebysig virtual final instance void Metodo() cil managed x .method public hidebysig instance void Metodo() cil managed (repare na presença de ‘virtual final’ no primeiro, que é o sealed). Ao declarar um método assim, você deixa clara a sua intenção de não permitir que os filhos sobrescrevam o comportamento do método.

        O Juan é muito bom sim. Admiro o conhecimento dele, só acho ele extremista, com um “quê” de complexo de superioridade quando o assunto é programação.

        Abraços e continue o excelente trabalho!

        • elemarjr
          10/06/2012

          Veja, eu acho que a diferença aqui são implicações do sealed em diferentes contextos. Não seria isso?!

          * Métodos marcados explicitamente como sealed (em overrides) precisam ainda ser identificados como virtual mas com implementação fechada (final) a partir daquele ponto.

          * Métodos não marcados como virtual são final por default.

          Não seria isso?!

  2. cirellolaranjo
    10/06/2012

    Eu não entendi ainda. A preocupação é desempenho ou “ambiente hostil”?

    Por questão de “ambiente”, por exemplo, se vou distribuir isso para alguém que não sei quem é e quero garantir algumas coisas, é válido. Mas se vou eu mesmo usar esse código, faz sentido perder tempo com essa conversa?

    E se estamos preocupados com desempenho nesse nível, talvez nem C# seja a solução. Talvez seja melhor pensar em algo mais baixo nível.

    • elemarjr
      10/06/2012

      Olá Laranjo,

      Para começar, considero todo ambiente potencialmente hostil. :D

      Penso que o meu código deve expressar o máximo possível o que eu estava pensando quando eu escrevi (é isso que eu quero dizer por “valor semântico”).

      Quanto mais meu código se explica, menos documento eu preciso. Quanto menos documento eu preciso, mais tempo para o código.

      Mesmo que eu seja um “exército de um Dev só”, ainda assim, precisarei dar manutenção no código e quanto mais feedback ele me der, melhor.

      Quanto a coisa da performance, realmente acho que os ganhos do sealed são “desprezíveis”. BTW, esse foi um ponto onde Juan e eu concordamos.

      []s

  3. Ricardo Noronha
    17/06/2012

    Na minha opinião o uso de sealed, tanto quanto virtual são importantes sim, e acredito que todo desenvolvedor deve avaliar em algum momento se aquela classe, ou método poderá ter seu comportamento alterado.

    Acredito que o ideal seria que não tendo a intenção de herdar a classe ou admitir um comportamento diferente no método, deva-se selá-lo para deixar explícito que tais possibilidades não foram pensadas na solução.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado em 09/06/2012 por em Post.

Estatísticas

  • 643,712 hits
%d blogueiros gostam disto: