Na minha opinião, o nome de uma entidade não deve transmitir informações sobre sua estrutura de tipos, mas sobre sua semântica. Portanto, não faz sentido definir sua classe como "AbstractSomething" se a abstração não fizer parte de seu objetivo de tempo de execução. O fato de ser uma classe abstrata de base é visível para o programador e não precisa ser refletido no nome.
No entanto, se torna perfeito chamar uma implementação de uma fábrica abstrata de AbstractFactory, porque isso se relaciona com a intenção da classe.
Em geral, apóie a convenção de nomenclatura que ajuda a transmitir o máximo de informações sobre o objetivo da sua classe.
Da mesma forma, fique longe de SomethingImpl. Não nos importamos que seja uma implementação e não uma classe base. Se sua hierarquia de classes foi projetada corretamente para herança, alguém poderá herdar dela. Certamente não haveria valor neles adicionando mais sufixos "Impl" ou outros artefatos. Também não há valor em adicionar um sufixo "Interface" ou prefixo "I".
Considerar:
IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl
Ao contrário de:
Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
<-- Ferrari
<-- Trabi
Eu prefiro o último de longe.
Isso, de certa forma, é semelhante ao uso indevido flagrante da Notação Húngara que lhe deu sua má reputação , pois as pessoas começaram a interpretá-la erroneamente como exigindo que os desenvolvedores prefixassem suas variáveis com um indicador do tipo da variável. Embora isso às vezes possa ter seus usos (principalmente se você tiver preguiça de procurar a definição do tipo), é geralmente inútil. A idéia original de Simonyi com a notação húngara era usá-la como um mnemônico para lembrar o desenvolvedor das capacidades da entidade, não de seu tipo.