ao criar software, é útil entender uma ampla gama de princípios de design. Entender como projetar um sistema com o princípio mais apropriado pode economizar inúmeras horas de desenvolvimento e dor de cabeça.

vamos primeiro falar sobre herança por um pouco. Herança é quando uma classe herda estado e / ou comportamento de uma classe pai. Digamos que estamos projetando um jogo, e eu preciso de um cachorro:

class Dog {
func bark(){
print("Bark")
}
}

depois de um tempo, percebemos que nosso software, como tudo, precisa de gatos, então criamos uma classe de Gatos:

class Cat{
func .meow(){
print("Meow!")
}
}

porque a natureza chama, nós adicionamos .cocô() para o gato e a classe do cão:

class Dog {
func bark(){
print("Bark")
}
func poop(){
print("Poop")
}
}class cat{
func meow(){
print("Meow")
}
func poop(){
print("Poop")
}
}

neste exemplo, temos dois animais que são capazes de fazer cocô. Infelizmente, ambos fornecem implementações para poop() , então há alguma duplicação de código aqui. então nós levantamos .cocô() em uma classe animal compartilhada.

Animal
.poop()Dog
.bark()Cat
.meow()

Agora que temos um monte de animais cocó em todos os lugares, precisamos de um cleaningrobot:

CleaningRobot
.drive()
.clean()

Você também precisa de um MurderRobot que pode .unidade () E.matar() os cães e gatos que são .cocô () em todos os seus pisos brancos:

MurderRobot
.drive()
.kill()

desde então .drive () agora está duplicado entre CleaningRobot e MurderRobot criamos uma classe de robô para colocá-lo.

Robot
.drive()CleaningRobot
.clean()MurderRobot
.kill()

é assim que toda a estrutura se parece:

Robot
.drive()CleaningRobot
.clean()MurderRobot
.kill()Animal
.poop()Dog
.bark()Cat
.meow()

“nossos clientes exigem um MurderRobotDog. Ele precisa ser capaz de .matar(), .unidade(), .bark(), mas não pode fazer cocô ().

e agora, estamos ferrados. Nós simplesmente não podemos encaixar bem o MurderRobotDog nessa hierarquia de herança. Poderíamos criar um novo objeto pai, onde você coloca todas as funcionalidades compartilhadas:

GameObject
.bark()Robot
.drive()CleaningRobot
.clean()MurderRobot
.kill()MurderRobotDogAnimal
.poop()DogCat
.meow()

, Mas isso significa que seus objetos vai ter uma tonelada de funcionalidades que eles não usam, assim você acaba com um Gorila/Banana problema — você solicitar uma banana, mas você acaba com um gorila segurando a banana e a toda a selva com ele.

podemos, No entanto, modelar isso com protocolos no Swift.Como os protocolos podem fornecer uma melhor abstração?

um protocolo no Swift define métodos ou propriedades que uma classe pode adotar. Aqui está um exemplo:

protocol Barker {
func bark()
}
protocol Pooper {
func poop()
}
protocol Driver {
func drive()
}
protocol Cleaner {
func clean()
}
protocol Killer {
func kill()
}

uma vez que as Classes podem adotar vários protocolos. A classe MurderRobotDog adota o protocolo Barker, Killer and driver, o que significa que a classe MurderRobotDog fornece implementações para bark(), kill(), and clean().

class MurderRobotDog: Barker,Killer, Driver{
func bark() {
print("Bark!")
}
func driver() {
print("Drive!")
}
func killer() {
print("Kill!")
}}

Como de Swift 2.0, agora podemos remover a duplicação de código, fornecendo uma implementação padrão usando uma extensão do protocolo de:

protocol Barker {
func bark()
}
extension Barker {
func bark() {
print("Bark!")
}
}class Dog: Barker{}
let myDog = Dog()
myDog.bark() // prints "Bark!"

Então, nós olhamos um exemplo de uma árvore de herança que quebrou e, em seguida, observamos como reestruturá-la usando o protocolo(interface).

a questão que provavelmente está em sua mente agora é-quando usar cada um? Bem … a grande maioria dos desenvolvedores concorda que devemos favorecer a Interface em vez da herança. Muitas pessoas vão lhe dizer que se algo tem um relacionamento “é um”, então você deve usar herança. Por exemplo, Mattias “é um” homem, assim eu posso herdar o homem. Se o relacionamento é de natureza” tem”, como um carro “tem um” motor, então você deve usar a composição.

conclusão

ao projetar um sistema, é importante escolher o princípio de design certo para o seu modelo. Em muitas circunstâncias, é melhor usar a interface em primeiro lugar. É mais flexível, poderoso e também é muito fácil de fazer.

Deixe uma resposta

O seu endereço de email não será publicado.