Williams Duarte

Para usar múltiplos namespaces, o codigo tem que ir dentro de chaves. <?php namespace Data { ... } namespace Data\User { ... } Mas o melhor mesmo, é separar, pois cada código terá a sua responsabilidade ! De um USE "importe" caso necessário nos componentes. http://php.net/manual/pt_BR/language.namespaces.definitionmultiple.php

Como o Gabriel disse, sua implementação usando classes abstratas, está equivocada! Classes abstratas faz com que você deixe seu código mais coeso e, com baixo acoplamento. Um exemplo de uso na vida real, você pode ter uma classe abstrata "RepositoryAbstract" contendo todos os métodos de manipulação de banco de dados "CRUD" etc, que é comum as demais classes, assim que seu sistema for crescendo. Através de outra Repository, você estende a classe abstrata contendo todos os métodos. class UserRepository extends RepositoryAbstract { } class PostRepository extends RepositoryAbstract { } class AddressRepository extends RepositoryAbstract { } Quando você estudar inversão de dependência as coisas ficaram mais claras. Do mais é estudar mesmo, não tem subjetividade.

Tirando o erro de concatenação, a solução sugerida em criar uma Exception personalizada, é a mesma coisa de dar a volta e parar no mesmo lugar. Pois ambas as Exceptions, tanto PDOException e DataBaseConnectionException, vai estender métodos da classe nativa Exception. Se quer capturar o erro da exceção em Runtime, use Monolog, muito mais simples.

Sua Classe de Conexão pode implementar o Pattern Registry ou Singleton. Dessa forma você evita abrir mais de uma conexão a cada instancia da classe. Login não é CRUD, então não faz sentido herdar funcionalidades! Basta injetar através do construtor! Você está injetando dados de acesso através da Classe CRUD. CRUD.php public function __construct($table){ parent::__construct("mysql:host=localhost;dbname=sistema_compras;","root",""); $this->table = $table; } O correto é ter um arquivo de configuração "config.php", desta forma você injetaria diretamente na conexão. Onde mais você usa esses objetos? private $sql; private $table; private $values; private $condition; Há não ser no próprio escopo da função, declarando nelas uma variável local, que pode ser simplesmente usada diretamente!

Lendo bons livros e artigos!

As principais camadas do MVC, não resolvem todos os problemas de arquitetura, mas ajudou a organizar, senão ainda teríamos os códigos macarrônicos no php, mesmo usando classes. No MVC é responsabilidade de Rotas -> Controller, agora você esta criando o seu, então... Nem vou entrar nesta questão, porque para muitos, todo parafuso é prego. Onde alguns famigerados frameworks escrito em PHP, começaram toda esta bagunça. No JS não conheço muito sobre essas camadas, mas no caso de server-side O Interactors seria responsável por alguns serviços como por exemplo App/ Interactors/ AutenticarUsuario RegistrarUsuario CancelarConta Etc Sim! Saiba que nem tudo você precisa documentar de forma tradicional, algumas metologias ágeis fala o seguinte: http://www.manifestoagil.com.br/ Se você programar com TDD, boa parte desta documentação é desnecessária.

Recomendo que veja este vídeo! Assiste, vai te ajudar entender um pouco mais sobre S.O.L.I.D. já mencionado no slide.

E claro, concatene os valores que vem do retorno da requisição com o HTML.

Use .html() https://api.jquery.com/html/

Uai, mas não é só enviar uma requisição via ajax novamente? Se você quer esse valor depois, que guarde em uma session, ou cookie, no caso do cookie você pode criar no próprio js e, nem precisara enviar a requisição novamente.

Primeiro passo é dar um nome mais conciso, ver o oque este método vai fazer ou retornar! Este método faz oque? Conta o total de empresas por regime tributário, e ao mesmo tempo por movimento financeiro? Não está muito claro e bem confuso. Métodos privados nada mais é do quebrar a aplicação em pequenos trechos de códigos, estes são auxiliares para os métodos protegidos ou públicos. Seus exemplos acima, você pode quebrar em dois métodos privados, já que os métodos públicos nada mais é, do que sua interface, sendo interface, deixe as regras de negocio separados em métodos privados, ou use patterns.

Teus códigos ao mesmo tempo que faz consulta no banco, faz calculo, estoura pipoca, ainda retorna um array. Já ouviu falar em métodos privados, conceito de models, repositorios, services etc?

Seu namespace é o mapeamento para o diretório. composer.json "MinhaApp\\": "src/App/Mvc/" Teu controller ficaria com o seguinte namespace <?php namespace MinhaApp\Controller; class Controller { public function index() { echo 'Olá mundo do MVC'; } } uso <?php use MinhaApp\Controller\Controller; require_once 'vendor/autoload.php'; $controller = new Controller(); $controller->index(); Após alterar o composer.json, você precisará executar novamente dump-autoload no terminal Linux $ composer dump-autoload Saiba mais em: https://getcomposer.org/doc/01-basic-usage.md#the-require-key

Cuidado com os Youtubers que de tudo entende e nada compreende! Programação orientada a Objetos não é sair criando classes e atributos e, estendendo de classes concretas "PAI", alguns comportamentos genéricos. Imagine centenas ou milhares de programadores produzindo código para um único software sem padronização? Seria o caos! É para isso que existe padrões! Sendo assim , uma Classe Concreta chamada Video, pode ser simplesmente substituída por uma interface vazia. VideoInterface { } A partir desta interface abstrair métodos "comportamentos" de outras classes, ao invés ficar estendendo de classes concretas, oque deixa teu código com forte acoplamento e, de difícil manutenibilidade. Exemplo, deixando o simples: class VerVideo implements VideoInterface { public function qualquer_coisa($param) { ... } } class MostraSinopse implements VideoInterface { public function qualquer_coisa($param) { .... } } class MostraTitulo implements VideoInterface { public function qualquer_coisa($param) { .... } } Desta forma não criei nenhum Getter e Setter e a aplicação ficou coesa. Uso de duas formas, ou registro a interface em um contêiner para substituir a concreta fazendo a inversão de dependência "DIP", ou chamo a classe concreta diretamente, verificando se a interface foi implementada. http://php.net/manual/pt_BR/internals2.opcodes.instanceof.php Minha dica é compre bons livros e recomendado pela comunidade de desenvolvedores. Exemplos de alguns livros:

Não existe soluções simples para problemas de engenharia de software, então temos que tapar várias lacunas com diversos materiais, mesmo passando por uma faculdade, o máximo que também terá é uma pincelada. No meu caso venho corrigindo, através de nuances de livros e materiais da IGTI