Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Pessoal,
Eu programo desde meus 8~9 anos com PHP estruturado, no entanto eu sempre leio artigos sobre os dois modos de programação, do OO e do estruturado.
Dizem que estruturado é para pequenas aplicações. E isso é mito. Pois eu já realizei a construção de grandes sistemas e aplicações somente com estruturado. Eu já estudei muitos códigos em OO, e tudo que é feito é em OO pode ser feito em estruturado!
No entanto, vejo centenas de artigos que mais critícam estruturado que os comparam. Fica algo como se fosse para leigos, é fato que você exibir um conteúdo qualquer com estruturado é mais fácil que OO, no entanto, contruir um sistema completo, e até complexo, é a mesma dificuldade de lógica, teoria, conhecimento e tempo!
Eu programo somente estruturado, aliás eu construo sistemas versáteis, razoavelmente rápidos, flexiveís e complexos, mas como eu estudo OO, eu também aplico OO em alguns códigos, funções, etc. Ou seja, de certa forma, aplico ambos modelos de programação em meus projetos, mas faço mais em estruturado.
É fato que nos dias atuais normalmente para projetos e empresas de desenvolvimento, eles solicitam conhecimento em OO.
Mas minha critíca quanto ao assunto é esta. Gostaria das suas colegas /applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/happy.gif&key=d39e68bd94edabd9069b8f4a6d941163110d4d36d12e6324ad75ec83de4843df" alt="happy.gif" />
Dizem que estruturado é para pequenas aplicações. E isso é mito. Pois eu já realizei a construção de grandes sistemas e aplicações somente com estruturado. Eu já estudei muitos códigos em OO, e tudo que é feito é em OO pode ser feito em estruturado!
Na verdade cara, OO e estruturado não tem muitas diferenças não...
Orientação à Objetos é mais uma teoria, vários conceitos, ou seja, OO é na verdade o uso de classes heranças, polimorfismos e etc, já a estruturação não utiliza classes nem nada, é apenas a linguagem corrida, C é uma linguagem estruturada, Portugol é estruturado, já por exemplo, C#, VB, Java utilizam o sentido de orientação a objetos, porém são também linguagens estruturadas, não há grandes diferenças entre criar um sistema estruturado totalmente (sem usar classes nem nada) ou OO (com classes) o ideal seria mesmo misturar os dois, mas tenha em mente que são dois conceitos que não são muito diferentes.
Orientação a objetos é então estruturado de certa forma, todo php é estruturado, todas as linguagens são estruturadas.
no entanto, construir um sistema completo, e até complexo, é a mesma dificuldade de lógica, teoria, conhecimento e tempo!
Cara, isto está muito errado... Um sistema de calculadora por exemplo não exige nem a mesma lógica, teoria nem conhecimento e nem tempo de um sistema de banco por exemplo, que é um dos sistemas mais complexos existente empregando diversas linguagens.
É fato que nos dias atuais normalmente para projetos e empresas de desenvolvimento, eles solicitam conhecimento em OO.
Se eles solicitassem conhecimento estruturado eles também estariam solicitando conhecimento OO
Galera não vamos brigar neste tópico ok?
bom ele está falando em está falando em Orientação a Objetos ??
bom eu começei a programar dessa forma mais bem eu estava na realidade mesmo só usando class e function até que um amigo meu me disse que isso não é bem o POO , não realidade acho na minha opnião que não tem muita diferença no resultado em si, mais a vantage é o seguinte o code fica mais organizado e você programa 10 vezes mais rapido e deixa de repetir codigos.
POO não é o bicho de 7 cabeça como todos pensam mais é logica pura, deve ter bastate atenção e claro deve ter bastate força de vontade de aprender.
achu que na verdade depde do que a pessoa vai fazer se for coisas simples use o php mesmo e seja feliz =D o importante e ser felizz deus abeçoe a todos!
Fico triste por eu ter aprendido somente estruturado. Vou estudar classes, eu terei de me acostumar com elas assim como me acostumei com estruturado, é essencial um OO hoje em dia. /applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/ermm.gif&key=0e759cbb73a282996291068c8fe8bad4f08911c74e6678b73eb234bf96d43c00" alt="ermm.gif" />
@Edit:
Estou com 17 anos. Escolhi alguns cursos, que cito abaixo para estudar e aprofundar ainda mais meu conhecimento dessa linguagem na qual sou amante.
São eles em ordem de conhecimento:
http://www.treinaweb.com.br/curso/logica-oo
http://www.treinaweb.com.br/curso/mysql
http://www.treinaweb.com.br/curso/php-orientado-objetos
http://www.treinaweb.com.br/curso/php-seguranca
http://www.treinaweb.com.br/curso/mvc-com-php-orientado-a-objetos
O que acham? /applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/laugh.gif&key=fb9a849ac525d2fd317adad061adf02e38bd5f5cb2c664d803c1667dd70a2af1" alt="laugh.gif" />
>
Fico triste por eu ter aprendido somente estruturado.
o tem de livros, apostilas e videos ensinando php estruturado e mysql não é atoa q tem tanta gente q so sabe estruturado.
>
não há grandes diferenças entre criar um sistema estruturado totalmente (sem usar classes nem nada) ou OO (com classes) o ideal seria mesmo misturar os dois, mas tenha em mente que são dois conceitos que não são muito diferentes.
não tem muita diferença? tem como dar um exemplo de codigo?
veja os sistemas estruturados em php, é quase certeza q misturam o codigo da logico com o html sem contar as variaveis globais.
mistura sempre termina em bagunaça.
O que vocês tem que ter em mente é que OO não é somente utilizar classes para se programar, a OO é um paradigma de programação, ou seja, uma outra lógica e fluxo para se programar... Existe muito mais coisa na OO que classes, existem polimorfismos, heranças e muito mais, além de padrões de projetos (design patterns) que auxiliam e muito para o entendimento do código.
É possível fazer sistemas grandes de forma estruturada, mas imagine que você tenha que mudar alguma coisa no fluxo da aplicação, você vai perder meses para uma pequena alteração.
Eu acredito que quem defende a estruturada na verdade nunca trabalhou com mais pessoas no mesmo projeto, no estruturado não há uma formalidade, é tudo feito meio que na gambiarra, a lógico está junto com a apresentação, com a OO e a utilização de padrões como o MVC é possível ter designers, programadores, engenheiros, testers trabalhando simultaneamente em um mesmo projeto sem que estes tenham conflitos ou dificuldades para entendimento do código.
Acreditem crianças, quando forem aprender a utilizar o OO comecem com a mente aberta, esqueçam aquilo que vocês sabem de estruturado, posso até me arriscar a dizer que aprender PHP de forma OO é quase como aprender uma nova linguagem.
Estude POO por favor, você ainda nem imagina o que pode ser feito em PHP, ainda mais agora com os traits, se informe em como desenvolver com POO utilizando metodos mágicos, e você verá o quanto é diferente os 2 modos de desenvolvimento
>
não tem muita diferença? tem como dar um exemplo de codigo?
veja os sistemas estruturados em php, é quase certeza q misturam o codigo da logico com o html sem contar as variaveis globais.
mistura sempre termina em bagunaça.
Nem sempre, o uso dos dois métodos de programação pode levar um programa simples para uma aplicação complexa, por exemplo, podemos criar uma classe usando o paradigma POO, criamos classes, objetos, usamos heranças, isso diminui o uso da CPU e aumenta o desempenho, porém se precisarmos de pequenas funções simples podemos estruturar poucas linhas de código fora da aplicação e interligá-la com a aplicação em si, temos um sistema que une o melhor de tudo, a facilidade da estruturação com a rapidez do método orientado.
Fico triste por eu ter aprendido somente estruturado. Vou estudar classes, eu terei de me acostumar com elas assim como me acostumei com estruturado, é essencial um OO hoje em dia.
A POO melhora o desempenho da aplicação, ela ensina coisas novas sobre os modos como você pode programar, não é que se você usar estruturados você não tem chance, muitas empresas ainda usam scripts estruturados para suas aplicações, como eu disse no quote de cima, a estruturação é mais simples e mais rápida para se executada, porém peca no desempenho para com a máquina, já o OO pode tanto ser mais rápido quanto ter mais performance com relação a máquina usada, ai vai depender de como você estrutura seus dados dentro do método OO. Mas se você quiser aprender eu sugiro pegar algumas referencias bem básicas de VB.NET e ir no site do macoratti que ele tem uma lição em 5 passos sobre POO.
Eu estou com um grande projeto em mente, e ele irá esperar alguns meses, ou até ano(s), pois irei sem dúvida enfiar a cara em apostilas compradas e/ou gratuitas. Sem contar que já comprei os cursos no TreinaWeb de Lógica OO, PHP OO e MVC. Pretendo extender ao máximo meu conhecimento! Vou esquecer o que já sei e enfiar a cara em aprender OO.
>
Estude POO por favor, você ainda nem imagina o que pode ser feito em PHP, ainda mais agora com os traits, se informe em como desenvolver com POO utilizando metodos mágicos, e você verá o quanto é diferente os 2 modos de desenvolvimento
Sem dúvida os metódos de desenvolvimento são completamente diferentes, isso é fato. No entanto, eu gostaria de saber qual aplicação seria cosntruida com OO e não com estruturado? /applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/ermm.gif&key=0e759cbb73a282996291068c8fe8bad4f08911c74e6678b73eb234bf96d43c00" alt="ermm.gif" />
É fato que ela é organizada, tem padrão de projeto e todo o que engloba melhorias, no entanto, qual exemplo de sistema que o OO faz que o procedural não?
Já estou estudando, é insano querer aprender tanto quanto eu. Haha!
Let's study! /applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/clap.gif&key=ab7a79d2320a1ded436b2ab0fea47e116ade502c5a2c7167044566e6dce34a83" alt="clap.gif" />
Acredito que o PHP ainda não chegou nesse patamar de a OO fazer coisas que a estruturada não consegue (talvez seja necessário algum work around mas será possível) e acredito que não seja nem essa a questão de se utilizar ou não a OO. A principal vantagem é a facilidade de desenvolvimento e manutenção.
A questão não é OQ é construído em um que não pode ser no outro, e sim a facilidade no código e a forma de manusear
Aqui vai um exemplo simples de fazer um site...
Digamos que você gere o template na classe BASE
class base {
function __construct() {
?>
<!DOCTYPE html>
<html>
<head></head>
<body>
<div class="header"><?php $this->header(); ?></div>
<div class="content"><?php $this->content(); ?></div>
<div class="footer"><?php $this->footer(); ?></div>
</head>
</html>
<?
}
function header() {
echo 'HEADER';
}
function content() {
echo 'CONTENT';
}
function footer() {
echo 'FOOTER';
}
}
E agora você quer alterar o conteudo na página contato ai então:
class contato extends base {
function content() {
echo 'CONTENT DA CONTATO';
}
}
E isso é um exemplo MUITO do simples, se informe sobre o uso de NAMESPACES, e como ele pode ser usado para auto incluir as classes, e nunca mais você irá programar estruturado. ISSO EU TE GARANTO.
Nesse caso é só saber programar em procedural corretamente.
Eu por exemplo, criei a página index.php que recupera o parâmetro e inclui o arquivo de controle (pasta /control/), ele inclui a model que é responsável pelo PHP e a control dessa página também inclui os arquivos do template.
Nesse caso, é muito prático alterar meus códigos. Eu fiz um "MVC" só que estruturado, e claro, menos eficaz, mas ainda sim é um design pattern. Eu utilizei o mesmo modelo no novo projeto da uGupa e da Focalize TV, felizmente estou contente com eles.
Eu irei estudar porque eu gosto muito de PHP, e todo conhecimento é bem vindo. Agora fiz 40% do curso de lógica OO, falta ainda MVC e muitos outros, haha! Gastei uma graninha nesses cursos mas vou me aperfeiçoar.
Este meu modelo de "MVC-> Model, view e control" é um tanto quanto bom. Pois todo PHP eu posso mudar na Model, já os temas eu posso mecher na View e o control é somente o tratamento das páginas, não sendo preciso mecher no mesmo!
Esse meu design pattern ainda tem mútiplos templates e linguagens, todos padronizados. É algo que me facilita muito a vida. Terminei em 90 dias (exatos) um projeto, digamos que, "porte médio". Somente com estruturado e esse "design pattern", se posso dizer assim. /applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/huh.gif&key=796dd2e8f5e667be07f01ae4a535735ac497e0cf1e7e3fc219233ca4d7b2023c" alt="huh.gif" />
E é fato também que cada programador tem um modo diferente de trabalhar. Não dá para quem produz PHP OO dizer que PHP de verdade é OO, assim como quem programa estruturado não pode dizer que PHP de verdade é estruturado, ambos são PHP e ambos são capazes de se criar algo construtivo. Se é uma é mais prática, fácil ou não, é questão de opinião, ou estou enganado? /applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/huh.gif&key=796dd2e8f5e667be07f01ae4a535735ac497e0cf1e7e3fc219233ca4d7b2023c" alt="huh.gif" />
Trabalho:
Qualquer um que começou na época do PHP 4 ou até mesmo anterior, começou com estruturado, porém quando você aprende alguns macetes que podem ser feito com OO no php, você nem olha mais pro estruturado e quer sempre se aperfeioar no OO, e claro mesmo com OO eu tenho funções estruturais, o PHP proporciona isso, e é lindo, pra dar o START no projeto, que é OO por exemplo, ou até funções que fazem ajustes. É gosto, mais a metodologia OO, tenta ao máximo deixa o código o mais próximo da vida real, sendo muito mais facil entender algo como $corpo->mover_braco() do que corpo_mover_braco(), estando em ambiente OO, a classe CORPO terá todas as informações necessárias para saber a posição atual do braço, enquanto a estrutural terá que receber todos esses dados, ou utilizando outras funções recuperar esses dados, gerando mais linhas e mais "dores de cabeça"
Bom, ainda não estou no patamar dos colegas aqui, pois não tenho nem 1 ano de ter feito o módulo PHP no curso.. Pelo que pude perceber Orientação a Objetos é algo mais complexo de se aprender, isso é um fato. Tem algumas coisas que ficam muito mais práticas e elaboradas com POO, mas tem coisas que não valem a pena fazer com Orientação a Objetos, como por exemplo um site pessoal com uma ou duas coisinhas dinâmicas...
Quanto ao estruturado, discordo que o código fique "bagunçado" ou mal feito, pode até não ser tão prático, mas é possível sim fazer algo bom e que não fique engessado.
Como gosto de aprender, estou desenvolvendo um grande sistema(o sistema é meu, não estou fazendo experiências com clientes...) com programação estruturada e pretendo, conforme for avançado, ir aplicando alguns conceitos de POO, até encontrar a "medida ideal".
Eu faço tudo em OO, mesmo pequenas aplicações... PQ?
Pelo simples fato que amanhã, o pequeno pode se tornar grande... E já me aconteceu algumas vezes
>
Eu faço tudo em OO, mesmo pequenas aplicações... PQ?
Pelo simples fato que amanhã, o pequeno pode se tornar grande... E já me aconteceu algumas vezes
Faz sentido. No entanto, o grande também pode ser procedural. Acredito realmente que estou certo quando digo que as metodologias são meras opiniões!
>
Faz sentido. No entanto, o grande também pode ser procedural. Acredito realmente que estou certo quando digo que as metodologias são meras opiniões!
Não são só meras opiniões, tudo está em como você entende as 2, OO é uma metodologia, e se bem entendida, você verá que ela pode ser muito mais benefica que a procedural, PRINCIPALMENTE quando trabalhando em equipe
Como é fantástico este mundo (novo) de metódos, classes, superclasses, subclasses, heranças, polimorfismo, etc.
É altamente indicado o POO, acredito sem sombra de dúvidas que, se alguém quer realmente se dizer programador verdadeiro em PHP deve ter conhecimentos em OO. Além claro, de se tornar um profissional dobradamente melhor. Há uma infinidade de coisas que OO se torna melhor, é mais ou menos que um "social" do PHP, onde a classe social OO, é mais complexa de aprendizado, no entanto ela facilita a vida no ramo. Mas não que isso seja motivo de notoriedade no final dos trabalhos, ou seja, não é notório as diferenças para os usuários finais em um trabalho OO ou procedural.
Se eu estiver errado em alguma citação, sem dúvida, me corrigam!
Você aprendeu sobre tudo isso em 20 minutos?
>
Você aprendeu sobre tudo isso em 20 minutos?
Clararamente que não. Eu estou em 60% do curso de lógica OO, somente a lógica. Fui bem nas provas até agora, (90% em 2 provas). Solicitei material físico para aprendizado também, chega em alguns dias. Mas isso ainda é somente teoria, mas sim, já entendi como funcionam tudo isso, como funciona a hierárquia, polimorfismo, classes, metódos, subclasses, superclasses, etc. Já entendi como eles funcionam e quais suas funções em um código OO. Mas ainda não coloquei em prática isso, é apenas teoria.
Amigo, recém comecei a estudar, acalme-se! Haha. /applications/core/interface/imageproxy/imageproxy.php?img=http://forum.imasters.com.br/public/style_emoticons/default/clap.gif&key=ab7a79d2320a1ded436b2ab0fea47e116ade502c5a2c7167044566e6dce34a83" alt="clap.gif" />
>
Digamos que você gere o template na classe BASE
class base {
function __construct() {
?>
<!DOCTYPE html>
<html>
<head></head>
<body>
<div class="header"><?php $this->header(); ?></div>
<div class="content"><?php $this->content(); ?></div>
<div class="footer"><?php $this->footer(); ?></div>
</head>
</html>
<?
}
function header() {
echo 'HEADER';
}
function content() {
echo 'CONTENT';
}
function footer() {
echo 'FOOTER';
}
}
Nesse exemplo, mesmo que haja uma classe-pai aqui desconsiderada, a implementação correta, para evitar dummy bodies e métodos públicos abstratos, seria utilizando Interfaces:
interface Template {
public function header();
public function footer();
}
class ContactForm implements Template {
public function header() {
echo 'Contact form Header';
}
public function footer() {
echo 'Contact Form Footer';
}
}>
Nesse exemplo, mesmo que haja uma classe-pai aqui desconsiderada, a implementação correta, para evitar dummy bodies e métodos públicos abstratos, seria utilizando Interfaces:
interface Template {
public function header();
public function footer();
}
class ContactForm implements Template {
public function header() {
echo 'Contact form Header';
}
public function footer() {
echo 'Contact Form Footer';
}
}
Como eu disse é um exemplo MUITO simples, e acho que se ele está aprendendo OO, provavelmente ainda nem chegou em INTERFACES, e se chegou aparentemente não teve nem tempo de entender o básico, para ai então entender o porque de utilizar interfaces.
Eu poderia até ter usado traits, que foi implementado agora no php 5.4, que extende a herança horizontalmente, mais como ele mesmo falou que ainda está estudando a metodologia, com o código que eu exibi, acredito que ele possa evoluir sozinho, realizando testes
Gente, minha sincera opinião é:
sim, a programação OO é um pouco mais... "organizada", contextualizada e até mesmo pelo paradigma, que usa classes, induz ao programador "um pouco mais de organização".
Entretanto, depende muito de como é feito o projeto do código. Não adianta o paradigma induzir a organização se o cara não tiver uma metodologia padrão para programar. O que "queimou" a programação estruturada foi a falta de organização na hora de programar, isso pode acontecer na linguagem que for, exemplo: em PHP tem uma página "index.php" e o cara mistura código com o HTML, scripts de banco de dados, css, javascript e etc ... . Aí nem digo que o paradigma usado nem é o estruturado, como um professor meu disse "isso já é lambança", pois a programação estruturada usa funções e não precisa colocar variáveis globais, apenas parametros. Nesse mesmo exemplo se em uma página "index.php", ser apenas o HTML e ter uma página aparte só com as funções, por exemplo, funções.php e lá ter as funções que acessam o banco e as demais funções... será sim um sistema bem performático. Que estou querendo dizer é: Lógico que o paradigma ajuda, porém, de nada vai adiantar se programador não tem um bom padrão de programação.
Tanto que que uns 15 anos atrás, a programação estruturada reinava; grandes sistemas, tais como siape, siafe e alguns da caixa e do BB estão ainda em paradigma estruturado, pois usam cobol, e até onde sei ainda não tem a versão OO para o cobol e nem o natural(linguagem de mainframe). Se forem procurar por análise estruturada no google, vai encontrar muio material sobre e como no OO tem seus diagramas, tais como: diagrama de contexto e o diagrama de fluxo de dados (DFD).
Mas uma comparação bem superficial entre os dois paradigmas:
classe flor{
privado cor;
privado num_petalas;
//agora os metodos
publico desabrochar(){
cor = "branca";
num_petalas = 8;
}
}
Na OO foi fácil "representar uma flor", já que aí você pode definir atributos e métodos.
Já no paradigma estruturado, representar uma flor não seria tão fácil, pra mim em minha humilde opinião, diria até que é quase impossível, mas por quê?! pelo pelo fato do paradigma estruturado ser mais focado em estrutura de dados e seu respectivo processamento. talvez se eu tentasse em programação estruturada... vamos tentar:
array flor ("cheiro" => "bom", "num_petalas" => "8", "cor" => "rosa");
funcao criar_flor(flor){
//decompor array usando um foreach e após atribur os dados e usar-los da forma que achar conveniente
}
Deram pra entender a diferença?!
e saliento, o que queimou a programação estruturada, em especial, em php, foi essa mistureba de codigo em uma página.
Espero ter ajudado :D
tem cobol OO é recente segundo o link desde 2002
de certo modo não é.
depende muito do que você chama de grande sistema/aplicação, certamente se o cliente pedir uma alteração no fluxo do sistema você perderá um mês para mais até conseguir fazer a mudança.
não é atoa, pense nisso.
por que é.
JAMAIS.
por essa pequena declaração eu afirmo, você não programa OO.
no máximo sabe criar classes só que não tenha dúvida que você deve violar no minimo uns 5 princípios básicos.
não é atoa, pense nisso².