none
Classes dentro de outras classes. RRS feed

  • Pergunta

  • Pessoal, 

    Sabemos que podemos criar classes dentro de outras classes.

    É errado criar uma classe dentro da outra, mesmo quando as 2 tenham a mesma ligação.

    Exemplo:
    Meu amigo prefere criar uma pasta e criar umas 10 classes soltas na solução que tenha a mesma ligação com a classe principal.

    Eu já acho interessante criar uma classe apenas, e todas as outras serem criadas dentro dessa classe.

    Exemplo:

    Classe Carro
    Dentro da classe Carro, criamos a classe: CarroPesquisa e assim de acordo com a minha necessidade.

    Ele disse que criar classe fora de outra classe está fora do conceito de programação orientada a objeto. Sendo que pesquisando, isso não muda em nada, somente é apenas uma situação de design adotada pelo desenvolvedor.

    quarta-feira, 2 de janeiro de 2013 17:56

Respostas

  • Cara...

    Eu acho que não tem nada a ver...

    Eu crio fora (na maioria das vezes até em outro arquivo)...

    Mas pela Classe "CarroPesquisa" estar implementada DENTRO da classe "Carro", ela não estará visível dentro do escopo do Namespace.

    Por exemplo:

    Imagina que a classe "Carro" está dentro do namespace (pasta, por exemplo) "Veiculos"... Daí vc consegue chamar uma instância da classe "Carro" simplesmente pelo nome "new Veiculos.Carro()"...

    Seguindo a linha de raciocínio do seu brother ae... Toda vez que vc quiser instanciar uma classe "CarroPesquisa", vc terá que chamar "new Veiculos.Carro.CarroPesquisa()"...

    Não acho isso tão produtivo.

    • Marcado como Resposta Rodrigo Epic terça-feira, 15 de janeiro de 2013 17:57
    quinta-feira, 3 de janeiro de 2013 16:40
  • Amigo, com relação a programação orientada a objeto, ou não entendi ou o que seu amigo disse não faz sentido. Criamos classes em arquivos separados para organização, controle e facilidade para outros programadores visualizarem e se acharem no código.

    Na questão de programação orientada a objetos, podem ser usados padrões(modelos) de projetos que separam as classes de acordo sua responsabilidade, por exemplo em camadas,  N-tiers, MVC, etc.

    • Marcado como Resposta Rodrigo Epic terça-feira, 15 de janeiro de 2013 17:57
    quinta-feira, 3 de janeiro de 2013 21:11
  • É errado por este motivo:

    Você tem um arquivo com dezenas de classes, você precisa alterá-la.

    Seus colegas também precisam alterar este arquivo, mas uma outra classe diferente da sua (todas estão contidas no arquivo).

    Provavelmente você usa um controle de versão, então ferrou. Apenas um vai poder alterar por vez.

    Se você criar em arquivos diferentes, você modulariza; o que permite que você trabalhe separadamente apenas na parte desejada, permitindo seus colegas trabalharem em outras partes simultaneamente.

    Não recomendo a prática da classe gorda!


    • Editado MarceloSchneider sexta-feira, 4 de janeiro de 2013 13:01
    • Marcado como Resposta Rodrigo Epic terça-feira, 15 de janeiro de 2013 17:57
    sexta-feira, 4 de janeiro de 2013 13:00

Todas as Respostas

  • Cara...

    Eu acho que não tem nada a ver...

    Eu crio fora (na maioria das vezes até em outro arquivo)...

    Mas pela Classe "CarroPesquisa" estar implementada DENTRO da classe "Carro", ela não estará visível dentro do escopo do Namespace.

    Por exemplo:

    Imagina que a classe "Carro" está dentro do namespace (pasta, por exemplo) "Veiculos"... Daí vc consegue chamar uma instância da classe "Carro" simplesmente pelo nome "new Veiculos.Carro()"...

    Seguindo a linha de raciocínio do seu brother ae... Toda vez que vc quiser instanciar uma classe "CarroPesquisa", vc terá que chamar "new Veiculos.Carro.CarroPesquisa()"...

    Não acho isso tão produtivo.

    • Marcado como Resposta Rodrigo Epic terça-feira, 15 de janeiro de 2013 17:57
    quinta-feira, 3 de janeiro de 2013 16:40
  • Amigo, com relação a programação orientada a objeto, ou não entendi ou o que seu amigo disse não faz sentido. Criamos classes em arquivos separados para organização, controle e facilidade para outros programadores visualizarem e se acharem no código.

    Na questão de programação orientada a objetos, podem ser usados padrões(modelos) de projetos que separam as classes de acordo sua responsabilidade, por exemplo em camadas,  N-tiers, MVC, etc.

    • Marcado como Resposta Rodrigo Epic terça-feira, 15 de janeiro de 2013 17:57
    quinta-feira, 3 de janeiro de 2013 21:11
  • É errado por este motivo:

    Você tem um arquivo com dezenas de classes, você precisa alterá-la.

    Seus colegas também precisam alterar este arquivo, mas uma outra classe diferente da sua (todas estão contidas no arquivo).

    Provavelmente você usa um controle de versão, então ferrou. Apenas um vai poder alterar por vez.

    Se você criar em arquivos diferentes, você modulariza; o que permite que você trabalhe separadamente apenas na parte desejada, permitindo seus colegas trabalharem em outras partes simultaneamente.

    Não recomendo a prática da classe gorda!


    • Editado MarceloSchneider sexta-feira, 4 de janeiro de 2013 13:01
    • Marcado como Resposta Rodrigo Epic terça-feira, 15 de janeiro de 2013 17:57
    sexta-feira, 4 de janeiro de 2013 13:00
  • Muito obrigado pessoal pelos esclarecimentos.
    Abraços
    terça-feira, 15 de janeiro de 2013 17:57