Quando defino métodos objetivo-c?

Question

Estou aprendendo Objective-C e tenho experiência em C/C++.

• Em C++ orientado a objetos, você sempre precisa declarar seu método antes de defini-lo (implementá-lo), mesmo que ele seja declarado na classe pai.

• No estilo processual C, IIRC, você pode definir apenas uma função, desde que ela seja chamada apenas de outra coisa na mesma unidade de compilação (ou seja,o mesmo arquivo) que veio posteriormente no arquivo (bem, desde que você não o declare em outro lugar com "extern").

• Agora, no Objective-C, parece que você só precisa declarar seletores no arquivo de cabeçalho se eles forem usados ​​por algo externo, e que você pode criar seletores em seu arquivo .m perfeitamente e chamá-los dentro o arquivo .m.Além disso, parece que métodos delegados ou métodos herdados nunca são (re)definidos.

Estou no caminho certo?Quando você precisa definir um seletor em Objective-C?

Answer 1

Para métodos Objective-C, a prática geral é colocar os métodos que você deseja expor no @interface seção do arquivo de cabeçalho para que outro código possa incluir apenas o .h e saiba como interagir com seu código.A "declaração preguiçosa" baseada em ordem funciona exatamente como funções em C - você não precisa declare um protótipo de método, a menos que você tenha uma dependência que não possa ser resolvida por pedido, mas você pode adicionar protótipos de método dentro do @implementation se necessário.

Então sim, você está no caminho certo.Não repita o protótipo do método para métodos herdados — o compilador o encontra no arquivo de cabeçalho do pai.Os métodos delegados podem ser definidos como protótipos em uma categoria (anexados a uma classe) e implementados conforme desejado, mas o delegado não precisa fornecer um protótipo de método, pois ele já está definido.(Ainda pode, se quiser, para maior clareza, etc.)

Como você está aprendendo Objective-C, o restante desta resposta contém muito mais detalhes do que você pediu.Você foi avisado.;-)

---

Quando você digita estaticamente uma variável (por exemplo MyClass* em vez de id) o compilador irá avisá-lo quando você tentar chamar um método que uma classe não anuncia que implementa, quer o faça ou não.Se você digitar a variável dinamicamente, o compilador não impedirá que você chame o que quiser e você só receberá erros de tempo de execução se chamar algo que não existe.No que diz respeito à linguagem, você pode chamar qualquer método que uma classe implemente sem erros em tempo de execução — não há como restringir quem pode chamar um método.

Pessoalmente, acho que isso é realmente uma coisa boa.Ficamos tão acostumados a encapsular e proteger nosso código de outros códigos que às vezes tratamos o chamador como um malfeitor desonesto, em vez de um colega de trabalho ou cliente confiável.Acho bastante agradável codificar com a mentalidade de "você faz o seu trabalho e eu faço o meu", onde todos respeitam os limites e cuidam de suas próprias coisas.Você pode dizer que a “atitude” do Objective-C é de confiança da comunidade, e não de aplicação estrita.Por exemplo, fico feliz em ajudar qualquer pessoa que venha até minha mesa, mas ficaria muito irritado se alguém mexesse em minhas coisas ou mudasse de lugar sem pedir.Um código bem projetado não precisa ser paranóico ou sociopata, apenas precisa funcionar bem em conjunto.:-)

Dito isso, existem muitas abordagens para estruturar suas interfaces, dependendo do nível de granularidade que você deseja/precisa na exposição de interfaces aos usuários.Quaisquer métodos declarados no cabeçalho público são essencialmente um jogo justo para qualquer pessoa usar.Ocultar declarações de método é um pouco como trancar seu carro ou casa - provavelmente não manterá todo mundo fora, mas (1) "mantém as pessoas honestas honestas" ao não tentá-las com algo com que não deveriam mexer, e (2 ) qualquer um que faz entrar certamente saberá que não deveria e não pode reclamar das consequências negativas.

Abaixo estão algumas convenções que uso para nomear arquivos e o que acontece em cada arquivo – começando com um arquivo .m na parte inferior, cada arquivo inclui o que está acima dele.(Usar uma cadeia estrita de inclusões evitará coisas como avisos de símbolos duplicados.) Alguns desses níveis se aplicam apenas a componentes reutilizáveis ​​maiores, como estruturas Cocoa.Adapte-os de acordo com suas necessidades e use os nomes que mais lhe agradarem.

• MyClass.h — API pública (interface de programação de aplicativos)
• MyClass_Private.h - SPI interno da empresa (interface de programação do sistema)
• MyClass_Internal.h — IPI interno do projeto (interface de programação interna)
• MyClass.m — Implementação, geralmente, de todas as declarações API/SPI/IPI
• MyClass_Foo.m — Implementação adicional, como para categorias

A API é para uso de todos e tem suporte público (geralmente em Foo.framework/Headers).O SPI expõe funcionalidades adicionais para clientes internos do seu código, mas com o entendimento de que o suporte pode ser limitado e a interface está sujeita a alterações (geralmente em Foo.framework/PrivateHeaders).O IPI consiste em detalhes específicos da implementação que nunca devem ser usados ​​fora do projeto em si, e esses cabeçalhos não estão incluídos na estrutura.Qualquer pessoa que opte por usar chamadas SPI e IPI o faz por sua própria conta e risco e, geralmente, em seu próprio prejuízo quando as alterações quebram seu código.:-)

Answer 2

Declarar os métodos no arquivo de cabeçalho apenas interromperá os avisos do compilador.Objective-C é uma linguagem dinâmica, então você pode chamar um método (enviar uma mensagem) para um objeto, independentemente de esse método ser declarado externamente ou não.

Além disso, se você definir um método no arquivo .m acima de qualquer código que o chame (declaração lenta), isso não gerará nenhum aviso.Porém, o mesmo se aplica: você pode enviar uma mensagem para um objeto sem que ele seja declarado.

Claro - isso significa que não existem métodos privados no Objective-C.Qualquer método implementado por uma classe pode ser chamado.

Preferência pessoal.Se for um método público (ou seja, usado externamente).declare-o em .h e defina em .m.Se você quiser limitar sua visibilidade, ou pelo menos indicar que é um método privado, use categorias/extensões de classe no arquivo .m.Embora muitos códigos de exemplo usem o método de declaração lenta.

Answer 3

Objective-C trata funções como "mensagens" e, como tal, você pode enviar uma "mensagem" para qualquer objeto - mesmo aquele que não declare explicitamente em sua interface que pode aceitar.Como resultado, não existem membros privados no Obj-C.

Isso pode ser muito poderoso, mas é uma fonte de confusão para novos programadores de Obj-C - especialmente aqueles vindos de C++, Java ou C#.Aqui estão as regras básicas:

• Você deve definir todos os métodos públicos em sua @interface para que os consumidores saibam quais mensagens você espera tratar.
• Você deve definir métodos @private em sua @interface para evitar mensagens do compilador e evitar ter que ordenar os métodos em sua @implementation.
• Você deve usar protocolos ao implementar uma convenção específica de métodos para sua classe.

Muito disso é preferência pessoal, mas ajuda a evitar avisos irritantes do compilador e mantém seu código organizado.e fácil de entender.