(Re)pensando a OOP - TDC 2012

(Re)Pensando a
Orientação a Objetos
Luís Otávio Cobucci Oblonczyk

25 de Agosto de 2012

Luís Otávio Cobucci Oblonczyk
●
Evangelista (doido por) PHP
●
Desenvolvedor na Softnex Tecnologia (SC)
●
Membro do PHPSC
●
ZCE PHP 5.3
●
Perfeccionista ao extremo =P

@lcobucci
http://about.me/lcobucci

Orientação a Objetos muda nossa vida?

O que é OOP?
“Orientação a objetos é um paradigma de
análise, projeto e programação de sistemas de
software baseado na composição e interação
entre diversas unidades de software chamadas de
objetos.”

http://pt.wikipedia.org/wiki/Orienta%C3%A7%C3%A3o_a_objetos

O que é OOP?
●
Paradigma = Padrão a ser seguido; Pressuposto
filosófico
●
Busca tornar o mundo das linguagens que os
computadores entendem mais próximo da
realidade

A mudança principal é como pensamos!

História da OOP
●
Os termos “objetos” e “instâncias” foram
utilizados por volta da década de 60
●
O conceito formal foi introduzido (também nos
anos 60) na linguagem de programação Simula
67
●
Na década de 70 foi lançada, na Xerox PARC, a
linguagem Smalltalk, que teve influências de
conceitos da Simula 67

Linguagens e OOP
●
Funcionalidades OOP adicionadas como
extensão

●
Principalmente OOP

●
Puramente OOP

Porque repensar a OOP?

Não, eu não sou pago por
colocar tirinhas do vida de
programador nas minhas
palestas.

Bem que podia né? =P

Pontos negativos da OOP
●
Aprendizado mais complexo (deve-se aprender
o conceito e a sintaxe para cada linguagem)
●
Maior utilização de recursos do servidor
(quando comparado à outros paradigmas que o
PHP suporta)

Pontos positivos da OOP
●
Reutilização de código
●
Extensibilidade
●
Código facilmente testável (depende do
desenvolvedor, claro =P)
●
Desenvolvimento mais próximo do negócio

Objeto
●
Representação computacional de algo concreto
e existente no mundo real
●
Possui características (atributos) e
comportamentos (métodos)

Classe
●
Descrição detalhada de um objeto e suas
relações
●
Segue as regras sintáticas da linguagem de
programação para definir os atributos e
comportamentos

<?php
namespace LcobucciExamples;

class Person
{
private $name;

public function talk($message)
{
echo $message;
}
}

Instância
●
Concretização da existência de um objeto;
criação do objeto, seguindo as regras definidas
na classe (previamente construída)

<?php

class Person
{
private $name;

{
echo $message;
}
}

$luis = new Person();

Visibilidade
●
Existem coisas que nem todos precisam
saber/ver...
●
Define a acessibilidade dos dados (métodos,
atributos) do objeto
●
Tipos:
●
public
●
protected
●
private

Herança
●
Aproveitamento de métodos e atributos entre
objetos de um mesmo contexto

<?php

class Person
{
private $name;

{
echo $message;
}
}

class Programmer extends Person
{
}

Herança
●
Permite a alteração do comportamento dos
métodos, caso necessário

<?php
class Person
{
private $name;
{
echo $message;
}
}

{
{
parent::talk(md5($message));
}
}

Abstração
●
Definição “parcial” dos comportamentos dos
objetos
●
É definido que o comportamento existe, mas
não é implementado, ou seja não tem
necessidade da classe pai saber como o objeto
age naquela ação

Abstração
●
Podem ser definidas classes abstratas,
métodos abstratos e interfaces
●
Classes abstratas não PODEM nunca ser
instanciadas diretamente, é necessária uma
classe filha
●
Métodos abstratos são aqueles que devem ser
implementados nas classes filhas

<?php
abstract class Person
{
private $name;
public abstract function talk($message);
}

class Professor extends Person
{
{
echo $message;
}
}

{
{
echo md5($message);
}
}

Abstração
●
Interfaces são estruturas que possuem apenas
a definição dos comportamentos dos objetos
●
Todos os comportamentos definidos em uma
interface são SEMPRE acessíveis publicamente
●
São utilizadas quando o contexto dos objetos
são diferentes, porém compartilham
comportamentos

<?php
interface Flyer
{
public function fly();
}

class Bird implements Flyer
{
public function fly()
{
}
}

class Airplane implements Flyer
{
public function fly()
{
}
}

Polimorfismo
●
A palavra polimorfismo tem origem grega,
significa “muitas formas”
●
Dentro da OOP, é a capacidade de um método
agir de formas diferentes
●
É possibilitado pela existência da abstração
(herança ou implementação de interface), onde
as classes implementam um mesmo método
abstrato de formas diferentes

<?php
interface PaymentMethod
{
public function pay($ammount);
}

class CreditCard implements PaymentMethod
{
public function pay($ammount)
{
}
}

class Money implements PaymentMethod
{
public function pay($ammount)
{
}
}

<?php

class Item
{
private $price;

public function sell(
$quantity,
PaymentMethod $paymentMethod
) {
$paymentMethod->pay(
$this->price * $quantity
);
}
}

Construtor e Destrutor
●
Métodos que inicializam e destroem o estado
do objeto

<?php

class PersonList
{
private $list;

public function __construct()
{
$this->list = array();
}

public function __destruct()
{
$this->list = null;
}
}

Design Patterns
Design patterns são soluções para necessidades
específicas e devem ser utilizados quando
necessário. Exemplos:

●
Adapter ●
Strategy
●
Façade ●
Decorator
●
Factory ●
Singleton
●
Proxy

Design Patterns
Design patterns são soluções para necessidades
específicas e devem ser utilizados quando
necessário. Exemplos:

●
Adapter ●
Strategy
●
Façade ●
Decorator
●
Factory ●
Singleton (você não vai precisar)
●
Proxy

Prepare-se, cenas fortes!

Problemas comuns...

Idioma do código
●
Mistura de idiomas dentro do código fonte
●
Tradução dos nomes de forma equivocada
(esquece-se que, principalmente, os métodos
são ordens)

<?php

class Pessoa
{
private $name;
}

<?php

$luis = new Pessoa();
$rex = new Cachorro();
$graveto = new Galho();

$luis->jogar($graveto);
$rex->pegar($graveto);

Isso não soa estranho??

Herança sem sentido
●
Herança não é apenas compartilhamento de
comportamentos!
●
O contexto das classes filhas não podem ser
diferentes da classe pai

<?php

class Passaro
{
public function voa()
{
}
}

class Aviao extends Passaro
{
}
Avião também voa, mas não
é um pássaro!!!

Causa raiz
●
O maior problema do desenvolvimento por si
só é a falta de planejamento, na orientação a
objetos essa falta pode causar problemas muito
sérios, tornando a manutenção do software
extramente exaustiva e trabalhosa.

Implementação e comparação...

Transferência entre contas
bancárias
●
O saldo da conta da Sílvia possui R$ 200,00
●
O saldo da conta da Maria possui R$ 30,00
●
Maria está com dificuldades financeiras, e pede
à Sílvia um empréstimo de R$ 100,00

<?php
$saldoContaSilvia = 200;
$saldoContaMaria = 30;

$saldoContaSilvia -= 100;
$saldoContaMaria += 100;

<?php

class ContaBancaria
{
public $saldo;

public function __construct($saldo)
{
$this->saldo = $saldo;
}

public function transfere(
ContaBancaria $destino,
$valor
) {
$this->saldo -= $valor;
$destino->saldo += $valor;
}
}

<?php

$contaSilvia = new ContaBancaria(200);
$contaMaria = new ContaBancaria(30);

$contaSilvia->transfere($contaMaria, 100);

Mais informações? Onde??
●
Head first Object-Oriented Analysis & Desing
http://www.headfirstlabs.com/books/hfooad/
●
Programando com Orientação a Objetos
http://www.adianti.com.br/phpoo
●
Domain Driven Design
http://domaindrivendesign.org/books/evans_2003
●
Clean Code: A Handbook of Agile Software
Craftsmanship
http://goo.gl/Qyhmq

Obrigado!

Eu por aí: http://about.me/lcobucci
Slides: http://slideshare.net/lcobucci

(Re)pensando a OOP - TDC 2012

Mais conteúdo relacionado

Mais procurados

Semelhante a (Re)pensando a OOP - TDC 2012

(Re)pensando a OOP - TDC 2012