Правильное использование интерфейсов

[esase]

Это значит - класса нет. Класс - это когда можно и имеет смысл создать его инстанс. В твоем случае $instance = new FileSystem не имеет смысла, соответственно, это не класс, а зачем-то использовано ключевое слово class вместо namespace.

Это во обще интересное утверждение, если класс содержит одни статичные методы то он не класс, паттерн сингелтон тоже запрещает использовать прямое создание объекта т.е вы не сделаете $var = new Test(); - то же видимо не класс. Вопрос риторический. Класс использую вместо глобальных функций для статичных функций даже в контексте неймспесов (различные утилиты) потому, что придерживаюсь ООП стиля.

 

[fixxxer]

В синглтоне есть new. Внутри.

 

[esase]

Модель может много что уметь. Нет никакого смысла в интерфейсе NewsModelInterface, т.к. нам это без разницы. Нам важно, что она _умеет_. В данном случае она умеет отрендерится в TemplateInterface, и это мы у нее и просим. NewsModel::render, в свою очередь, интересует только то, что переданный ему объект умеет сделать assign; его не интересует, будет там html, pdf или картина маслом.

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

 

[Adelf]

интерфейс нужно применять только тогда когда, есть необходимость в нескольких реализациях

Тогда, когда такая необходимость может возникнуть. Ты не совсем уловил суть. Это что-то вроде инкапсуляции. Например в методе renderTo из примера фиксера - там нужно знать только то, что этому обьекту можно методом assign записать несколько значений. Если метод бы точно знал что ему передается, например, SmartyView - это было бы излишней информацией.. которая ему просто не нужна. Такие вещи просто надо научиться чувствовать.

 

[fixxxer]

esase, не совсем так.

Интерфейс нужно применять тогда, когда нам надо знать, что это нечто умеет. Скажем, HtmlTemplate может уметь какой-нибудь addStylesheet() и addJavascript(), но модели это неинтересно - ей все равно, это html-шаблон, или pdf-шаблон, или plain-text шаблон для почтовой рассылки.

Или, скажем, у нас есть сериализатор объектов (например, в json, или там в msgpack). В этом случае NewsModel, например, может реализовать SerializeableInterface с методами exportToArray() и restoreFromArray() - и сериализатор будет интересоваться только наличием этого интерфейса, на все остальное ему по барабану.

В таких случаях сразу понятно, что, если даже у нас есть в данный момент надо сериализовывать только NewsModel, писать сериализатор, который будет принимать только NewsModel, смысла нет никакого.

Смысл в том, чтобы мыслить интерфейсами, помнить о SRP и низкой связанности. Иначе можно в том случае, когда на данный момент надо делать сериализацию только NewsModel, написать говнокод - запихнуть сериализацию внутрь NewsModel, или написать класс, который берет NewsModel и сам из нее достает $newsModel->title и т.д. (Нет, все время от времени по объективным причинам пишут подобный говнокод, но надо понимать, что это - говнокод, и он создает технический долг, который потом придется отдавать).

 

[fixxxer]

Да, важно в подобных моментах забыть, что мы пишем на php. Его динамическая нестрогая типизация позволяет много вольностей - об этом стоит на время забыть при обсуждении теоретических вопросов. Представь себе, что у нас Java или C#.

 

[MiksIr]

Это во обще интересное утверждение, если класс содержит одни статичные методы то он не класс, паттерн сингелтон тоже запрещает использовать прямое создание объекта т.е вы не сделаете $var = new Test(); - то же видимо не класс. Вопрос риторический. Класс использую вместо глобальных функций для статичных функций даже в контексте неймспесов (различные утилиты) потому, что придерживаюсь ООП стиля.

Вы делаете классическую ошибку новичка. Класс в ООП и языковая конструкция "class" в PHP - разные вещи. Равно как интерфейс в ООП и "interface" в PHP. Наличие слова "class" не делает это априори классом. Это не риторический вопрос, это вопрос понимания основ ООП.

 

[esase]

Вы делаете классическую ошибку новичка. Класс в ООП и языковая конструкция "class" в PHP - разные вещи. Равно как интерфейс в ООП и "interface" в PHP. Наличие слова "class" не делает это априори классом. Это не риторический вопрос, это вопрос понимания основ ООП.

что же мне писать чтобы класс стал классом, а интерфейс интерфейсом в php ?
Давайте об этом порассуждаем здесь...

 

[fixxxer]

esase, этот вопрос из разряда "на заборе *** написано, а там дрова". Чтобы класс был классом, он должен быть классом с точки зрения теории объектного дизайна. Ключевое слово class не имеет особого значения - если я в исходном коде php поменяю ключевое слово class на слово "жопа", от этого классы не станут жопой. ООП-код можно писать и на языках, в которых нет понятия класса.

Утрированный пример - возьмем весь код вордпресса с его функциями, и обернем в один большой class Wordpress. И что, это теперь ООП?

С другой стороны, если посмотреть на модули в nginx, то их структура очень похожа на классы, а сами модули - на объекты, хоть в C и нет таких понятий.

 

[esase]

esase, этот вопрос из разряда "на заборе *** написано, а там дрова". Чтобы класс был классом, он должен быть классом с точки зрения теории объектного дизайна. Ключевое слово class не имеет особого значения - если я в исходном коде php поменяю ключевое слово class на слово "жопа", от этого классы не станут жопой. ООП-код можно писать и на языках, в которых нет понятия класса.

Утрированный пример - возьмем весь код вордпресса с его функциями, и обернем в один большой class Wordpress. И что, это теперь ООП?

С другой стороны, если посмотреть на модули в nginx, они очень похожи на классы, хоть в C и нет такого понятия.

1. Насчет вордпреса, да это это будет один большой Бог класс который может инстанироваться и да это будет ООП с точки зрения ООП, почему нет факты?
2. Теперь к вопросу об утилитах (классах которые содержат в себе только статичные методы).

• Да конечно с данного класса не возможно создать экземпляры он по большому используется как хранилище для небольших функций которые не нашли себя в качестве чего то большего. Но почему он не класс? потому, что с него нельзя создать новые экземпляры?
• Удобства данного подхода - 1. не засирается глобальное пространтсво, 2. Данный класс можно подгрузить автолоадером в любой точке приложения (как это сделать кроме как require при использовании этой утилиты в качестве файла с глобальными функциями я хз).
• Утилиты можно групировать в классах по их функциональности соот-но улучшая ориентацию в коде где, что лежит.

 

[Adelf]

Но почему он не класс? потому, что с него нельзя создать новые экземпляры?

Именно так. Это не класс. Это набор функций.

 

[fixxxer]

Теперь к вопросу об утилитах (классах которые содержат в себе только статичные методы).

Это суть неймспейсы. То, что в php ввиду его особенностей удобнее так делать, не делает их классами.

В ООП статические методы нужны для того, чтобы работать с экземплярами того класса, в котором они написаны, в тех случаях, когда $this не применим. Например, тот же синглтон, или factory-методы.

 

[esase]

Это суть неймспейсы. То, что в php ввиду его особенностей удобнее так делать, не делает их классами.

В ООП статические методы нужны для того, чтобы работать с экземплярами того класса, в котором они написаны, в тех случаях, когда $this не применим. Например, тот же синглтон, или factory-методы.

Ребят мне кажется мы говорим немного о разном, дайте вспомнить мне, что такое класс?
Класс - это шаблон описывающий методы и поля будущих порожденных от него объектов. Надеюсь никто спорить не будет.
Объект - эта сущность созданная на основе некоторого класса или классов.

Статические методы принадлежат классу а не объектам.
Отсюда - если класс (не объект) не предоставляет методы и поля для создания объектов это еще не значит что он не класс. А как же абстрактные классы они ведь тоже могут содержать в себе только статические методы, значит он не класс? класс это шаблон, он может быт и пустым в принципе, представим себе некий базовый
класс Class Base {} все, заполним его позже, а может во обще не заполним но он от этого классом не перестанет быть.

PS. Да и никто вам не мешает создать экземпляр из класса Utility/FileSystem, просто на выходе вы получите объект со списком статичных методов.

Приведите мне ссылку плиз на какое нибудь серьезное умо заключение которое бы опровергало напрочь то, что я здесь пишу

 

[esase]

Именно так. Это не класс. Это набор функций.

Любой класс это по сути список методов и полей как не крути

 

[Adelf]

esase, иногда кажется, что ты троллишь.

А как же абстрактные классы они ведь тоже могут содержать в себе только статические методы, значит он не класс?

Абстрактный класс без абстрактных или virtual функций смысла не имеет.

В C# например есть такое понятие как static class. Который как раз как твой FileSystem, может содержать лишь статические методы. И там C# анализатор понимает, что создавать экземпляр такого класса смысла нет.. и наверно даже не даст это сделать.

PS. Да и никто вам не мешает создать экземпляр из класса Utility/FileSystem, просто на выходе вы получите объект со списком статичных методов.

Только это не будет иметь смысла. То, что в PHP ты можешь это сделать не делает FileSystem классом в понимании ООП.
Ты можешь себе представить функцию например: func(FileSystem $system) ? Появится ли такая когда-нибудь в твоем коде?
Да и нет такого понятия "обьект со статическими методами"

 

[esase]

В C# например есть такое понятие как static class. Который как раз как твой FileSystem, может содержать лишь статические методы. И там C# анализатор понимает, что создавать экземпляр такого класса смысла нет.. и наверно даже не даст это сделать.

как эта сущность называется в c# ? класс, объект, функция с функциями?

 

[Adelf]

esase, неважно как оно называется. Важно, чем оно на самом деле является.
В C# static class используются либо как твой FileSystem, либо для создания extension для других классов и интерфейсов. Т.е. это совсем не ООП-шная штука и все это знают и понимают. Благо статический язык позволяет немного ограничить некоторые понятия.

просто на выходе вы получите объект со списком статичных методов.

Я об этом. Методы будут не у обьекта а у его класса. Обьект будет вообще ненужным инстансом непонятно чего.

 

[esase]

неважно как оно называется. Важно, чем оно на самом деле является.

Во обще то важно, вот завтра меня спросят а че это? я скажу не важно Т.е. это совсем не ООП-шная штука и все это знают и понимают, так что оте....сь от меня

 

[hell0w0rd]

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

на мой взгляд самый идиотский подход, который только может быть. У меня дикий батхерт от зенд-кода, написанного в таком стиле, где половина абстрактных классов пустые, про интерфейсы не помню.
На мой взгляд, если на момент написания класса нет, или не планируется никакой абстракции - ее не нужно заранее подготавливать.

 

[Adelf]

esase, ну тебе уже пытались тут обьяснить. Класс это такая штука, от которого создают экземпляры. Представь, что в PHP запретили статические методы, а сказали использовать только функции(тем более, что неймспейсы появились уже...). Тогда картина мира ООП в PHP будет более ясной.