Subscribe to RSSNomeando classes
Quando se desenvolve um framework, muitos cuidados devem ser tomados, um dos que eu mais prezo é a clareza no que se refere o nome da classe, pois quanto mais óbvio, mas fácil é o aprendizado.
Antes de começar a trabalhar no DePO eu testei outros frameworks, um deles foi o tiOPF e umas das primeiras coisas que me chamou atenção foi a nomenclatura das classes, achei muito ruim de se trabalhar no dia a dia. Então para o próprio DePO, utilizamos o prefixo dpo, ex: TdpoPersistentObject, bem mas hoje, com o advento do .NET e o conceito de nomespaces, e também depois de utilizar muito OO, eu acho que quanto mais simples melhor.
Quase concluindo o Jazz SDK, eu resolvi rever algumas classes, como poderia otimizar algum código, pois quando comecei a projetá-lo, não tinha uma visão bem defininida do todo, agora que ja passei por praticamente todas etapas, vi que o que fiz no início, precisava ser revisado.
Me deparei com os nomes de algumas classes do ValueType Framework, com nomes esquisitos, mas estes nomes não poderiam ser simples, pois iriam entrar em conflito com classes da VCL: TObject, TObjectList, TDate, TMemo.
No início, eu usava o prefixo Jazz em todas as classes, então TObject ficaria TJazzObject, muito bom e bonito, mas redundante, principalmente se houver uma migração para .NET que tem namespaces, resolvi então deixar o nome das classes mais simples e colocar Jazz apenas no nome da unit, ex: JazzValueType.pas, mas como nomear estas classes que estão em conflito com a VCL? Inicialmente eu usei TValueObject, TValueObjectList, TValueType e TValueMemo, por que “Value” no nome? Value de ValueType, pois achei que TValueTypeObject ficaria muito longo, mas agora pensei e se eu colocasse TTypeObject ou TObjectType, não ficaria melhor? Agora vem as opções que pensei, e gostaria que você desse sua opinião e se possível dissesse o porquê.
- TValueTypeObject, TValueTypeObjectList, TValueTypeDate, TValueTypeMemo
- TValueObject, TValueObjectList, TValueDate, TValueMemo
- TTypeObject, TTypeObjectList, TTypeDate, TTypeMemo
- TObjectType, TObjectListType, TDateType, TMemoType
- TvtObject, TvtObjectList, TvtDate, TvtMemo
Não acho que utilizar o Jazz no nome seria legal, pois é o nome do SDK, e o framework é ValueType.
Aguardo sua opnião.
8 Comments
Eu, particularmente, prefiro “TvtObject…”. Por que:
- “vt” é bem significativo (Value Type)
- e é curto, não vai custar muito digitar e nem lembrar no nome….
Pra organizar as classes… segue a susgestão de leitura de um artigo meu publicado no site da clubedelphi..
http://www.devmedia.com.br/login/login.asp?erro=1&comp=1120
abraço
TObjectType, TObjectListType, TDateType, TMemoType.
Acredito que esta opção é a mais elegante.
Porém há o problema, por serem nomes muito genéricos, de conflitos com outras framewors ou componentes que se possa usar.
Em .NET tem a solução do namespaces, mas como fica com o win32 ?
Algo como o que está abaixo resolveria, acho.
TJObjectType, TJObjectListType, TJDateType, TJMemoType.
ou
TJazzObjectType, TJazzObjectListType, TJazzDateType, TJazzMemoType.
Eu acho que Jazz deve aparecer nas classes sim.
TJazzObjectType, TJazzObjectListType, TJazzDateType, TJazzMemoType.
Fica muito mais fácil identificar as classes do SDK como um todo.
Infelizmente Win32 ainda é o foco principal do Jazz, então temos que dar prioridade a ele na solução dos problemas, e como ele não tem namespaces, fica no nome da classe mesmo.
Sobre meu comentário anterior, o último parágrafo não saiu como eu queria.
Não quis dizer que é infeliz o motivo do Jazz estar focando Win32. O “infelizmente” é direcionado ao Win32 não suportar namespaces.
Espero que tenha ficado mais claro.
Concorco com o Flávio em utilizar os nomes TObjectType, TObjectListType, TDateType e TMemoType. Este é o padrão adotado pela Microsoft (um nome simples em inglês).
O conflito de nomes não vai existir se utilizar “fullname” ex: JazzValueType.TMemoType. Como seria no .NET e/ou Java.
César, a pior escolha, na minha opinião seria os nomes TvtObject, TvtObjectList, TvtDate e TvtMemo. Assim como nas boas práticas do .NET, não é encorajado utilizar prefixos nos nomes de classes (tb chamado de notação húngara). No entanto, prefixos na units eu concordo, pois não temos os namespaces para diferenciar.
PS: Acho que seria uma boa ideia montar um fórum para o Jazz…
Para o caso 1: TValueTypeObject, TValueTypeObjectList, TValueTypeDate, TValueTypeMemo
- Define bem, mas um pouco extenso veja o ObjectList, mas não deveríamos ser preguiçosos ao ponto de dizer que é ruim por que é extenso
Para o caso 2: TValueObject, TValueObjectList, TValueDate, TValueMemo
- Neste caso pode-se haver conflitos com outras classes do sistema do usuário. ex: TValueReferencia (para um dominio laboratorial por exemplo). Pode até ser uma herança de TValueObject, mas não pertence a hierarquia dos ValueTypes.
Para o caso 3: TTypeObject, TTypeObjectList, TTypeDate, TTypeMemo
- Acho que ele define legal, e nao haveria conflito por que geralmente quando se monta uma classe que tem o a palavra “Type”, este estaria no final do nome. ex: TPersonType.
Para o caso 4: TObjectType, TObjectListType, TDateType, TMemoType
- Este aqui sofreria conflitos como mostrado no exemplo do caso anterior.
Para o caso 5: TvtObject, TvtObjectList, TvtDate, TvtMemo
- Bem, desculpe Paulo mas eu acho este o pior de todos, mas esta é minha opinião ok? Hj sou totalmente contra abreviações, impede o usuário de bater o olho na coisa e já identificar pra que serve. Prefiro usar o primeiro caso à usar este quinto. “vt” pode ser tanta coisa
para o caso 6: TJazzObjectType, TJazzObjectListType, TJazzDateType, TJazzMemoType.
- Eu concordo com o Cesar na questão da nomeclatura nao envolver o nome do framework, inclusive pretendo remover o Infra dos nos das classes do Infra Framework tambem. Acredito que o nome na unit seja suficiente. Independente de Win32 ou .Net, namespace, eu acredito que dificilmente haverá confiltos. No Infra devo adotar o esquema do caso 3.
Bem pessoal, isso sinceramente é minha humilde (e longa) opinião.
Obrigado a todos pelos comentários
Paulo Quicoli, tentei acessar o ortigo, mas precisava de usuário e senha
Eu tinha uma preferência antes de postar, mas não expressar para não influenciar nas opiniões.
Os nomes [Low(TObjectType)..High(TMemoType)] (rs…) são os que mais me agrada, e repensando no caso, acho que fica bom padronizar todos os nomes das units JazzValueType.pas e JazzValueTypeIntf.pas para este padrão.
o prefixo Jazz nas units, também acho que se faz necessário.
Marcos, sim vou montar um fórum ou lista de discussão, na verdade toda a infra-estrutura esta sendo providenciada, criei uma conta para o Jazz no Novell Forge, mas to sem tempo de providenciar as configurações, se alguém aparacer pra ajudar nesta parte eu passo, se não assim que eu chegar na fase beta, eu passo pra infra-estrutura.
1. TValueTypeObject, TValueTypeObjectList, TValueTypeDate, TValueTypeMemo
This one includes the word “Type” which in my opinion should’t be used unless the class is a type of something. ex. TCompanyType. I also sounds redundant. I most if not all cases the word Type may be changed to Kind.
2. TValueObject, TValueObjectList, TValueDate, TValueMemo
I like this one better. Is not too long and describes the purpose of the class: Is a “Value”. The “TValue” prefix will most likely not be used in the application classes (ex. TValueReferencia -> TReferencia, TReference, TReferenceKind or TReferenceType).
3. TTypeObject, TTypeObjectList, TTypeDate, TTypeMemo
Same reson as 1
4. TObjectType, TObjectListType, TDateType, TMemoType
Same reson as 1
5. TvtObject, TvtObjectList, TvtDate, TvtMemo
I like this one and is short, although Delphi developers are used to think that the prefix means the brand.
My 2 cents