No entanto, sem construções de linguagem orientada a objetos, um programador pode ainda introduzir características OO em código PHP. É um pouco mais difícil e pode tornar o código mais difícil de ler porque é mistura paradigmas (linguagem procedural com pseudo-OO design). OO construções em código PHP - tais como a capacidade de definir e usar classes, a capacidade de construir relacionamentos entre as classes que usam herança, e a capacidade de definir interfaces - torná-lo muito mais fácil construir um código que adere às boas práticas OO.
Enquanto os projetos puramente processual, sem modularidade muito correr bem, as vantagens do design OO aparecem na manutenção. Porque uma aplicação típica gastará a maior parte da sua vida útil em manutenção, a manutenção do código é uma grande despesa ao longo da vida de um aplicativo. Também pode ser facilmente esquecida durante o desenvolvimento. Se você estiver em uma corrida para obter o seu aplicativo desenvolvido e implantado, a longo prazo de manutenção pode ter um assento traseiro para conseguir algo para o trabalho.
Modularidade - uma das características-chave do bom design OO - ajuda com essa manutenção. Modularidade ajuda a encapsular a mudança, o que tornará mais fácil de estender e modificar a aplicação ao longo do tempo.
Embora existam mais de sete hábitos para a construção de software OO geral, os sete hábitos aqui são o que você precisa para tornar seu código se enquadram aos critérios básicos de design OO. Eles te dão uma base sólida sobre a qual você pode adicionar mais hábitos OO e construir software que é facilmente mantida e ampliada. Estes hábitos alvo de um par das principais características de modularidade. Para mais informações sobre os benefícios do design OO que são independentes de linguagem, veja Recursos .
Os sete bons hábitos PHP OO são:
- Ser modesto.
- Seja um bom vizinho.
- Evite olhar para Medusa.
- Abrace o elo mais fraco.
- Você está em borracha, estou cola.
- Mantê-lo na família.
- Pense em padrões.
Ser modesto
Para ser modesto é evitar expor-se em suas implementações de classes e funções. Escondendo a sua informação é um hábito fundamental. Você terá um tempo difícil criar qualquer um dos outros hábitos até que você tenha desenvolvido o hábito de esconder os detalhes de suas implementações. Esconder informação também é conhecido como encapsulamento.
Existem muitas razões pelas quais a exposição campos públicos diretamente é um mau hábito, a mais importante das quais é que ele deixa você sem opções devem mudar algo em sua implementação. Você usa conceitos OO isolar a mudança, e encapsulamento desempenha um papel integral em assegurar que todas as alterações feitas não são de natureza viral. Viralmudanças são aquelas que começam pequenas - como mudar uma matriz que contém três elementos para uma que contém apenas dois. De repente, você descobrir que você está mudando cada vez mais do seu código para acomodar uma mudança que deveria ter sido trivial.
Uma maneira simples de começar a ocultar a sua informação é para manter campos privados e expô-los com os assessores públicos, que são como janelas em sua casa. Em vez de ter uma parede inteira aberta ao exterior, você tem apenas uma janela ou dois. (Falo mais sobre assessores em " Bom Hábito: Use acessores públicos . ")
Além de permitir sua implementação por trás da cortina de mudar, usando acessores públicos em vez de expor diretamente campos permite que você construa em cima de sua implementação base, substituindo a implementação de um assessor para fazer algo um pouco diferente do comportamento do pai. Ele também permite que você construa uma implementação abstrata que adia a implementação real para classes que substituir a base.
Mau hábito: Expor campos públicos
No exemplo de código ruim na Lista 1, os campos da
Pessoa objeto estão expostos diretamente como campos públicos em vez de com assessores. Embora este comportamento é tentador, especialmente para objetos de dados leves, ele limita-lo.Listagem 1. Mau hábito de expor campos públicos
<? Php
classe Pessoa
{
prefixo $ público;
givenName $ público;
familyName $ público;
sufixo $ público;
}
$ Pessoa = new Pessoa ();
$ Pessoa-> prefix = "Mr.";
$ Pessoa-> givenName = "João";
echo ($ pessoa-> prefix);
echo ($ pessoa-> givenName);
?>
|
Se alguma coisa muda com o objeto, qualquer código que usa ele precisa mudar também. Por exemplo, se a pessoa deu, nomes de família, e outros eram para ser encapsulado em um
PersonName objeto, você precisaria modificar todo o seu código para acomodar a alteração.
Bom hábito: Use acessores públicos
Usando bons hábitos OO (veja a Listagem 2), o mesmo objeto agora tem campos privados em vez de campos públicos, privados e os campos são cuidadosamente expostas para o mundo exterior por entidades públicas
obter e definir métodos, chamados assessores. Esses assessores agora fornecer um público forma de obter informações de sua classe PHP de modo que se algo em mudanças a sua implementação, a probabilidade é menor que você precisa mudar todo o código que usa a classe.Listagem 2. Bom hábito de usar acessores públicos
<? Php
classe Pessoa
{
prefixo $ privadas;
givenName $ privadas;
familyName $ privadas;
sufixo $ privadas;
setPrefix função pública ($ prefix)
{
$ This-> prefix = $ prefix;
}
getPrefix função pública ()
{
return $ this-> prefixo;
}
setGivenName função pública ($ gn)
{
$ This-> givenName = $ gn;
}
getGivenName função pública ()
{
return $ this-> givenName;
}
setFamilyName função pública ($ fn)
{
$ This-> familyName = $ fn;
}
getFamilyName função pública ()
{
return $ this-> familyName;
}
setSuffix função pública ($ sufixo)
{
$ This-> $ sufixo = sufixo;
}
getSuffix função pública ()
{
return $ sufixo;
}
}
$ Pessoa = new Pessoa ();
$ Pessoa-> setPrefix ("Sr.");
$ Pessoa-> setGivenName ("John");
echo ($ pessoa-> getPrefix ());
echo ($ pessoa-> getGivenName ());
?>
|
À primeira vista, isto pode parecer muito mais trabalho, e isso pode ser realmente mais trabalho no front end. Normalmente, no entanto, usando bons hábitos OO compensa no longo prazo, como mudanças futuras são muito solidificado.
Na versão do código mostrado na Listagem 3, eu mudei a implementação interna de usar um array associativo para as peças nome. Idealmente, eu teria que lidar com mais erros e seria mais cuidadoso com a verificação se o elemento existe, mas o propósito deste exemplo é mostrar como o código usando minha classe não precisa mudar - é alegremente inconscientes da minha classe alterações. Lembre-se que a razão para a adopção de hábitos OO é encapsular cuidadosamente a mudança que o seu código é mais extensível e de fácil manutenção.
Listagem 3. Outra reviravolta nessa bom hábito com uma implementação diferente internos
<? Php
classe Pessoa
{
private $ PersonName = array ();
setPrefix função pública ($ prefix)
{
$ This-> PersonName ['prefixo'] = $ prefix;
}
getPrefix função pública ()
{
return $ this-> PersonName ['prefixo'];
}
setGivenName função pública ($ gn)
{
$ This-> PersonName ['givenName'] = $ gn;
}
getGivenName função pública ()
{
return $ this-> PersonName ['givenName'];
}
/ * Etc .. * /
}
/ *
* Mesmo que a implementação interna alterada, o código aqui permanece exatamente
* O mesmo. A mudança foi encapsulada somente para a classe Pessoa.
* /
$ Pessoa = new Pessoa ();
$ Pessoa-> setPrefix ("Sr.");
$ Pessoa-> setGivenName ("John");
echo ($ pessoa-> getPrefix ());
echo ($ pessoa-> getGivenName ());
?>
|
Seja um bom vizinho
Quando você constrói uma classe, ele deve lidar com seus próprios erros de forma apropriada. Se a classe não sabe como lidar com os erros, deve empacotá-los em um formato que o seu interlocutor entende. Além disso, evitar o retorno de objetos que são nulos ou em um estado inválido. Muitas vezes, você pode fazer isso simplesmente através da verificação de argumentos e lançar exceções específicas que dizer porque os argumentos fornecidos são inválidos. Quando você constrói esse hábito, você pode economizar - e as pessoas manter o seu código ou usando seus objetos - um monte de tempo.
Mau hábito: Não tratamento de erros
Considere o exemplo mostrado na Listagem 4, que aceita alguns argumentos e retorna uma
pessoa objeto com alguns dos valores preenchidos. No entanto, no parsePersonName () método, não há validação para ver se o fornecido $ val variável é nulo, uma string de comprimento zero ou talvez uma string em um formato não analisável. O parsePersonName () método não retorna um Person objeto, mas retorna null. Administradores ou programadores que usam este método pode ser a coçar a cabeça e - no mínimo - estar em um lugar onde eles precisam para começar a definir pontos de interrupção e depurar o script PHP.Listagem 4. Mau hábito de não jogar ou tratamento de erros
PersonUtils classe
{
parsePersonName public static function ($ format, $ val)
{
if (strpos (",", $ val)> 0) {
$ Pessoa = new Pessoa ();
$ Partes = split (",", $ val) / / Suponha que o valor é passado, primeira
$ Pessoa-> setGivenName ($ partes [1]);
$ Pessoa-> setFamilyName ($ partes [0]);
}
return $ pessoa;
}
}
|
O
parsePersonName () método na Listagem 4 poderia ser modificado para inicializar a pessoa fora do objeto se condição, garantindo que você sempre obter uma válida Pessoa objeto. No entanto, você tem uma pessoa sem definir propriedades, que não o deixa em uma posição muito melhor.
Bom Hábito: Cada módulo lida com seus próprios erros
Em vez de deixar seu palpite chamadores, ser pró-ativo sobre a validação de argumentos. Se uma variável unset não pode produzir um resultado válido, verifique se a variável e lançar uma
InvalidArgumentException . Se a cadeia não pode ser vazio ou deve ser em um formato específico, verifique o formato e lançar uma exceção. Listagem 5 demonstra como criar suas próprias exceções, assim como algumas novas condições na parsePerson () método que demonstram algumas validações rudimentares.Listagem 5. Bom hábito de erros jogando
<? Php
classe InvalidPersonNameFormatException estende LogicException {}
PersonUtils classe
{
parsePersonName public static function ($ format, $ val)
{
if (! formato $) {
throw InvalidPersonNameFormatException nova ("formato PersonName inválido.");
}
if ((isset ($ val)) |! | strlen ($ val) == 0) {
throw InvalidArgumentException novo ("deve fornecer um valor não nulo para analisar.");
}
}
}
?>
|
A linha inferior é que você quer que as pessoas sejam capazes de usar sua classe sem ter que saber o funcionamento interno do mesmo. Se usarem incorretamente ou de forma que você não tinha a intenção, eles não deveriam ter de adivinhar por que ele não funcionou. Como um bom vizinho, você entende que as pessoas reuso de sua classe não é psíquica, e, portanto, de tomar as conjecturas fora.
Evite olhar para Medusa
Quando eu estava começando a aprender sobre os conceitos de OO, eu era duvidoso que as interfaces foram realmente útil. Um colega meu chamou a analogia que não usar interfaces é como olhar para a cabeça de Medusa. Na mitologia grega, Medusa era uma personagem feminina com cobras para o cabelo. Qualquer pessoa que olhou para ela diretamente transformado em pedra. Perseus, que matou Medusa, foi capaz de confrontá-la, olhando para seu reflexo em seu escudo, evitando assim ser transformado em pedra.
Interfaces são o seu espelho para lidar com Medusa. Quando você usa uma implementação específica, concreta, seu código deve mudar se as alterações código de implementação. Usando implementações diretamente muitos limites de suas opções, como você virou as aulas essencialmente para a pedra.
Mau hábito: Não usando interfaces
Listagem 6 mostra um exemplo que carrega o
Person objeto de um banco de dados. Que leva o nome da pessoa e retorna oPerson objeto no banco de dados que corresponda.Listagem 6. Mau hábito de não usar interfaces
<? Php
classe DBPersonProvider
{
getPerson função pública ($ givenName, $ familyName)
{
/ * Ir para o banco de dados, se a pessoa ... * /
$ Pessoa = new Pessoa ();
$ Pessoa-> setPrefix ("Sr.");
$ Pessoa-> setGivenName ("John");
return $ pessoa;
}
}
/ * Preciso obter dados pessoa ... * /
$ Fornecedor = new DBPersonProvider ();
$ Pessoa = $ provedor> getPerson ("John", "Doe");
echo ($ pessoa-> getPrefix ());
echo ($ pessoa-> getGivenName ());
?>
|
O código para carregar
Person do banco de dados é muito bem até que algo muda no ambiente. Por exemplo, carregar Persondo banco de dados pode ser bom para a primeira versão do aplicativo, mas para a segunda versão, você pode precisar adicionar a capacidade de carregar uma pessoa de um Web Service. Em essência, a classe tem transformado em pedra, pois é diretamente usando a classe de implementação e agora é frágil a mudar.
Bom hábito: interfaces Use
Listagem 7 mostra um exemplo de código que não muda como novas formas de usuários de carga ficam disponíveis e são implementados. O exemplo mostra uma interface chamada
PersonProvider , que declara um único método. Se algum código usa um PersonProvider , o código restringe de usar as classes de implementação diretamente. Em vez disso, ele usaPersonProvider como se fosse um objeto real.Listagem 7. Bom hábito do uso de interfaces
<? Php
interface de PersonProvider
{
getPerson função pública ($ givenName, $ familyName);
}
classe implementa DBPersonProvider PersonProvider
{
getPerson função pública ($ givenName, $ familyName)
{
/ * Pretendo ir para o banco de dados, se a pessoa ... * /
$ Pessoa = new Pessoa ();
$ Pessoa-> setPrefix ("Sr.");
$ Pessoa-> setGivenName ("John");
return $ pessoa;
}
}
classe PersonProviderFactory
{
public static função createProvider ($ type)
{
if ($ tipo == 'banco de dados')
{
return new DBPersonProvider ();
Else {}
return new NullProvider ();
}
}
}
$ Config = 'banco de dados';
/ * Preciso obter dados pessoa ... * /
$ Provider = PersonProviderFactory:: createProvider ($ config);
$ Pessoa = $ provedor> getPerson ("John", "Doe");
echo ($ pessoa-> getPrefix ());
echo ($ pessoa-> getGivenName ());
?>
|
Quando você usa interfaces, tentar evitar sempre referindo-se as classes de implementação diretamente. Em vez disso, use algo externo a seu objeto para lhe dar a correcta aplicação. Se sua classe carrega a execução com base em alguma lógica, ele ainda precisa de exigir as definições de todas as classes de implementação, e que não leva a lugar nenhum.
Você pode usar um padrão Fábrica para criar uma instância de uma classe de implementação que implementa sua interface. A
fábrica de método, por convenção, começa com a criação e retorna a interface. Pode levar o que quer que os argumentos são necessárias para a sua fábrica para descobrir qual classe de implementação é o correto para retornar.
Na Listagem 7, o
createProvider () método simplesmente leva um tipo de $ . Se o tipo de $ é definida como banco de dados , a fábrica retorna uma instância da DBPersonProvider . Qualquer nova implementação para carregar pessoas de uma loja não necessita de nenhuma alteração na classe que usa a fábrica e interface. O DBPersonProvider implementa oPersonProvider interface e tem a aplicação efectiva do getPerson () método nela.
Abrace o elo mais fraco
Vagamente acoplamento seus módulos é uma coisa boa, é uma das propriedades que lhe permite encapsular a mudança. Dois dos outros hábitos - "Seja modesto" e "Evite olhar para Medusa" - ajudam você a trabalhar para a construção de módulos que são fracamente acoplados. Para vagamente casal suas aulas, desenvolver a característica final, construindo o hábito de baixar as dependências de suas classes.
Mau hábito: acoplamento forte
Na Listagem 8, dependências redução não é necessariamente reduzir as dependências para o cliente usando um objeto. Pelo contrário, o exemplo demonstra diminuição suas dependências na classe correta e minimizá-los em outro lugar.
Listagem 8. Mau hábito de acoplamento forte de
Endereço
<? Php
require_once "AddressFormatters.php /.";
Endereço de classe
{
private $ AddressLine1;
private $ AddressLine2;
$ cidade privadas;
estado $ privadas; / / ou província ...
private $ postalCode;
private $ país;
setAddressLine1 função pública ($ linha1)
{
$ This-> AddressLine1 = $ linha1;
}
/ * Acessores, etc .. * /
getCountry função pública ()
{
return $ this-> país;
}
formato da função pública ($ type)
{
if ($ tipo == "inline") {
$ Formatter = InlineAddressFormatter new ();
} Else if ($ tipo == "multiline") {
$ Formatter = MultilineAddressFormatter new ();
Else {}
$ Formatter = NullAddressFormatter new ();
}
return $ formatador-> format ($ this-> getAddressLine1 (),
$ This-> getAddressLine2 (),
$ This-> getCity (), $ this-> getState (), $ this-> getPostalCode (),
$ This-> getCountry ());
}
}
$ Addr = Endereço new ();
$ Addr-> setAddressLine1 ("123 Qualquer St.");
$ Addr-> setAddressLine2 ("Ste 200");
$ Addr-> setCity ("Anytown");
$ Addr-> setState ("AY");
$ Addr-> setPostalCode ("55555-0000");
$ Addr-> setCountry ("EUA");
echo ($ addr-> formato ("multiline"));
echo ("\ n");
echo ($ addr-> format ("inline"));
echo ("\ n");
?>
|
O código que chama o
format () método no endereço objeto pode olhar grande - tudo que faz é usar o endereço de classe, chamada format () , e ele é feito. Em contraste, os endereços de classe não é a mesma sorte. Ele precisa saber sobre os formatadores de vários usado para formatar corretamente, o que não pôde fazer a Endereço objeto muito reutilizável para alguém, especialmente se esse alguém não está interessado em usar as classes do formatador nos format () método.Embora o código usando endereços não tem muitas dependências, o endereço de classe tem muito poucos, quando ele provavelmente deve ser apenas um objeto de dados simples.
O
endereço de classe está intimamente ligado com as classes de implementação que sabe como formatar o Endereço objeto.
Bom hábito: Baixo acoplamento entre os objetos
Ao construir bons projetos OO, é necessário pensar em um conceito chamado de Separação de Preocupações (SoC). SoC significa que você tentar separar objetos por que eles deveriam estar realmente preocupados, assim, diminuindo o acoplamento.No original
Endereço de classe, teve que se preocupar sobre como formatar em si. Que provavelmente não é um bom projeto.Em vez disso, um endereço de classe deve pensar sobre as partes do Endereço , enquanto algum tipo de formatador deve se preocupar sobre como formatar corretamente o endereço.
Na Listagem 9, o código que formatou o endereço é movido para interfaces, classes de implementação, e uma fábrica - a construção do "interfaces use" hábito. Agora, o
AddressFormatUtils classe é responsável por criar um formatador e formatação de um endereço . Qualquer outro objeto agora pode usar um endereço sem ter que se preocupar também requer as definições dos formatadores.Listagem 9. Bom hábito de baixo acoplamento entre os objetos
<? Php
interface de AddressFormatter
{
formato da função pública ($ AddressLine1, AddressLine2 $, $ cidade, $ estado,
$ PostalCode, $ country);
}
MultiLineAddressFormatter classe implementa AddressFormatter
{
formato da função pública ($ AddressLine1, AddressLine2 $, $ cidade, $ estado,
$ PostalCode, $ country)
{
retorno sprintf ("% s \ n% s \ n% s,% s% s \ n% s",
AddressLine1 $, $ AddressLine2, $ cidade, $ estado, $ postalCode, $ country);
}
}
InlineAddressFormatter classe implementa AddressFormatter
{
formato da função pública ($ AddressLine1, AddressLine2 $, $ cidade, $ estado,
$ PostalCode, $ country)
{
retorno sprintf ("% s% s,% s,% s% s% s",
AddressLine1 $, $ AddressLine2, $ cidade, $ estado, $ postalCode, $ country);
}
}
AddressFormatUtils classe
{
função public static formatAddress ($ tipo, $ endereço)
{
$ Formatter = AddressFormatUtils:: createAddressFormatter ($ tipo);
return $ formatador-> format ($ endereco-> getAddressLine1 (),
$ Endereco-> getAddressLine2 (),
$ Endereco-> getCity (), $ endereco-> getState (),
$ Endereco-> getPostalCode (),
$ Endereco-> getCountry ());
}
createAddressFormatter função private static ($ type)
{
if ($ tipo == "inline") {
$ Formatter = InlineAddressFormatter new ();
} Else if ($ tipo == "multiline") {
$ Formatter = MultilineAddressFormatter new ();
Else {}
$ Formatter = NullAddressFormatter new ();
}
return $ formatador;
}
}
$ Addr = Endereço new ();
$ Addr-> setAddressLine1 ("123 Qualquer St.");
$ Addr-> setAddressLine2 ("Ste 200");
$ Addr-> setCity ("Anytown");
$ Addr-> setState ("AY");
$ Addr-> setPostalCode ("55555-0000");
$ Addr-> setCountry ("EUA");
echo (AddressFormatUtils:: formatAddress ("multiline", $ addr));
echo ("\ n");
echo (AddressFormatUtils:: formatAddress ("inline", $ addr));
echo ("\ n");
?>
|
A desvantagem, claro, é que sempre que os padrões são usados, muitas vezes significa a quantidade de artefatos (classes, arquivos) sobe. No entanto, esse aumento é compensado pela diminuição de manutenção em cada classe e pode ser diminuído ainda mais quando a reutilização adequada é adquirida.
Você está em borracha, estou cola
Projetos altamente coeso OO estão focados e organizados em módulos relacionados. Aprender sobre "preocupações" é importante para determinar como organizar funções e classes para ser bem coesa.
Mau hábito: a coesão Baixo
Quando um projeto tem baixa coesão, que tem classes e métodos que não são agrupados bem. O termo código espaguete é frequentemente usado para descrever classes e métodos que são agrupados em conjunto e têm baixa coesão. Lista 10 fornece um exemplo de código espaguete. O relativamente genérica
Utils classe usa muitos objetos diferentes e tem muitas dependências. Ele faz um pouco de tudo, o que dificulta a reutilização.Listagem 10. Mau hábito de baixa coesão
<? Php
Utils classe
{
função public static formatAddress ($ formatType, $ address1,
Address2 $, $ cidade, $ estado)
{
retorno "string algum endereço";
}
formatPersonName public static function ($ formatType, $ givenName,
$ FamilyName)
{
return "nome de alguma pessoa";
}
função public static parseAddress ($ formatType, $ val)
{
/ / Implementação real poderia definir valores, etc ..
Endereço retorno new ();
}
parseTelephoneNumber public static function ($ formatType, $ val)
{
/ / Implementação real poderia definir valores, etc ..
retorno telephoneNumber new ();
}
}
?>
|
Bom hábito: Embrace alta coesão
Alta coesão significa que classes e métodos que estão relacionados entre si são agrupados. Se os métodos e classes são altamente coeso, você é capaz de facilmente se separou grupos inteiros sem afetar o design. Projetos com alta coesão oferecem a oportunidade para baixo acoplamento. A Listagem 11 mostra dois dos métodos que estão mais bem organizados em classes.O
AddressUtils classe contém métodos para lidar com Endereço classes e mostra alta coesão entre os métodos relacionados com o endereço. Da mesma forma, PersonUtils contém métodos que lidam especificamente com Pessoa objetos. Estas duas novas classes com seus métodos altamente coesos têm baixo acoplamento, porque eles podem ser usados de forma totalmente independente um do outro.Listagem 11. Bom hábito de alta coesão
<? Php
AddressUtils classe
{
função public static formatAddress ($ formatType, $ address1,
Address2 $, $ cidade, $ estado)
{
retorno "string algum endereço";
}
função public static parseAddress ($ formatType, $ val)
{
/ / Implementação real poderia definir valores, etc ..
Endereço retorno new ();
}
}
PersonUtils classe
{
formatPersonName public static function ($ formatType, $ givenName,
$ FamilyName)
{
return "nome de alguma pessoa";
}
parsePersonName public static function ($ formatType, $ val)
{
/ / Implementação real poderia definir valores, etc ..
retorno PersonName new ();
}
}
?>
|
Mantê-lo na família
Costumo dizer às pessoas nas equipes de software em que eu fui um líder técnico ou arquiteto que o maior inimigo de linguagens OO é uma operação de copiar e colar. Quando usado na ausência de um projeto OO up-front, nada cria mais confusão do que copiar código de um arquivo para o seguinte. Onde quer que você esteja tentado a copiar o código de uma classe para outra, pare e pense em como você pode usar hierarquias de classe para alavancar semelhantes ou funcionalidade idêntica. Você vai descobrir que na maioria dos casos, com um bom design, copiar o código é completamente desnecessário.
Mau hábito: Não utilizar hierarquias de classe
A Listagem 12 mostra um exemplo simples de classes parciais. Eles começam com campos duplicados e métodos - não é bom a longo prazo quando o aplicativo pode precisar de mudar. Se houvesse um defeito na
pessoa de classe, não seria mais provável ser um defeito no Employee classe, mas também porque parece que a implementação foi copiada entre os dois.Listagem 12. Mau hábito de não usar hierarquias
<? Php
classe Pessoa
{
givenName $ privadas;
familyName $ privadas;
}
classe Employee
{
givenName $ privadas;
familyName $ privadas;
}
?>
|
Herança é um hábito difícil de começar a usar, porque muitas vezes, a análise para construir modelos de herança apropriada pode ter um monte de tempo. Por outro lado, usando Ctrl + C e Ctrl + V para construir novas implementações leva apenas alguns segundos. Mas o tempo é geralmente compensado rapidamente em manutenção, onde a aplicação vai realmente passar a maior parte de seu tempo.
Bom hábito: herança Leverage
Na Listagem 13, o novo
funcionário classe estende a Pessoa de classe. Agora herda todos os métodos comuns e não reimplementar-los. Além disso, a Listagem 13 mostra o uso de um método abstrato para demonstrar como funcionalidade básica pode ser colocado em uma classe base e funcionalidade específica pode ser dissuadida de uma classe de implementação.Listagem 13. Bom hábito de aproveitar a herança
<? Php
Pessoa classe abstrata
{
givenName $ privadas;
familyName $ privadas;
setGivenName função pública ($ gn)
{
$ This-> givenName = $ gn;
}
getGivenName função pública ()
{
return $ this-> givenName;
}
setFamilyName função pública ($ fn)
{
$ This-> familyName = $ fn;
}
getFamilyName função pública ()
{
return $ this-> familyName;
}
public function sayHello ()
{
echo ("Olá, eu sou");
$ This-> introduceSelf ();
}
introduceSelf função abstrata pública ();
}
Funcionário classe estende Pessoa
{
papel $ privadas;
setRole função pública ($ r)
{
$ This-> papel = $ r;
}
getRole função pública ()
{
return $ this-> papel;
}
introduceSelf função pública ()
{
echo ($ this-> getRole () ".." $ this-> getGivenName (). "".
$ This-> getFamilyName ());
}
}
?>
|
Pense nos padrões
Padrões de projeto são interações comuns de objetos e métodos que têm sido comprovada ao longo do tempo para resolver certos problemas. Quando você pensa em padrões de projeto, você está se forçando a estar ciente de como as classes interagem uns com os outros. É uma maneira fácil de construir classes e suas interações, sem ter que cometer os mesmos erros que outras pessoas fizeram no passado e de beneficiar de projetos comprovados.
Nenhum comentário :
Postar um comentário