Orientação a Objetos

1. tá.

2. O olho só vê, então não é responsabilidade dele saber o que o objeto que ela tá vendo é, isso seria responsabilidade de uma area do celebro.

3.Seria.

Muito obrigada pela a sua ajuda :)

Fiz esses modelos de class simples, eu queria saber se estou no caminho certo??

Começou bem.

>

class olho{

 private $cor,$estado;
 public function __construct($cor = null, $estado = null){

Sugestões:

• Não presuma a cor. Obrigue a obtenção da informação
• Assuma um estado inicial reduzindo a complexidade do construtor

class Eye
{

 const BLACK = "#000000";
 const BROWN = "#663300";
 const GREEN = "#00CC00";
 const BLUE = "#0033CC";

 private $color;
 private $closed;

 public function __construct($color)
 {
 $this->color = $color;
 $this->closed = true;
 }

>

if(is_null($cor))

 $this->cor = 'castanho';

 if(is_null($estado))
 $this->estado = 'fechado';
 }

Apesar de as propriedades serem privadas, o fato de não haver validação no construtor dá o mesmo efeito que se elas fossem públicas.

Imagine que você vá estudar genética e desenvolva o método [inline]obterAlelo[/inline]

 public function obterAlelo()
 {
 $pieces = str_split(substr($this->cor, 1), 3);
 return $pieces[intval(mt_rand()) % 2];
 }

$new olho('ZZZZZZZ');vai nos causar problemas mais pra frente.

>

 public function abrirOlho(){
 return $this->estado = 'aberto';
 }
 public function fecharOlho(){
 return $this->estado = 'fechado';
 }

Isso aqui não viola nenhum mantra de boa escrita de orientação a objetos. Mas é desencorajado em outra disciplina: Refatoração

Note que você tem dois métodos muitíssimos similares. A necessidade de modificação em um, em 99% dos casos, vai implicar na necessidade de modificação do outro.

 private function definirEstado($novoEstado)
 {
 return $this->estado = $novoEstado;
 }

No seu exemplo, depois dessa modificação eu ainda questionaria a necessidade de existirem [inline]abrirOlho[/inline] e [inline]fecharOlho[/inline].

Se fosse decidido por mantê-los, pelo menos ficariam mais manuteníveis:

 public function abrirOlho()
 {
 return $this->definirEstado('aberto');
 }

 public function fecharOlho()
 {
 return $this->definirEstado('fechado');
 }

>
Dúvidas:

1) Estou respeitando os princípios do SOLID na class 'olho' e 'boca'??

S: É meio difícil de opinar sobre este assunto com um exemplo tão trivial. Eu sequer sei descrever qual a responsabilidade das classes [inline]Olho[/inline] e [inline]Boca[/inline] neste cenário. Existem apenas métodos de alteração de estado. Não existe processamento. Não há interação entre os objetos. Dessa forma, fica até dífícil violar o princípio de responsabilidade única. Portanto, até agora, sim.

O: Novamente, como não há responsabilidades, não há um cenário onde seja necessário a modificação.

L: Princípio de Substituição de Bárbara Liskov. Esta classe não é herdeira. Não é possível testar este princípio. Assumimos que sim.

I: Não existem interfaces. O que resulta em um Não. O princípio de segregação de interfaces prega que interfaces tenham o menor grau de granularidade possível, sem se proliferarem pelo sistema como interfaces de um método só. Para aplicar este princípio no seu cenário, seria algo assim:

interface Toggleable
{

 public function toggle();
}

class Olho implements Toggleable
{
/ ... métodos, propriedades e etc /

 public function toggle()
 {
 return $this->estado = ($this->estado === 'aberto' ? 'fechado' : 'aberto');
 }
}

class Boca implements Toggleable
{
/ ... /

 public function toggle()
 {
 return $this->estado = ($this->estado === 'fechado' ? 'aberto' : 'fechado');
 }
}

2) Poderia me dá um exemplo de uma (ação/método) onde não cabe a responsabilidade da class 'olho' e 'boca'??

Poderia me dar um exemplo da responsabilidade deles?

3) Eu não criei método 'get' para pegar o atributo 'estado' e 'cor', pois 'get' não seria uma ação do 'olho'. Seria certo eu colocar um get nessa class para pegar os atributos 'estado' e 'cor' do olho??

É necessário que o mundo externo saiba destes estados? Até o momento, não. Se, futuramente, você tiver um enfermeiro(a) que vá pingar um colírio, este enfermeiro precisa saber se o olho está aberto.

class Enfermeiro
{

 public function medicar(Olho $olho)
 {
 if ($olho->obterEstado() !== 'aberto') {
 throw new RuntimeException("Só posso medicar olhos abertos!");
 }
 }
}

Obs.: Não referenciei o método 'set' pois acredito que o abrirOlho(), fecharOlho() e piscaOlho() são métodos do tipo 'set'

O raciocínio está correto. A forma como eles resolvem o problema que está equivocada. Já expliquei o porque lá em cima.

Mas continue assim. Já começou melhor que bastante casos de sucesso que tivemos por aqui (Oi :))

Muito obrigada pela explicação, esclareceu muita coisa :thumbsup:

Logo eu não entendi o que você quis dizer, sobre obrigue a obtenção da informação?? você fez até um exemplo só que não entendi a intenção de já ter as cores já definidas e o atributo closed??

>

Sugestões:

• Não presuma a cor. Obrigue a obtenção da informação


• Assuma um estado inicial reduzindo a complexidade do construtor

class Eye
{

 const BLACK = "#000000";
 const BROWN = "#663300";
 const GREEN = "#00CC00";
 const BLUE = "#0033CC";

 private $color;
 private $closed;

 public function __construct($color)
 {
 $this->color = $color;
 $this->closed = true;
 }

Logo eu não entendi o que você quis dizer, sobre obrigue a obtenção da informação??

Dado que você tenha uma gama de possibilidades (cores de olhos), assumir um valor padrão aumenta a necessidade de uma documentação mais detalhada

Se você não passar o parâmetro cor a um novo olho, será assumida a cor castanha por motivos disso, disso disso e daquilo

Puxa vida. Com tantas cores, porque castanho?

O que é diferente com o estado. É inclusive mais fácil de explicar:

O estado inicial de um novo olho é fechado. Isso porque, como ele ainda não está trabalhando, está descansando :P
você fez até um exemplo só que não entendi a intenção de já ter as cores já definidas

pura frescura. Na minha opinião fica mais verboso:

$myEye = new Eye(Eye::BROWN);

e o atributo closed??

Apenas renomeei [inline]estado[/inline] para [inline]closed[/inline] porque, uma vez que reescrevi a classe toda em inglês, não faz o menor sentido ter todas as informações em inglês e um atributo [inline]estado[/inline] ali no meio.

Isso me faz lembrar uma ressalva que deveria ter feito quanto ao seu código:

class Olho
{
public function abrirOlho()
Se o método já pertence a um olho, porque se chama [inline]abrirOlho[/inline]?

Acho que [inline]$olho->abrir()[/inline] já é - com o perdão do trocadilho - visível o suficiente, não?

Muito obrigada ^_^

Tenha um otimo Final de Semana