Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Estive olhando alguns posts aqui sobre interface e implementei um pedaço de código, gostaria que os feras me orientassem quanto ao modelo.
iuser.php
<?php
interface iUser
{
public function login();
public function logout();
}user.php
<?php
class user implements iUser
{
public function __construct() {}
public function login() {
echo 'User - Login!';
}
public function logout() {
echo 'User - Logout!';
}
}iCadastro.php
<?php
interface iCadastro
{
public function cadastrar($objeto);
}funcionario.php
<?php
class funcionario extends user implements iCadastro
{
public function __construct() {}
public function cadastrar($objeto) {
echo 'Funcionario - Cadastrar!';
}
}gerente.php
<?php
class gerente extends funcionario
{
public function __construct() {}
public function cadastrar($objeto) {
if (get_class($objeto) === 'funcionario') {
echo 'Gerente Cadastra Funcionario!';
}else{
throw new Exception('Falha ao cadastrar funcionario!');
}
}
}
<?php
class administrador extends gerente
{
public function __construct() {}
public function cadastrar($objeto) {
if (get_class($objeto) === 'gerente') {
echo 'Administrador Cadastra Gerente!';
}else{
throw new Exception('Falha ao cadastrar Gerente!');
}
}
}Lembrando que só estou tentando entender interfaces, e aproveitando, gostaria de outras visões de implementação desta situação acima, gostaria que alguém me explicasse como funciona o namespace, li varios tutoriais e não consegui implementar neste modelo, obrigado.
Explica melhor o princípio da responsabilidade única e namespace, obrigado pela atenção.
Pra falar a verdade, não vi violação de srp hora nenhuma.....
<?php
class gerente extends funcionario
{
public function __construct() {}
public function cadastrar($objeto) {
if (get_class($objeto) === 'funcionario') {
echo 'Gerente Cadastra Funcionario!';
}else{
throw new Exception('Falha ao cadastrar funcionario!');
}
}
}<?php
class gerente extends funcionario //Use nomes de class em uppercamelcase
{
public function __construct() {}
public function cadastrar(Funcionario $funcionario) {
///...blablabla
}
}abstract class User{
protected $name;
public function __construct($name) {
$this->name = $nome;
}
abstract function login();
abstract function logon();
}Pra falar a verdade, não vi violação de srp hora nenhuma.....
Não apenas SRP, mas também DIP, as classes não devem depender se concreções no sentido geral, apenas de abstrações no sentido geral.
Explica melhor o princípio da responsabilidade única e namespace, obrigado pela atenção.
O correto é que você planeje a classe em todos os aspectos, desde o ponto de vista do design até qual será o papel que unicamente ela vai exercer e lembrando que design de classe não é o modo como você escreve "desenha o texto".
Espaço de nomes (NAMESPACE), é basicamente prefixar um nome, o NS vai ser agora um container para o conteúdo ( NS\YourClass, NS\Registry\Observe ), seu uso é opcional.
Eu gosto de pensar seguindo o conjunto de diretórios, afinal a organização de suas classes é crucial:
Imagina que você tenha o seguinte sistema de path de diretórios:
Aplication/View/
Os NameSpaces seguindo o estilo "NS Diretory Path" para o exemplo acima são:
Aplication/View/AbstractInputController.php
//AbstractInputController.php
/**
* O PHP vai dispor todo o conteúdo dentro de
Aplication\View
{
[...]
}*/
namespace Aplication\View;
abstract class AbstractInputController
{
//[...]
}
Pessoal, muito obrigado pelas respostas, mas acho que vou fazer o seguinte, vou reabrir este tópico com um novo título, como modelagem e desenvolvimento, para desenvolvermos este modelo descrito do início, porque aí podemos ir seguindo passo a passo e vocês me orientando sobre o que fazer, como e onde conseguir material de estudo, o que acham.
Por favor administradores, fechem o tópico, obrigado.
Primeiro: Não precisa usar estas nomenclaturas, ex: "iUser", você quiz abreviar "Interface+User", mas já é uma "interface" então não precisa dizer isto na nomenclatura, aconselho usar "NameSpaces".
O design da interface não está ruim, mas o que se ver em seguida são suas classes violando o "Princípio da Responsabilidade Única" ou SRP.
Você precisa abstrair e pensar em seu código para a administração de funcionários e não apenas ações isoladas.
Eu tentei criar um exemplo abaixo que deve lhe dar uma melhor noção sobre abstração
abstract class Manager implements \Countable
{
/**
* Aplicando:
WorkerInformation.php
*/
class WorkerInformation extends Manager
{
Em "Manager" são "ações estáticas", ou seja, elas precisam apenas de um controlador, por isso eu implementei tudo.
O responsável por ler os dados dos funcionários foi abstraído, assim você pode usar qualquer programa externo, neste exemplo "RH\Adapter\WorkerManager" é o responsável.