DEOR NODEJS - WILLIAM BRUNO

Bem Vindo ao meu blog. Me chamo William Bruno (aka wbruno) e trabalho como
Desenvolvedor NodeJs

Vou partir do princípio de que se você chegou até aqui, já tem algum conhecimento em
Orientação a Objetos, já esboçou as tuas primeiras classes, e já tem alguma experiência na
criação de sistemas.

Interfaces são contratos.

Na minha ótica, o paradigma dos objetos, foi criado para resolver basicamente duas coisas:
Padronização e Encapsulamento. Os outros problemas que OO também resolve, já possuiam
soluções anteriores. [reutilização, organização…]

As interfaces existem por isso, para ajudar a defender o primeiro pilar.

Estou falando ‘por cima’, para simplificar e me focar no conceito que quero expor.

Imaginemos que nosso sistema faz um CRUD, e possui um módulo de Agenda, razoável,
termos um model que seja parecido com isso:

<?php

class Agenda
{
public function insere_agenda(){
//implementação
}
public function atualiza_agenda(){
//implementação
}
public function excluir_agenda(){
//implementação
}
}
Bacana.. Recebemos então uma solicitação que nos pede para criarmos outro ‘módulo’, para
galerias de fotos. Novamente, vamos lá e fazemos:

<?php

class Galeria
{
public function insere_galeria(){
//implementação
}
 //...
}
bem parecidos, porém diferentes nas implementações.
Nosso ‘controlador’, que usará os objetos instanciados apartir de Galeria, ou Agenda, sabe que
precisa usar:

$galeria = new Galeria();

$galeria->insere_galeria();
ou

$agenda = new Agenda();

$agenda->insere_agenda();
Mas e se um outro programador, for dar continuidade nesse trabalho, é complicado ele ter a
paciência de estudar todas as nossas classes, identificar o ‘padrão’ que usamos, e então
implementar agora o módulo de ‘Notícias’… esse ‘outro programador’, pode até ser nós
mesmos, daqui um tempo.

Evoluímos a cada ‘passagem de tempo’, impossível termos de cabeça todos os códigos, de

todos os nossos projetos. Pode ser que não nos lembremos o que fizemos ‘lá atrás’.

Documentar é importante, mas um código bem escrito é ainda mais.

Assim que esse ‘novo programador’, for implementar o módulo de Notícias, ele terá que se
perguntar: ‘E agora, oque preciso fazer?’.

Aqui é onde mora o perigo. Ele pode detonar ‘o nosso padrão'(que já estava errado), e fazer
algo completamente bizzarro:

<?php
class Noticia
{
public function cadastra(){}
public function Muda(){}
public function manda_pRo_liXo(){}
}
e ai ? a culpa não é só dele.
O nosso sistema por si só, não ‘deixava claro’, como as coisas deveriam ser, ou seja, não
implementamos direito um dos pilares do OO.

É aqui que entram as interfaces. A forma de pensar tem que mudar.

Afinal, Galeria::insere_galeria();, Agenda::insere_agenda(), e Noticia::cadastra();, não são
‘semelhantes entre si’ ?

Queremos que os próximos a programarem no nosso sistema, saibam o que devem fazer, e
‘como devem fazer’. Podemos então, obrigar que os próximos depois da gente, sejam mais
consistentes.

interface iModel
{
public function insert();
public function update();
public function delete();
}
A nomenclatura já está bem melhor também.
Pessoalmente, não vejo sentido no insere_blablabla(); mas coloquei ali, pq vejo muito disso por
ai.

Então, daqui para frente, nossas classes precisam apenas implementar essa interface.
Isso mesmo implementar. A interface define apenas a assinatura dos nossos métodos. A
implementação fica a cargo de cada classe em específico.

Aqui então, vemos surgir o conceito de ‘poliformismo’. Coisas iguais com comportamentos
diferentes, ou coisas diferentes com comportamentos iguais.
Mas como isso é pano para manga, voltemos as nossas interfaces, que não são nada mais do
que: ‘coisas’ que vemos, que nos permitem trabalhar com elas. A beleza da programação, está
em não precisarmos saber como os métodos foram/serão implementados, porém podemos
usá-los, acreditando que eles cumpram o papel para o qual foram designados.

Não raramente fazemos isso. Posso dizer que toda vez que você usa uma função nativa da
linguagem, vc está acreditando que ela faz o que vc precisa, sem saber exatamente como ela
faz.

Nossas classes agora são assim:

class Agenda implements iModel

{

}
class Galeria implements iModel
{

}
Todas irão implementar a nossa interface, e por isso, precisam obrigatoriamente fazer isso
corretamente, se não, alguns erros serão lançados:
Fatal error: Class Agenda contains 3 abstract methods and must therefore be declared abstract
or implement the remaining methods (iModel::insert, iModel::update, iModel::delete) in C:\
Program Files\Apache Software Foundation\Apache2.2\htdocs\index.php on line 17
Somos obrigados a:
 class Agenda implements iModel
{
public function insert(){
//implementação
}
public function update(){
//implementação
}
public function delete(){
//implementação
}
}
E o mesmo para todas as classes que implementarem essa interface.
O nosso ‘novo programador’, que vai criar lá, o módulo de Notícias, agora, apenas precisa ler a
iModel, e implementar a class Noticia, com base nessa interface.

Se nosso chefe chegar agora, pedir um módulo de ‘Artigos’, então sabemos por onde começar,
e temos algo para nos basear. Tá lindo até aqui, mas não para por ai.

É ainda mais poderoso que isso. O php apesar de ser ‘de tipagem fraca’, nos dá um suporte
muito importante a typehinting. Nossas models, usarão um banco de dados(ou não), mas não
são, ‘o banco’ em si.

Por isso que não faz sentido, que nossas models, herdem coisas de uma class Db.
Se é para usar, vamos usar:

interface iModel
{
public function insert( iDb $db );
public function update( iDb $db );
public function delete( iDb $db );
}
Agora, outro erro foi disparado:

Fatal error: Declaration of Agenda::insert() must be compatible with that of iModel::insert() in C:\
Program Files\Apache Software Foundation\Apache2.2\htdocs\index.php on line 14
Basta adequarmos nossas classes, a essa nova realidade.

public function insert( iDb $db ){}

Okay, mas e oque isso quer dizer?
Que os nossos métodos: esperam receber um objeto ‘iDb’. E quem é esse iDb ?

[conheço pdo, tente por favor extrair o conceito, e não apenas a implementação que estou
expondo].
 interface iDb
{
public function query();
}
class MySql implements iDb
{
public function query();
}
class PostGre implements iDb()
{
public function query();
}
Usamos para o banco MySQL dessa forma:

$db = new MySql();

$galeria = new Galeria();

$galeria->insert( $db );
Como também poderíamos usar com a nossa class para o banco de dados Postgre:

$db = new PostGre();

Ou seja, ganhamos uma flexibilidade aqui.
Ambos, tanto postgre, quanto mysql, possuem em comum a interface iDb. Por isso, que os
métodos da class Galeria, que esperam receber um objeto iDb, aceita tanto instancias de
PostGre, quanto de MySql.

Mas não podemos, fazer:

class Storage
{
public function query(){}
}
$db = new Storage();
$galeria = new Galeria();
$galeria->insert( $db );//mandando um objeto Storage, que não implementa iDb
Será lançado um erro. Afinal, o método iModel::insert() espera receber um iDb, e não foi isso
que mandamos para ele.

Nossas classes especificas, assinaram os contratos com as interfaces.

Na prática, temos a garantia de que podemos usar os métodos insert(), update() e delete, com
exatamente esses nomes, e passando um objeto iDb, que sabemos que podemos usar o
método query();
 public function insert( iDb $db )
{
$sql = "INSERT INTO ...";
return $db->query( $sql );
}
Essa consistência é importante. Não importa se é MySQL, Postgre, SQL Server.. todos
implementando iDb, temos a garantia de que o método query() existe, e pode ser usado.

Quando usar Abstract, e quando usar interface, é uma outra discussão.

Coloquei a forma com que vejo, com base em tudo o que já estudei, pesquisei e li. É isso,
comentem a vontade, por favor. Me ajudará a saber sobre oque devo escrever.

aqui e realmente entendo que o texto esta simples porém de extrema qualidade. parabéns

REPLY

Samuel Gomes Huarachi

JULHO 5, 2012 AT 09:28
Muito bom o artigo. Assim podemos ter ideia de como usar esses recursos em nossos
programas

REPLY

Rafa
SETEMBRO 27, 2012 AT 02:14
Uma pergunta, quando começo um projeto em PHP e coloco minha classes em uma pasta
separada, onde coloco as minhas interface? devo criar uma pasta apenas para as interface e
fazer um include em cada classe que eu utilizar? isso não é um problema?

REPLY

wbruno (Post author)

SETEMBRO 27, 2012 AT 11:03
Eu não separo. Eu coloco todas as classes, interfaces e classes abstratas na mesma pasta.
Para o POO, pouco importa a organização de pastas.

REPLY

Rafa
SETEMBRO 27, 2012 AT 17:25
Ok posso colocar junto mas isso não atrapalha? tenho dezenas de classes e geralmente coloco
nomeDaCasse.class.php e da interface posso usar nomeDaInterface.interface.php ? ou tem
uma dica melhor?
tenho problema com os includes, sempre que faço include relativo na minhas classes da um
erro na hora de usar cron, como você faz para sempre fazer os includes certinho? alguma
manha? o autoload sempre me da dor de cabeça.

PS: nao uso mvc

REPLY

Renan
JANEIRO 2, 2013 AT 17:04
Ótimo artigo, simples, objetivo e com exemplos intuitivos!! Parabéns cara, continue escrevendo
e que Deus te abençoe!!!

REPLY

Marcos
ABRIL 7, 2013 AT 18:35
Parabéns ótimo artigo.

REPLY

Hamilcar
SETEMBRO 7, 2013 AT 15:20
Parabéns pelo artigo, claro e conciso, mas tenho a mesma dúvida do Rafa, com relação a
organização de pastas…

REPLY

Giovane
NOVEMBRO 10, 2013 AT 14:39
Ótimo artigo rapaz!

Comecei hoje a aprender PHP Orientado a Objetos. Tenho noção de PHP estruturado e
Orientação a Objetos em Java, porém PHPOO é simplesmente perfeito heuaheua

Essas interfaces realmente ajudam a não perder o padrão na programação. Gostei 😉

Valeu!

REPLY

Julio
DEZEMBRO 4, 2013 AT 15:45
Cara primeiramente parabéns o artigo ficou muito bom, mas tenho uma duvida, segue:

public function insert( iDb $db )

{
$sql = “INSERT INTO …”;
return $db->query( $sql );
}

Entendi que neste metodo ele irá usar o metodo query do objeto $db e executar o conteduo
$sql , porem terei que receber valores a serem inseridos na tabela como por exemplo (nome,
endereco e etc) para completar o insert into, neste caso como devo fazer?? Se o metodo insert
só aceita um objeto do tipo $db como parametro??

Att.

REPLY

Angélica
MARÇO 21, 2015 AT 11:00
Poxa,ficou excelente!
Ainda estou nos princípios da POO e preciso aprimorar meus conceitos teóricos e você me
esclareceu muito!Texto ótimo e código muito claro 😀

REPLY

Uhelliton Andrade
ABRIL 30, 2015 AT 17:33
Obrigado Bruno pela rica contribuição…

REPLY
Deixe uma resposta

Your email address will not be published.

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym
title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s>
<strike> <strong>
© 2015 DESENVOLVEDOR NODEJS – WILLIAM BRUNO — UP ↑DESENVOLVEDOR
NODEJS - WILLIAM BRUNO

Bem Vindo ao meu blog. Me chamo William Bruno (aka wbruno) e trabalho como
Desenvolvedor NodeJS nos horários em que não estou estudando Matemática ou escrevendo
posts.
SHOW MENU
Afinal o que é Interface ? [oop]

ABRIL 20, 2011 / 20 COMMENTS

Vou partir do princípio de que se você chegou até aqui, já tem algum conhecimento em
Orientação a Objetos, já esboçou as tuas primeiras classes, e já tem alguma experiência na
criação de sistemas.

Interfaces são contratos.

Na minha ótica, o paradigma dos objetos, foi criado para resolver basicamente duas coisas:
Padronização e Encapsulamento. Os outros problemas que OO também resolve, já possuiam
soluções anteriores. [reutilização, organização…]

As interfaces existem por isso, para ajudar a defender o primeiro pilar.

Estou falando ‘por cima’, para simplificar e me focar no conceito que quero expor.

Imaginemos que nosso sistema faz um CRUD, e possui um módulo de Agenda, razoável,
termos um model que seja parecido com isso:

<?php

class Agenda
{
public function insere_agenda(){
//implementação
}
public function atualiza_agenda(){
//implementação
}
public function excluir_agenda(){
//implementação
}
}
Bacana.. Recebemos então uma solicitação que nos pede para criarmos outro ‘módulo’, para
galerias de fotos. Novamente, vamos lá e fazemos:

<?php
class Galeria
{
public function insere_galeria(){
//implementação
}
//...
}
bem parecidos, porém diferentes nas implementações.
Nosso ‘controlador’, que usará os objetos instanciados apartir de Galeria, ou Agenda, sabe que
precisa usar:

$galeria = new Galeria();

$galeria->insere_galeria();
ou

$agenda = new Agenda();

$agenda->insere_agenda();
Mas e se um outro programador, for dar continuidade nesse trabalho, é complicado ele ter a
paciência deestudar todas as nossas classes, identificar o ‘padrão’ que usamos, e então
implementar agora o módulo de ‘Notícias’… esse ‘outro programador’, pode até ser nós
mesmos, daqui um tempo.

Evoluimos a cada ‘passagem de tempo’, impossível termos de cabeça todos os códigos, de

todos os nossos projetos. Pode ser que não nos lembremos o que fizemos ‘lá atrás’.

Documentar é importante, mas um código bem escrito é ainda mais.

Assim que esse ‘novo programador’, for implementar o módulo de Notícias, ele terá que se
perguntar: ‘E agora, oque preciso fazer?’.

Aqui é onde mora o perigo. Ele pode detonar ‘o nosso padrão'(que já estava errado), e fazer
algo completamente bizzarro:

<?php
class Noticia
{
public function cadastra(){}
public function Muda(){}
public function manda_pRo_liXo(){}
}
e ai ? a culpa não é só dele.
O nosso sistema por si só, não ‘deixava claro’, como as coisas deveriam ser, ou seja, não
implementamos direito um dos pilares do OO.
É aqui que entram as interfaces. A forma de pensar tem que mudar.
Afinal, Galeria::insere_galeria();, Agenda::insere_agenda(), e Noticia::cadastra();, não são
‘semelhantes entre si’ ?

Queremos que os próximos a programarem no nosso sistema, saibam o que devem fazer, e
‘como devem fazer’. Podemos então, obrigar que os próximos depois da gente, sejam mais
consistentes.

interface iModel
{
public function insert();
public function update();
public function delete();
}
A nomenclatura já está bem melhor também.
Pessoalmente, não vejo sentido no insere_blablabla(); mas coloquei ali, pq vejo muito disso por
ai.

Então, daqui para frente, nossas classes precisam apenas implementar essa interface.
Isso mesmo implementar. A interface define apenas a assinatura dos nossos métodos. A
implementação fica a cargo de cada classe em específico.

Aqui então, vemos surgir o conceito de ‘poliformismo’. Coisas iguais com comportamentos
diferentes, ou coisas diferentes com comportamentos iguais.
Mas como isso é pano para manga, voltemos as nossas interfaces, que não são nada mais do
que: ‘coisas’ que vemos, que nos permitem trabalhar com elas. A beleza da programação, está
em não precisarmos saber como os métodos foram/serão implementados, porém podemos
usá-los, acreditando que eles cumpram o papel para o qual foram designados.

Não raramente fazemos isso. Posso dizer que toda vez que você usa uma função nativa da
linguagem, vc está acreditando que ela faz oque vc precisa, sem saber exatamente como ela
faz.

Nossas classes agora são assim:

class Agenda implements iModel

{

}
class Galeria implements iModel
{

}
Todas irão implementar a nossa interface, e por isso, precisam obrigatoriamente fazer isso
corretamente, se não, alguns erros serão lançados:
Fatal error: Class Agenda contains 3 abstract methods and must therefore be declared abstract
or implement the remaining methods (iModel::insert, iModel::update, iModel::delete) in C:\
Program Files\Apache Software Foundation\Apache2.2\htdocs\index.php on line 17
Somos obrigados a:

class Agenda implements iModel

{
public function insert(){
//implementação
}
public function update(){
//implementação
}
public function delete(){
//implementação
}
}
E o mesmo para todas as classes que implementarem essa interface.
O nosso ‘novo programador’, que vai criar lá, o módulo de Notícias, agora, apenas precisa ler a
iModel, e implementar a class Noticia, com base nessa interface.

Se nosso chefe chegar agora, pedir um módulo de ‘Artigos’, então sabemos por onde começar,
e temos algo para nos basear. Tá lindo até aqui, mas não para por ai.

É ainda mais poderoso que isso. O php apesar de ser ‘de tipagem fraca’, nos dá um suporte
muito importante a typehinting. Nossas models, usarão um banco de dados(ou não), mas não
são, ‘o banco’ em si.

Por isso que não faz sentido, que nossas models, herdem coisas de uma class Db.
Se é para usar, vamos usar:

interface iModel
{
public function insert( iDb $db );
public function update( iDb $db );
public function delete( iDb $db );
}
Agora, outro erro foi disparado:

Fatal error: Declaration of Agenda::insert() must be compatible with that of iModel::insert() in C:\
Program Files\Apache Software Foundation\Apache2.2\htdocs\index.php on line 14
Basta adequarmos nossas classes, a essa nova realidade.
public function insert( iDb $db ){}
Okay, mas e oque isso quer dizer?
Que os nossos métodos: esperam receber um objeto ‘iDb’. E quem é esse iDb ?

[conheço pdo, tente por favor extrair o conceito, e não apenas a implementação que estou
expondo].

interface iDb
{
public function query();
}
class MySql implements iDb
{
public function query();
}
class PostGre implements iDb()
{
public function query();
}
Usamos para o banco MySQL dessa forma:

$db = new MySql();

$galeria = new Galeria();

$galeria->insert( $db );
Como também poderiamos usar com a nossa class para o banco de dados Postgre:

$db = new PostGre();

Ou seja, ganhamos uma flexibilidade aqui.
Ambos, tanto postgre, qnto mysql, possuem em comum a interface iDb. Por isso, que os
métodos da class Galeria, que esperam receber um objeto iDb, aceita tanto instancias de
PostGre, qnto de MySql.

Mas não podemos, fazer:

class Storage
{
public function query(){}
}
$db = new Storage();
$galeria = new Galeria();
$galeria->insert( $db );//mandando um objeto Storage, que não implementa iDb
Será lançado um erro. Afinal, o método iModel::insert() espera receber um iDb, e não foi isso
que mandamos para ele.
Nossas classes especificas, assinaram os contratos com as interfaces.
Na prática, temos a garantia de que podemos usar os métodos insert(), update() e delete, com
exatamente esses nomes, e passando um objeto iDb, que sabemos que podemos usar o
método query();

public function insert( iDb $db )

{
$sql = "INSERT INTO ...";
return $db->query( $sql );
}
Essa consistência é importante. Não importa se é MySQL, Postgre, SQL Server.. todos
implementando iDb, temos a garantia de que o método query() existe, e pode ser usado.

Quando usar Abstract, e quando usar interface, é uma outra discussão.

Coloquei a forma com que vejo, com base em tudo o que já estudei, pesquisei e li. É isso,
comentem a vontade, por favor. Me ajudará a saber sobre oque devo escrever.

Dissertar por aqui, é uma rica fonte de aprendizado para mim também. Bons estudos a todos
nós.
Categories: PHP Tags: oo
« Problemas com acentuação no AJAX, como resolver Entendendo erros do validador CSS do
w3c »
20 Comments

Andrey Knupp
ABRIL 20, 2011 AT 07:50
Opá, Caramba cara esse Artigo Ficou Bem Legal
Você não so explicou as Interfaces como explicou
o recebimento de um Objeto em seu metodo assim da pra ter uma ideia mais clara de ambas
as coisas Não so das interfaces como a Importancia de implementar uma interface obrigando a
classe seguir um padrão em seus metodos !

Achei Bem Legal !!!!, Abraços

REPLY

Ibrahim
ABRIL 20, 2011 AT 16:16
Ó o brunovisk mandando ver nos artigos. Acho importante sim que você explique o porque de
usar uma interface. Ajuda aqueles que querem fazer algo direito a entenderem a fundo como e
porque fazer.
Parabéns pelo artigo.
REPLY

Renato
JUNHO 3, 2011 AT 18:41
meu cérebro fritou rsrs vou ter que ler umas 5 vezes

parabéns 😀

REPLY

wbruno (Post author)

JUNHO 3, 2011 AT 19:49
Bacana Renato!

dá uma olhada, o texto está todo muito simples.

Se restar alguma dúvida, não hesite em em perguntar.

REPLY

Cristiano
JULHO 12, 2011 AT 19:09
Caraca, do mal esse seu artigo. Curti pra caramba, está tudo muito claro pra mim agora,
entendi muitos padroes de códigos que eu utilizo no trabalho e nem sabia pra que serviam
exatamente. Obrigado parabens 😀

REPLY

Roni
NOVEMBRO 19, 2011 AT 10:48
Wbruno, parabéns! Já estudei livros de OOP e não havia visto uma descrição de interface tão
clara e com exemplos simples, muito bom !

REPLY

Dalton
JANEIRO 18, 2012 AT 01:44
Parabéns, um artigo de ótima qualidade, simples em sua linguagem e de fácil entendimento.

É difícil ver essa qualidade em artigos POO aqui no Brasil. Continue escrevendo.

Abraços.

REPLY
Lucas
ABRIL 12, 2012 AT 19:13
Agora sim ficou claro o que é interfaces.
Meus parabéns pelo post!

REPLY

Renato
JUNHO 27, 2012 AT 23:17
Um ano depois volto aqui e realmente entendo que o texto esta simples porém de extrema
qualidade. parabéns

REPLY

Samuel Gomes Huarachi

JULHO 5, 2012 AT 09:28
Muito bom o artigo. Assim podemos ter ideia de como usar esses recursos em nossos
programas

REPLY

Rafa
SETEMBRO 27, 2012 AT 02:14
Uma pergunta, quando começo um projeto em PHP e coloco minha classes em uma pasta
separada, onde coloco as minhas interface? devo criar uma pasta apenas para as interface e
fazer um include em cada classe que eu utilizar? isso não é um problema?

REPLY

wbruno (Post author)

SETEMBRO 27, 2012 AT 11:03
Eu não separo. Eu coloco todas as classes, interfaces e classes abstratas na mesma pasta.
Para o POO, pouco importa a organização de pastas.

REPLY

Rafa
SETEMBRO 27, 2012 AT 17:25
Ok posso colocar junto mas isso não atrapalha? tenho dezenas de classes e geralmente coloco
nomeDaCasse.class.php e da interface posso usar nomeDaInterface.interface.php ? ou tem
uma dica melhor?

tenho problema com os includes, sempre que faço include relativo na minhas classes da um
erro na hora de usar cron, como você faz para sempre fazer os includes certinho? alguma
manha? o autoload sempre me da dor de cabeça.

PS: nao uso mvc

REPLY

Renan
JANEIRO 2, 2013 AT 17:04
Ótimo artigo, simples, objetivo e com exemplos intuitivos!! Parabéns cara, continue escrevendo
e que Deus te abençoe!!!

REPLY

Marcos
ABRIL 7, 2013 AT 18:35
Parabéns ótimo artigo.

REPLY

Hamilcar
SETEMBRO 7, 2013 AT 15:20
Parabéns pelo artigo, claro e conciso, mas tenho a mesma dúvida do Rafa, com relação a
organização de pastas…

REPLY

Giovane
NOVEMBRO 10, 2013 AT 14:39
Ótimo artigo rapaz!

Comecei hoje a aprender PHP Orientado a Objetos. Tenho noção de PHP estruturado e
Orientação a Objetos em Java, porém PHPOO é simplesmente perfeito heuaheua

Essas interfaces realmente ajudam a não perder o padrão na programação. Gostei 😉

Valeu!

REPLY

Julio
DEZEMBRO 4, 2013 AT 15:45
Cara primeiramente parabéns o artigo ficou muito bom, mas tenho uma duvida, segue:
public function insert( iDb $db )
{
$sql = “INSERT INTO …”;
return $db->query( $sql );
}

Entendi que neste metodo ele irá usar o metodo query do objeto $db e executar o conteduo
$sql , porem terei que receber valores a serem inseridos na tabela como por exemplo (nome,
endereco e etc) para completar o insert into, neste caso como devo fazer?? Se o metodo insert
só aceita um objeto do tipo $db como parametro??

Att.

REPLY

Angélica
MARÇO 21, 2015 AT 11:00
Poxa,ficou excelente!
Ainda estou nos princípios da POO e preciso aprimorar meus conceitos teóricos e você me
esclareceu muito!Texto ótimo e código muito claro 😀

REPLY

Uhelliton Andrade
ABRIL 30, 2015 AT 17:33
Obrigado Bruno pela rica contribuição…

REPLY
Deixe uma resposta

Your email address will not be published.

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym
title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s>
<strike> <strong>

© 2015 DESENVOLVEDOR NODEJS – WILLIAM BRUNO — UP ↑