ооп доступ к методу private

Boris

Новичок
Добрый день!
Подскажите, пожалуйста, где ошибка.
Код:
interface IUser
{
  function getName();
}
 
class User implements IUser
{
  public function __construct( $id ) { }
 
  public function getName()
  {
    return "Jack";
  }
 
  public function test(){
      return $this->getName();
  }
}
 
class UserFactory
{
  public static function Create( $id )
  {
    return new User( $id );
  }
}
 
$uo = UserFactory::Create( 1 );
echo( $uo->test()."\n" );
данный код выводиn имя Jack
стоит мне изменить право доступа к методу getName на private

Код:
private function getName()
  {
    return "Jack";
  }
как уже ничего не выводится. пробовал в interface также задать private к методу не помогло.
буду рад если кто то объяснит.
Спасибо
 

Boris

Новичок
т.е. получается что создать интерфейс с описанием методов которые должны быть закрыты от внешнего кода не получится, и шаблон с сетером сделать нельзя????
 

ksnk

прохожий
@Boris, интерфейс - это не шаблон объекта. Это ИНТЕРФЕЙС, который обязан реализовать объект, чтобы общаться с другими объектами.
Если нужен шаблон - посмотри в сторону абстрактных классов. Хотя там приватных методов тоже нельзя наследовать, опять же в силу определения слова "приватный" ;)
 

AnrDaemon

Продвинутый новичок
стоит мне изменить право доступа к методу getName на private

Код:
private function getName()
  {
    return "Jack";
  }
как уже ничего не выводится. пробовал в interface также задать private к методу не помогло.
буду рад если кто то объяснит.
Спасибо
Звучит как http://xyproblem.info/
Чего именно вы хотите достичь?
 

antson

Новичок
Партнер клуба
@AnrDaemon,
XY-problem : "Не спрашивай как? Скажи зачем !"
Жемчужины творчества программистов - Бентли Дж.
 

AnrDaemon

Продвинутый новичок
@antson, обрати внимание, что человек изначально задал вопрос об интерфейсе.
 

Astar75

Новичок
private - метод или свойство доступно только внутри класса
protected - метод или свойство доступно как внутри класса, так и в дочерних классах
public - метод или свойство класса доступны везде

выводы делай самостоятельно
 

antson

Новичок
Партнер клуба
@AnrDaemon, это я оффтопил по поводу XY
так ему в первых 2-х ответах дали ссылки на:
1.Интерфейс по определению - ПЕРЕЧЕНЬ ПУБЛИЧНЫХ МЕТОДОВ, КОТОРЫЕ ДОЛЖЕН РЕАЛИЗОВАТЬ КЛАСС
2. И главная ересь с точки ООП в его вопросе
ЖЕЛАНИЕ ИМЕТЬ ПРИВАТНЫЙ ГЕТТЕР

я конечно могу придумать когда такое нужно.
из класса родителя нужно взять значение переопределенное в потомке, но не давать его наружу
По этому создаем класс в котором должен быть
abstract protected
https://stackoverflow.com/questions/7939199/abstract-private-functions
 

AnrDaemon

Продвинутый новичок
Я бы хотел услышать от ТС, зачем ему это пондобилось.
А не ваши догадки на тему, которые только ещё больше ТС запутывают.
 

Boris

Новичок
все очень просто. мне захотелось по пробовать на практике то что прочитал в книге. в интерфейсе есть перечень методов которые должны быть описаны классом который имплементирует данный интерфейс, из теории методы могут быть public protected private исходя из этого я подумал а почкму не создать в интерфейсе заранее такой метод, доступ к которому будет закрыт из вне, тем самым описывая его в классе сразу как бы это оговорить . я читал что у методов трейта например можно изменить права доступа trait::method as private
короче говоря эксперементировал, но или пропустил или был не внимателен читая про интерфейсы..
 

WMix

герр M:)ller
Партнер клуба
в интерфейсе есть перечень методов которые должны быть описаны классом который имплементирует данный интерфейс
смысл не в "которые должны быть описаны", а как взаимодействовать с ними,

вводить интерфейс, чтоб кто-то что-то был должен, не имеет смысла, смысл имеет алгоритм который принимает различные обьекты имеющие единый интерфейс и что-то с ними делает используя знание "как взаимодействовать с ними"

отсюда понятно что смысла в private методе описанного в интерфейсе нет
 

WMix

герр M:)ller
Партнер клуба
нет, это называется полиморфизм, "множественное наследие" это из разряда как посильнее наговнокодить
 

antson

Новичок
Партнер клуба
понятие абстрактного класса больше подойдет, когда, что-то условно различается в потомках, но этого не надо выставлять наружу

Код:
<?php

abstract class Partizan{
    // только для демонстрации
    private $lastZapros;

    // получение потомко зависимых данных нужных для 1 и 2
    abstract protected function _getSecret();
   
    // 1 публичный метод
    public function zapros(){
        $this->lastZapros = rand(1,$this->_getSecret());
        return $this->lastZapros;
    }

    // 2 публичный метод
    public function otklik($x){
        return ($x+$this->lastZapros) == $this->_getSecret();
    }

}

class PartizanA extends Partizan{
    private $secret = 10;
    // дочерний класс должен реализовывать
    protected function _getSecret(){
        return $this->secret;
    }
}

class PartizanB extends Partizan{
    private $secret = 12;
    // дочерний класс должен реализовывать
    protected function _getSecret(){
        return $this->secret;
    }
}
вместо protected может быть private
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
нет, это называется полиморфизм, "множественное наследие" это из разряда как посильнее наговнокодить
дядя Боб с тобой не согласен - он считает, что авторы java просто поленились реализовать множественное наследование, сэкономили на компиляторе, который в 80е выполнялся намного дольше
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@antson, ну и зачем тут абстрактный метод? я ж говорю - защищенного статического поля класса вполне достаточно
 

fixxxer

К.О.
Партнер клуба
прочитал в книге
почкму не создать в интерфейсе заранее такой метод, доступ к которому будет закрыт из вне
Прочитай книгу еще раз и обрати внимание на то, что такое интерфейс. Там должно быть дано определение, если его нет - возьми книгу получше.

Вот есть у тебя розетка на 220 вольт, это интерфейс, можешь туда воткнуть телевизор, принтер или два пальца. Как при этом устроен телевизор, для этого интерфейса не имеет никакого значения. Ровно как не имеет никакого значения, как у тебя организована электропроводка.
 
Сверху