Should Helper / classes de utilitários ser abstrato?

StackOverflow https://stackoverflow.com/questions/309553

  •  08-07-2019
  •  | 
  •  

Pergunta

Eu geralmente me pego extraindo comportamento comum fora das aulas em classes helper / utilidade que contêm nada além de um conjunto de métodos estáticos. Muitas vezes me perguntei se eu deveria estar declarando essas classes como abstrato, desde que eu realmente não posso pensar de uma razão válida para sempre instanciar esses?

O que os prós e contras ser a declarar tal classe como abstrata. 

public [abstract] class Utilities{

   public static String getSomeData(){
       return "someData";
   }

   public static void doSomethingToObject(Object arg0){
   }
}
Foi útil?

Solução

Você poderia simplesmente declarar um construtor privado que não faz nada.

O problema com declarar a classe "abstrato" é que a palavra-chave abstract geralmente significa que a classe se destina a ser uma subclasse e ampliado. Isso definitivamente não é o que você quer aqui.

Outras dicas

Não se preocupe tornando-abstrato, mas incluem um construtor sem parâmetros privada para impedi-los de nunca ser instanciado.

ponto de comparação para os interessados: em C # você declarar a classe a ser estática, tornando-o abstrato e selada (Final de Java) na forma compilada, e sem qualquer construtor de instância em tudo. Isso também faz com que seja um erro de tempo de compilação para declarar um parâmetro, variável, array etc desse tipo. Handy.

Eu não declarar classes de utilitários abstrato, eu declará-los final e fazer o construtor privado. Dessa forma, eles não podem ser uma subclasse e que não pode ser instanciado. 



public final class Utility
{
    private Utility(){}

    public static void doSomethingUseful()
    {
        ...
    }
}

Ao declarar-los como abstrato, você de fato está indicando a outros codificadores que você destinado para essas classes para ser derivado. Realmente, você está certo, que não há muita diferença, mas a semântica aqui são realmente mais sobre a interpretação de outras pessoas que olham para o seu código.

Gostaria de acrescentar mais um passo para além do construtor privado: 

public class Foo {
   // non-instantiable class
   private Foo() { throw new AssertionError(); }
}

Jogando os métodos evita AssertionError na mesma classe de instanciar a classe (bem, eles podem tentar). Isto normalmente não é um problema, mas em um ambiente de equipe que você nunca sabe o que alguém vai fazer.

No que diz respeito a palavra-chave "abstrato", tenho notado utilitários aulas subclasse em numerosos casos: 

public class CoreUtils { ... }
public class WebUtils extends CoreUtils { ... }

public class Foo { ... WebUtils.someMethodInCoreUtils() ... }

Eu acredito que este é feito para que as pessoas não tem que se lembrar que classe de utilitário para incluir. Existem quaisquer desvantagens para este? É este um anti-padrão?

Saudações, LES

Como outros declarou, fazer um construtor sem parâmetros privado. Ninguém pode criar uma instância de que, para além da própria classe.

Como já foi mostrado como é feito com outras linguagens, vem aqui como fazê-lo na próxima C ++ versão, como fazer uma classe não-instanciável: 

struct Utility { 
    static void doSomething() { /* ... */ } 
    Utility() = delete; 
};

Não, mas se o seu idioma suporta, há um forte argumento a ser feito que na maioria dos casos eles devem (podem) ser declarado como 'estático' ... estática informa o compilador que não pode ser instanciado, e que todos métodos em si deve ser estático.

Abstract é para as classes que têm detalhes de implementação baseada em instância, que será usado por instâncias de classes derivadas ...

alguém mencionou que em C # 3.0, você poderia fazer isso através de métodos de extensão. Eu não sou um cara de C #, que alguns de volta nos 1,5 / 2,0 dias, mas não tê-lo usado desde então. Com base em uma compreensão muito superficial Eu acho que algo semelhante pode ser realizado em java com importações estáticas. Eu percebo que não é de todo a mesma coisa, mas se o objetivo é apenas fazer esses métodos de serviços públicos parecem um pouco mais "nativo" (por falta de um termo melhor) para a classe chamando, eu acho que vai fazer o truque. Assumindo a classe Utilities declarei na minha pergunta original. 

import static Utilities.getSomeData;

public class Consumer {

    public void doSomething(){

        String data =  getSomeData();
    }

}

Eu poderia oferecer alguns conselhos construtivo?

Se você está fazendo um monte de presente, há dois problemas que você vai correr em.

Em primeiro lugar, um método estático que leva um parâmetro deve ser muitas vezes uma parte do objeto que é esse parâmetro. Sei que isso não ajuda para objetos como String, mas se for preciso objetos que você definiu, você poderia quase certamente melhorar o objeto, incluindo seu ajudante como um método desse objeto.

Se leva todos os valores nativos, você provavelmente poderia definir um objeto que é um método de. Veja se você pode encontrar qualquer agrupamento desses valores nativos e agrupá-los como um objeto. Se você apenas tentar isso, você vai encontrar um monte de outros usos para esse pequeno mini-objeto, e antes que você perceba que vai ser incrivelmente útil.

Outra coisa, se você tem uma classe de utilitário com um monte de semi-relacionado métodos estáticos e variáveis ??estáticas, você quase sempre quer que ele seja um Singleton. Descobri isso por tentativa e erro, mas quando você descobrir que você precisa mais do que 1 (eventualmente você vai), é muito mais fácil fazer um singleton em um multipleton (?), Em seguida, para tentar mudar uma classe estática em um multipleton ( ok, então eu estou fazendo palavras até agora).

Boa sorte. Este material foi principalmente tentativa e erro para mim - percebi isso como há 5 anos, porém, e eu nunca encontrei uma instância onde eu lamentou não ter classe / métodos estáticos

.
métodos

helper / utilidade são muito bem. Não se preocupe em adicioná-los a uma biblioteca dentro de sua aplicação ou Framework. A maioria dos quadros que eu vi usá-los em muitas variedades.

Dito isto, se você quiser ficar realmente astuto sobre eles você deve olhar para métodos de extensão em C # 3.0. Usando o método de extensão fará seus Utilities um pouco mais de uma parte "holística" do seu quadro que parece que o que você está tentando fazer, considerando para torná-los abstrato. Para não mencionar método de extensão são muito divertido de escrever!

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top