Orientação a Objetos

[Hive Pass 2]

Olá pessoal, eu estou iniciando na Orientação a Objeto, na realidade eu já estou introduzido na Orientação a Objetos, só que mesmo lendo vários artigos, tentando praticar, sempre me resta dúvidas. Eu gostaria de fazer algumas perguntas e quem poder me responder, serei grato.

Certa vez eu fiz uma leitura em uma postagem bem extensa onde várias pessoas participaram, onde um usuário perguntou como pensar orientado a objetos. Isso já foi/é também um problema para mim, mas então o João neto respondeu que antes de qualquer coisa a gente deve conhecer o problema e fazer com que o objeto tenha uma responsabilidade e saiba resolver esse problema (responsabilidade).

Eu estou fazendo um sistema, mas para mim ele NUNCA está bom, sempre acho que a orientação a objetos que eu tentei aplicar fugiu do sentido da orientação a objetos e fiz um macarrão em um único método.

A primeira pergunta é: Mesmo eu conhecendo o problema, sabendo o que eu devo fazer, qual é o conceito que vocês usam para criar os métodos correto, fazer essa divisão e evitar esse macarrão.

O sistema é simples, ele tem que pegar a url e fazer uma divisão em partes e cada parte dessa url eu chamo de um nome, por exemplo (como um router MVC):

www.meusite.com.br/controller/method/action/arg

O objeto pegaria a url apenas na parte /controller/method/action/value e faz uma separação, onde essa separação define por "/" cada parte da url, por exemplo:

controller = O Controller

method = O Method

action = O Action

arg = O Argument (arg)

Nisto eu fiz o seguinte, criei um contruct comum e dentro do construct eu chamei um método privado que eu criei chamado split_uri();

e dentro do método privado split_uri(); eu fiz a separação de cada parte da url e de acordo com que eu fazia isso, eu setava algumas variáveis globais (propriedades) determinadas.

e depois em cada método como get_controller() eu retornava o valor da variável global (propriedade).

 

<?php

class MVCRouter
{

    private $controller;
    
    private $method;
    
    private $action;
    
    private $arg;
    
    public function __construct()
    {
    
         $this->split_uri();
        
    }
    
    private function split_uri()
    {
    
        $url_splitted = preg_split("[\\/]", $_SERVER["REQUEST_URI"], -1, PREG_SPLIT_NO_EMPTY);
        
        $this->direction = (isset($url_splitted[0]) ? $url_splitted[0] : "index");
        
        $this->handler = (isset($url_splitted[1]) ? $url_splitted[1] : "index");
        
        $this->action = (isset($url_splitted[2]) ? $url_splitted[2] : "index");
        
        $this->arg = (isset($url_splitted[3]) ? $url_splitted[3] : "");
    
    }
    
    public function get_controller()
    {
    
        return $this->controller;
    
    }
    
    private function get_method()
    {
    
        return $this->method;
    
    }
    
    public function get_action()
    {
    
        return $this->action;
    
    }
    
    public function get_arg()
    {
    
        return $this->arg;
    
    }

}

Eu sei o que ele tem que fazer, e tudo mais, mas na hora da aplicação, tento colocar a responsabilidade no objeto que é de pegar a url, dividir em partes e ter métodos da interface.

Eu também tento sempre seguir os principios da programação como DRY, KISS e tudo mais, mas ás vezes o problema sempre aparece. Por exemplo, nesse mesmo sistema eu tenho um problema, e eu percebi que eu repeti o código 3 vezes, mas porque existe uma verificação 3 vezes e a cada verificação eu faço uma repetição de código, o que muda em cada verificação if, elseif e else são pequenas linhas de código, funciona como um switch, onde dependendo de cada resultado eu faço uma setagem de 3 variáveis globais, mas eu percebi que eu gerei uma repetição.

Eu gostaria de saber o que vocês pensam antes de definir os métodos... é uma pergunta até meio sem nexo, mas é bem complicado de se explicar assim, porque vejam meu código, eu sabia o problema, mas os únicos métodos que veio na mente para definir foram esses.

O que me deixou achando que eu sai dos principios da orientação a objetos nesse código foi o método privado que eu criei e eu chamo a execução dele no construct do sistema, por isso eu achei que ficou bem estranho.

Obrigado gente;

É uma situação bem complicada, mas vou tentando deixar mais fácil para todos entenderem e tentar resolver isso.

Pode ser também que eu sempre acho que o código está ruim porque eu sou um cara ultra metódico, de besço mesmo, e isso as vezes me f**.

[Cristianoferr 32]

Sobre a url, não é mais fácil usar um .htaccess?

RewriteRule ^controller/([a-z0-9-]+)/([a-z0-9-]+)/([a-z0-9-]+)?$ /controller.php?method=$1&action=$2&arg=$3 [NC,L]

Programação é um eterno aprendizado, usar metodologias como MVC ajuda muito, pois ajuda a determinar responsabilidades para cada camada.

Programar com intenção é o que eu vejo que mais ajuda ao dar nomes próprios aos métodos e variáveis.

Focar em métodos que fazem uma coisa só.

E não trabalhar com números mágicos e strings soltas, sendo melhor criar constantes ou simplesmente não usar, delegando a responsabilidade. O seu método por exemplo usa de números mágicos ao pegar a posição e string solta ao definir o valor padrão para "index". E se isso mudar?

Eu confesso que ainda deixo a desejar na minha programação, eu peco em vários pontos, mas é uma questão de estar sempre se corrigindo.

Bom, no geral, eu recomendo o livro "Código Limpo", é muito bom.

 

O que me deixou achando que eu sai dos principios da orientação a objetos nesse código foi o método privado que eu criei e eu chamo a execução dele no construct do sistema, por isso eu achei que ficou bem estranho.

Na verdade foi o contrário, você fez o certo ao separar esse código do construct. E se tivesse mais código no construct, inicializando outras variáveis? Ia deixar misturado? Não né.

 

Quer um exemplo de como o código poderia ter sido melhorado sem duplicar o código?

Ao invés disso:

 

$this->direction = (isset($url_splitted[0]) ? $url_splitted[0] : "index");
$this->handler = (isset($url_splitted[1]) ? $url_splitted[1] : "index");
$this->action = (isset($url_splitted[2]) ? $url_splitted[2] : "index");
$this->arg = (isset($url_splitted[3]) ? $url_splitted[3] : "");

 

Cria uma função como essa:

 

function pegaValorParametro($url,$index,$valor_default){
$retorno=(isset($url[$index]) ? $url[$index] : $valor_default);
}

 

E substitui o codigo por isso:

 

$this->direction =pegaValorParametro($url_splitted,0,"index");
$this->handler =pegaValorParametro($url_splitted,1,"index");
$this->action =pegaValorParametro($url_splitted,2,"index");
$this->arg =pegaValorParametro($url_splitted,3,"");

 

Daria para tirar o $url_splitted do parametro do metodo se fosse feito o calculo dentro da função, mas aí depende se é um processo computacionalmente caro ou não.

Claro que com o .htaccess isso seria desnecessário, bastaria dar um $_GET no parametro.

[Hive Pass 2]

Na realidade @Cristianoferr esses posicionamentos no qual você se refere por exemplo $split_url[0], estão corretos, pois sempre o controller vai ser o da primeira posição do array, e como você viu, eu faço uma verificação antes para saber se ele existe, caso não exista eu coloco um padrão.

 

Eu entendo seu ponto de vista e gostei, de que devemos programar com intensividade para conseguirmos dar nomes aos métodos. Até ai tudo bem, mas a questão não é apenas essa, e sim também sobre a questão de legibilidade, de termos como por exemplo não utilizar um nome maior do que 23 caracteres e outras coisas, na realidade, boas práticas.

 

Sobre o htaccess não dá certo fazer diretamente porque eu preciso fazer essa verificação nesse objeto, porque depois se em minha aplicação, em algum momento eu precisar saber qual é o controller, eu poderei saber por causa do objeto router, onde ele fez a divisão e me passou apenas o controller.

 

Caso mais alguém tenha opinião e ponto de vista sobre isso será bem vindo.

 

Obrigado.

[hinom 5]

Sugiro incluir verificação do SAPI

 

Exemplo

$sap_cli = ( php_sapi_name() == 'cli' ) ? true : false;

 

Isso caso vc queira disponibilizar a execução dos módulos via shell aproveitando os mesmos recursos.

 

Se for aplicar isso, o httaccess não sevirá pois o PHP é executado diretamente. Por isso particularmente prefiro não deixar o app dependente de terceiros como htaccess (Apache), web.config (IIS) entre outros.

 

Há outras validações para fazer também, por exemplo, está esquecendo do modo padrão, resgatando os parâmetros pelo GET ou POST. Ex: /?c=controller&method=action&value=read

 

 

Outro passo é rotear links alias.

[Cristianoferr 32]

Na realidade @Cristianoferr esses posicionamentos no qual você se refere por exemplo $split_url[0], estão corretos, pois sempre o controller vai ser o da primeira posição do array, e como você viu, eu faço uma verificação antes para saber se ele existe, caso não exista eu coloco um padrão.

Entendo, mas ainda assim é um magic number... se for seguir à risca padrões de desenvolvimentos, números mágicos teriam que sumir, não é algo ultra-necessário e sim uma boa prática.

 

 

Eu entendo seu ponto de vista e gostei, de que devemos programar com intensividade para conseguirmos dar nomes aos métodos. Até ai tudo bem, mas a questão não é apenas essa, e sim também sobre a questão de legibilidade, de termos como por exemplo não utilizar um nome maior do que 23 caracteres e outras coisas, na realidade, boas práticas.

Bom, não conheço essa boa prática de evitar nomes com mais do que 23 caracteres. Nomes devem ser descritivos, para manter o nome de uma função pequeno é simples: a função deve ser focada em fazer uma coisa apenas.

 

 

Sobre o htaccess não dá certo fazer diretamente porque eu preciso fazer essa verificação nesse objeto, porque depois se em minha aplicação, em algum momento eu precisar saber qual é o controller, eu poderei saber por causa do objeto router, onde ele fez a divisão e me passou apenas o controller.

Com o htaccess você faria justamente isso sem precisar usar split na url.

Um exemplo melhor:

 

RewriteRule ^([a-z0-9-]+)/([a-z0-9-]+)/([a-z0-9-]+)/([a-z0-9-]+)?$ /mvcrouter.php?controller=$1&method=$2&action=$3&arg=$4 [NC,L]

 

Dessa forma a url www.meusite.com.br/controller/method/action/arg é traduzida em seus respectivos componentes, bastando dar um get no parametro desejado.

[Hive Pass 2]

Bom, não conheço essa boa prática de evitar nomes com mais do que 23 caracteres. Nomes devem ser descritivos, para manter o nome de uma função pequeno é simples: a função deve ser focada em fazer uma coisa apenas.

Era apenas um exemplo... :thumbsup:

 

Sobre o htaccess eu já utilizo o mesmo para passar os parametros da url para o index.php.

RewriteRule ^(.*)$ index.php/$i [QSA,L]

Mas a questão não é essa, vamos esquecer htaccess, porque independente dele o sistema tem que funcionar separando a url.

 

www.meusite.com.br/index.php/controller/method/action/arg. Htaccess é opcional.

 

Voltando para o assunto em questão:

 

O que eu quero realmente saber é se meu código está bem escrito, se não saiu da ideia do orientado a objetos, se existiriam outras formas de escrever-lo. (esqueça o Htaccess, estamos falando de orientação a objetos)

 

Obrigado.

[Hive Pass 2]

Uma coisa que me deixou curioso e pensando intensamente é sobre a questão dos números mágicos, eu queria de verdade saber como eu poderia remover os números mágicos em um caso por exemplo de preg_split, ou preg_match no caso se ele for utilizado em algum momento no sistema?

 

Alguém mais tem opinião sobre o assunto em questão?

[shini 318]

no preg_match vc pode definir os 'indices'.

 

 

 

 

<?php

$str = 'foobar: 2008';

preg_match('/(?P<name>\w+): (?P<digit>\d+)/', $str, $matches);

print_r($matches);

http://php.net/manual/en/function.preg-match.php

[Hive Pass 2]

Muito obrigado. @shini

Eu estava sem internet de ontem para hoje, mas eu tenho toda a documentação do PHP no computador e eu percebi isso de ontem para hoje, mas não tinha entendido muito bem, mas obrigado por me lembrar disso.

Mas me fale, isso apenas no caso do preg_match correto? e no preg_split? Como ficaria a questão da existência dos números mágicos?

[shini 318]

Com o preg_split não é possivel definir os indices, por exemplo o preg_split retornar mtos itens vc vai usar um for/foreach ou seja o indice não interessa, se forem poucos no maximo 3 vc pode usar direto esses 'numeros magicos' porém deve-se evidenciar o contexto.

 

tem esse livro aqui que é so sobre estilo de codigo => http://www.skoob.com.br/livro/218267-a-arte-de-escrever-programas-legiveis

[Enrico Pereira 299]

Clean Code do Uncle Bob, Refactoring to Patterns do Martin Fowler e Test Driven Development By Example do Kent Beck são livros que você pode ter um grande interesse.

 

O roteamento de URLs não está mais sendo feito dessa forma "mágica" de /controller/action/id como era feito no passado. Hoje em dia os routers "manuais" estão sendo usados, um deles é o Respect\Rest.

[Hive Pass 2]

Com o preg_split não é possivel definir os indices, por exemplo o preg_split retornar mtos itens vc vai usar um for/foreach ou seja o indice não interessa, se forem poucos no maximo 3 vc pode usar direto esses 'numeros magicos' porém deve-se evidenciar o contexto.

 

tem esse livro aqui que é so sobre estilo de codigo => http://www.skoob.com.br/livro/218267-a-arte-de-escrever-programas-legiveis

Muito obrigado. Estarei dando uma olhada no livro.

 

Clean Code do Uncle Bob, Refactoring to Patterns do Martin Fowler e Test Driven Development By Example do Kent Beck são livros que você pode ter um grande interesse.

 

O roteamento de URLs não está mais sendo feito dessa forma "mágica" de /controller/action/id como era feito no passado. Hoje em dia os routers "manuais" estão sendo usados, um deles é o Respect\Rest.

Interessante, estou começando a ler o livro Clean Code. - Muito obrigado pela indicação dos outros livros.

Assim eu ainda vejo o router como algo interessante, pois como o nome já fala, router, ele faz que possamos definir uma rota antes, como funciona no Code Igniter, e outros frameworks, onde você coloca em uma variável, normalmente nas configurações, uma lista de routes que você quer que, no caso, se o usuário tentar acessar pela url o router definido nas configurações, ele leva para um controller definido nas configurações de route, mas caso contrário, se nenhum router for definido, ou o que o usuário colocou na url não "bater" com nenhum router, ele mesmo, automaticamente cria o destino baseando-se no que o usuário digitou na url, pegando as partes da url e definido quem é o controller, quem é o action e assim por diante. Não sei se entendeu, mas verifica sobre routing no Code Igniter, e o melhor exemplo de todos sobre o assunto routing é o Laravel, que creio que foi baseado no sistema de routing do Ruby on Rails.

Mas fora isso, nunca tinha ouvido/lido sobre o Respect\Rest, vou dá uma olhada.

 

@edit

Depois eu li direito seu comentário, eu percebi que você falou que hoje em dia não é muito feito routeamento automatico, mais manual.

Depende, um Framework ele se comporta bem de ambas formas, a configuração manual do router é totalmente opcional como eu escrevi no texto em cima. Caso o usuário não configure as rotas, o framework se encarrega de definir quem será o controller, action e tudo mais baseando-se pela url digitada pelo usuário.

 

Eu estou tentando adaptar meu código para isso, estou tendo algumas dificuldades, problemas e tudo mais, tentando deixar ele funcionamento da forma que os frameworks funcionam, e sempre dentro das boas práticas, por isso a postagem, para saber sobre essas questões, quais são e quais não são boas práticas.

 

Chegamos a uma discurção legal, que é sobre a questão dos números mágicos, que não é interessante a utilização.

 

Mais alguém tem algo em mente que não acha que é uma boa prática ou que é uma boa prática em orientação a objetos ou até mesmo em programação procedural?

 

Se quiserem analisar meu código e falar algo a respeito dele também, fiquem à vontade.

 

Acho que muita gente tem dúvidas parecidas, e essa postagem ajudaria várias pessoas.

[Enrico Pereira 299]

Orientação a objetos é um paradigma. Você pode escrever qualquer lógica com ela.

 

Eu consigo identificar apenas um problema nesta classe: acoplamento. Você está acessando a $_SERVER['REQUEST_URI'] de forma direta. O ideal é que isso seja passado como parâmetro, nesse caso no construtor.

 

As rotas manuais são melhores porque:

- São customizáveis.

- São escaláveis.

- São uma espécie de "documentação" das URLs de sua aplicação.

- São explícitas, mais fáceis de manter.

- Não são acopladas com nome de classe/método.

 

Uma dica: não use o CodeIgniter ou qualquer outro framework velho como base. O próprio Rails não usa mais rotas implícitas, ele trata elas como uma configuração legada.

[Hive Pass 2]

Orientação a objetos é um paradigma. Você pode escrever qualquer lógica com ela.

 

Eu consigo identificar apenas um problema nesta classe: acoplamento. Você está acessando a $_SERVER['REQUEST_URI'] de forma direta. O ideal é que isso seja passado como parâmetro, nesse caso no construtor.

 

As rotas manuais são melhores porque:

- São customizáveis.

- São escaláveis.

- São uma espécie de "documentação" das URLs de sua aplicação.

- São explícitas, mais fáceis de manter.

- Não são acopladas com nome de classe/método.

 

Uma dica: não use o CodeIgniter ou qualquer outro framework velho como base. O próprio Rails não usa mais rotas implícitas, ele trata elas como uma configuração legada.

 

Muito obrigado pelas dicas.

Qual você considera um framework velho ou novo?

Porque assim, eu tenho uma coisa em mente mas não sei se tem lógica no que eu vou escrever.

Quando algo fica ultrapassado ou removemos ele do sistema, ou declaramos ele como obsoleto na documentação e deixamos público o motivo. Em momento nenhum eu percebi isso no Code Igniter e na maioria dos frameworks que eu conheço que utiliza o sistema de router tanto manual quanto automatico.

 

No caso... Vamos fazer uma suposição.

Se você não definir as rotas em um framework o que aconteceria? Ele ficaria inútil? Onde o usuário não poderia acessar endereços que não foram definidos manualmente? Imagine um site GIGANTE, como por exemplo um e-commerce, onde tem várias páginas, imagine agora o arquivo de configuração de rotas como não ficaria.

 

Infelizmente na internet não consigo encontrar nenhum artigo que deixa claro isso sobre as rotas, de que as rotas automaticas estão ultrapassadas e tudo mais. O pesssoal da internet, normalmente quando o assunto é frameworks, tutoriais referentes a frameworks, quase não tocam no assunto routing, então me veem logo a cabeça de que o framework por si ele já cuida das rotas para a gente, já faz o sistema de routing automaticamente, ou eu estou errado?

 

Me deixa entender isso direito, por favor, poderia me explicar?

 

E muito obrigado pelas dicas do meu código.

 

Esse código é apenas um exemplo que eu tinha em mente para abrir uma discurssão, mas foi bom saber disso que você falou sobre a questão de acessar o $_SERVER['REQUEST_URI'] diretamente, que é melhor passar como paramêtro.

 

Qual seria a diferença de passar o $_SERVER['REQUEST_URI'] por parametro e acessa-lo diretamente?

 

$router = new RouterMVC($_SERVER['REQUEST_URI']);

 

Assim que você está falando? Se sim, qual a diferença?

 

Obrigado.

[Enrico Pereira 299]

Muito obrigado pelas dicas.

Qual você considera um framework velho ou novo?

 

Não é o framework em si, mas a versão dele. O CI é um framework que vive em razão de compatibilidade com versões anteriores pois os clientes da empresa que faz o CI usam o CI em versões antigas.

 

 

Quando algo fica ultrapassado ou removemos ele do sistema, ou declaramos ele como obsoleto na documentação e deixamos público o motivo. Em momento nenhum eu percebi isso no Code Igniter e na maioria dos frameworks que eu conheço que utiliza o sistema de router tanto manual quanto automatico.

 

O Rails foi quem declarou isso como obsoleto, não o CI.

A maioria dos frameworks modernos não faz uso disso. Veja Rails, Django, Symfony2, Zend Framework 2, Laravel, Play! Framework, Express, etc. Isso só existe em poucos frameworks da comunidade PHP como CI, Cake, etc.

 

Não que isso seja ruim, mas esse tipo de mágica é complicado quando o sistema cresce. Além de destruir a flexibilidade e deixar mais difícil a aplicação de REST.

 

 

Se você não definir as rotas em um framework o que aconteceria? Ele ficaria inútil? Onde o usuário não poderia acessar endereços que não foram definidos manualmente? Imagine um site GIGANTE, como por exemplo um e-commerce, onde tem várias páginas, imagine agora o arquivo de configuração de rotas como não ficaria.

 

Rota é uma definição de URL. Se não há uma rota definida para a página, logo é uma página 404.

 

Eu acho que você teve um mal entendimento de rotas. Você não define uma rota para cada posts, mas define um modelo de rotas.

Na prática:

 

 

 

// No arquivo de rotas
$router->get('/posts/{slug}', 'PostsController#post');

// No arquivo do controller
class PostsController
{
    public function post($slug)
    {
        echo 'Você requisitou o post com o slug: ' . $slug;
    }
}

 

 

Infelizmente na internet não consigo encontrar nenhum artigo que deixa claro isso sobre as rotas, de que as rotas automaticas estão ultrapassadas e tudo mais. O pesssoal da internet, normalmente quando o assunto é frameworks, tutoriais referentes a frameworks, quase não tocam no assunto routing, então me veem logo a cabeça de que o framework por si ele já cuida das rotas para a gente, já faz o sistema de routing automaticamente, ou eu estou errado?

 

Não errado, mas desinformado.

Veja a documentação do Laravel, por exemplo: http://laravel.com/docs/quick. Logo após a instalação, ela já fala sobre rotas.

 

 

Esse código é apenas um exemplo que eu tinha em mente para abrir uma discurssão, mas foi bom saber disso que você falou sobre a questão de acessar o $_SERVER['REQUEST_URI'] diretamente, que é melhor passar como paramêtro.

 

Qual seria a diferença de passar o $_SERVER['REQUEST_URI'] por parametro e acessa-lo diretamente?

 

$router = new RouterMVC($_SERVER['REQUEST_URI']);

 

Assim que você está falando? Se sim, qual a diferença?

 

Obrigado.

 

Sim. Há uma diferença. Você não está aplicando testes unitários agora, mas quando estiver (é uma evolução natural de desenvolvimento) você verá que facilita a testabilidade do código. Desculpe-me se confundi você ainda mais haha.

 

Isso é um conceito chamado Dependency Injection.

[Hive Pass 2]

Sensacional @Enrico Pereira, muito bom mesmo.

Rota é uma definição de URL. Se não há uma rota definida para a página, logo é uma página 404.

Eu acho que você teve um mal entendimento de rotas. Você não define uma rota para cada posts, mas define um modelo de rotas.
Na prática:

JUSTAMENTE isso que eu estou tentando lhe falar.

As rotas que a gente configura:

$router->get('/posts/{slug}', 'PostsController#post');

Elas são opcionais correto? Pois a definição derotas é dada a partir da URL digitada pelo usuário.

As configurações de rotas servem apenas caso você queria levar o usuário para um controller especifico. por exemplo:

/posts/

Vamos supor que o usuário digitou www.meusite.com.br/posts/ e você fez uma configuração de rota:

$router->get('/posts/{slug}', 'CustomController#post');

Perceba que ao invés do framework automaticamente pegar "posts" da URL como o controller, ele verifica se existe uma rota definida nas configurações para caso o usuário digite "posts" na url, se existe ele pega o que está escrito logo depois nas configurações e utiliza dele para definir quem é o controller, nesse caso o "CustomController" correto?

É justamente isso que eu estou tentando lhe falar, se por acaso, o usuário não configurar as rotas, o framework AUTOMATICAMENTE vai utilizar a url para definir quem é o controller, action e tudo mais? ou ele só funciona se a gente definir as rotas antes?

No caso, se eu não definir a rota "posts" e o usuário acessar www.meusite.com.br/posts ele vai acusar 404?

Se você responder que não precisamos configurar as rotas, ai meio que cria uma controversa, pois você falou que os frameworks, eles não utilizam mais a técnica de roteamento automático logo precisariamos SEMPRE configurar as rotas antes para qualquer controller criado?!.

Justamente isso que está me deixando confuso. :P

 

@edit

 

 

Sim. Há uma diferença. Você não está aplicando testes unitários agora, mas quando estiver (é uma evolução natural de desenvolvimento) você verá que facilita a testabilidade do código. Desculpe-me se confundi você ainda mais haha.

 

Isso é um conceito chamado Dependency Injection.

 

Pelo contrário, foi bom você ter me avisado. :D

[Enrico Pereira 299]

Sim, a ideia é ter menos mágica. Essa é uma convenção ruim.

 

Se eu tiver um controller Posts com o método foo e não quiser que a URL /posts/foo seja uma URL, e aí? A convenção me obriga...

 

Configuração às vezes é necessária. 100% convenção vira uma bola de neve.

[Hive Pass 2]

Sim, a ideia é ter menos mágica. Essa é uma convenção ruim.

 

Se eu tiver um controller Posts com o método foo e não quiser que a URL /posts/foo seja uma URL, e aí? A convenção me obriga...

 

Configuração às vezes é necessária. 100% convenção vira uma bola de neve.

De verdade, muito obrigado por essas informações.

 

Eu concordo com você até certos pontos, de que devemos sim configurar para evitar coisas não convencionais.

 

Creio que até mesmo evita alguns problemas de segurança como LFI (Local FIle Inclusion).

 

Eu entrei nessa questão porque eu não tenho conhecimento sobre vários frameworks, apenas o Code Igniter e um pouco de Zend, mas não acho convencional ainda aprender outros frameworks, por isso essa informação não era válida para mim.

 

Certa vez eu assisti um Hangout com o @João Batista Neto de 6 horas de duração, era dividido em duas partes, falando sobre Frameworks e Ferramentas PHP e o Alexandre Gaigalas em algum momento do vídeo ele fala que a questão da configuração de roteamento do Framework é totalmente opcional, por isso eu afirmei, afinal, além dele ter falado, até onde eu tenho conhecimento eu sei que os routes são opcionais, até você falar agora que isso é um recurso obsoleto, e que devemos definir obrigatóriamente as configurações de routes para evitar coisas não convencionais.

Então, eu não tinha conhecimento sobre isso justamente, como eu falei, não parei para aprender outros frameworks ainda, porque os problemas que eu tive, problemas de domínio como fala o João no vídeo, foram resolvidos com o Code Igniter, por isso eu não parei para aprender outros, só tomei conhecimento sobre cada um, mas percebi que ele me ajudaria no meu problema.

 

Mas obrigado por me deixar informado sobre essa questão dos routes.