Очередной тупой вопрос ООП PHP MVC - помогите.

[AnrDaemon]

"Интерфейс" - это технический контракт, на который может ссылаться объект-клиент при работе с объектом-провайдером.

interface IProvider {
  public function provide(string $filter = null);
}

class Client {
  public function __construct(IProvider $provider)
  {
    print $provider->provide();
  }
}

class Service implements IProvider {
  protected static $stuff = 'I has stuff.';
  public function provide(string $filter = null)
  {
    return self::$stuff;
  }
}

class Liar implements IProvider {
}

$deal = new Client(new Service());
$cheat = new Client(new Liar());

 

[С.]

Bbldlo_Coder, ООП это одно. MVS -- это совершенно другое, к тому же с очень размытыми определениями, понимаемые многими по-разному. Если ты будешь постигать это одновременно, то тебе гарантирована бесконечная каша в голове, да еще и присыпанная сверху ajax`ом. Заимись сначала чем-то одним, в любом порядке.

 

[grigori]

в нашем гнезде радость - птенцам принесли новую игрушку

 

[Bbldlo_Coder]

Bbldlo_Coder, ООП это одно. MVS -- это совершенно другое, к тому же с очень размытыми определениями, понимаемые многими по-разному. Если ты будешь постигать это одновременно, то тебе гарантирована бесконечная каша в голове, да еще и присыпанная сверху ajax`ом. Заимись сначала чем-то одним, в любом порядке.

То что разные это понятно. Идею MVC как-то понимаю, теперь надо ООП освоить получше, видимо особой магии то и нет... пойду играться дальше.

Так мне и не понятно, как мне реализовать некий класс, который сможет распределять задания между пользователями. Причем реализация этих двух классов (пользователи и задания) мне не известна. Пусть даже мой класс по одному заданию распределяет.. надо же кто-то передать ему данные о всех юзерах и об их умениях. Как это сделать через два массива, в один цикл и одной функцией я знаю. Но как манипулировать объектами, даже N-количеством объектов я не понимаю... как задания распределить - мне не понятно. Возможно объект задние должно иметь метод выбора пользователя, но данные пользователей тоже надо получить как-то.... не понимаю пока как.

 

[AnrDaemon]

Тебе не надо писать класс, который распределяет задания между пользователями.
Посмотри внимательно пример, который тебе привели. (Впрочем, в примере есть ошибка. Бонусные очки, если ты её найдёшь.)

 

[С.]

Идею MVC как-то понимаю,

Вот именно, что ""как-то"

теперь надо ООП освоить получше,
Так мне и не понятно, как мне реализовать некий класс, который сможет распределять задания между пользователями.
Но как манипулировать объектами, даже N-количеством объектов я не понимаю... как задания распределить - мне не понятно.

Все твои непонятки ни малейшего отношения к ООП не имеют (как впрочем и к MVC). Это вопрос алгоритмизации данной конкретной задачи.

Боюсь, что каша уже имеет место быть.

 

[Bbldlo_Coder]

Если пример от AmdY, то я его вообщем понял... Ошибку я там долго буду искать, так как синтаксическую я не замечу (не писал я в стиле ООП), а логическую вообще не найду так как мыслю я переменными, массивами и константами. И Как выясняется проблема у меня с логикой.

Вообще в краце, я понял так, что есть метод addTask() у объекта User, который проверит есть ли навык у этого пользователя, и если очередь не больше некого максимума то задание привяжется к пользователю.

Хотелось сделать несколько иначе, чтобы задание присваивалось пользователю с самой короткой очередью. Но допустим таких пользователей 10 из них надо выбрать того кто имеет меньше всего навыков. Суть в том, что например задание определенного типа умеют дела только 2 из 30, а значит у них очередь должна быть минимальной. Как до делать это с методом, который есть у объекта типа пользователь я не понимаю. Как ему очередь всех пользователей дать пересмотреть.

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

 

[AnrDaemon]

Если пример от AmdY, то я его вообщем понял... Ошибку я там долго буду искать, так как синтаксическую я не замечу (не писал я в стиле ООП), а логическую вообще не найду так как мыслю я переменными, массивами и константами. И Как выясняется проблема у меня с логикой.

С таким отношением вам не стать программистом. Вообще никем не стать. Так и будете сидеть у стеночки и стонать "я не смогу".

 

[Bbldlo_Coder]

С таким отношением вам не стать программистом. Вообще никем не стать. Так и будете сидеть у стеночки и стонать "я не смогу".

Вот я и пытаюсь разобраться как составить логику используя ООП. и хотелось бы чтобы она не уступала функциональном варианту. Потому, что у меня функция перебирает два массива, один из котрых многомерный. И возвращает одномерный, где ключ это id задания, а значение id пользователя. И делает она это очень быстро... Но проблема в том, что если я хочу доработать эту мою функцию, или несколько. Я могу обернуть это дело в класс,и творить свое "мракобесие"... только через месяц я забуду как оно работает, и чтобы внести изменения придется, все вспоминать. А в ООП можно сделать, а потом унаследовать и дополнить, но видимо заплатишь ты тем, что вот так просто эту задачу не решить (как я понял). Тут алгоритм скажем так, станет больше, и станет более "дубовый". Либо я не понимаю как организовать такой же алгоритм используя нормальные классы (а не мои объединения функций), либо так сделать и правда нельзя.

Откуда вообще "растут ноги", есть некоторое WEB-приложение, которое я использую в своих целях:

- Регистрация сотрудников
- Создание конфигурации устройств (пользователями)
- Вывод описания устройства по конфигурации в PDF
- Учет браков
- Склад (даже с партиями)
- И планируется сделать еще возможность создавать списки - комплектации, которые будут собирать компоненты (а там есть аналоги и разные партии) для плат. Со склада это все вычитается, а устройство изготовленное поступает на склад.
- И собственно распределение задач между сотрудниками осуществляется на разных стадиях, сборка комплектации, пайка, тестирование узла, тестирование объединения узлов, упаковка продукта.
- Еще графики там всякие выводятся, кпд сотрудников и т.д. Да и иногда, кто-то какой-нибудь элемент сломает, много там нюансов... Там даже есть валюты, курсы и компоненты сделанные в России имеют цену в рублях, а зарубежные в $ евро, и все это пересчитывается. Да, и много чего еще там происходит в моем это "мракобесии" (слово в точку - нравится).

Изначально это была "лапша" (надо сказать что склада не было на это стадии), потом разбил на функции, разложил по разным файлам функции используемые для разных операций. Подключаю эти наборы взаимозависимости от того в каком интерфейсе работает пользователь. Например, если распределяются задачи, файл с функциями для работы со складом не подключается.

Как бы сейчас это похоже на несколько отдельных веб-приложений, доступ к которым раздает index.php. Так же в каждом приложении свой роутер. Точка входа только index.php, который раздает доступ к приложениям (остальное само по себе не запускается - die. Вьювер один, "разворачивает" многомерный массив, и строит страницу заполняя данными. Тип тега, его класс, его содержание. Если содержание массив, значит внутри есть еще теги и происходит рекурсия)) Сам массив тоже создается функцией, которая получает только данные и тип страницы, которую надо вывести. Если такого типа страницы нет, то собирается страница на усмотрение алгоритма, но этот алгоритм отдельная функция. Тема сделана на Bootstrap. Вьювер вообщем имеет приложение с ним связанное, которое умеет его настраивать. Парсит папку css и можно создать новые типы страниц используя свои классы CSS - скелеты страниц.

К слову класс, который создает PDF, он вообщем то очень похож на мое объединение функций... Создал объект набил его параметрами, получил PDF документ.

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

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

П.С.

Желание избавить от мракобесия огромное))

 

[AnrDaemon]

Не надо пихать в одну корзинку логику и OOP! Логика - это код. OOP - это инкапсуляция кода.
Когда мне надо посмотреть, что там за херню печатает программа, написанная на сях, я не ору, что не знаю этого языка. Да, не знаю. Но меня учили не только "программировать на языке", меня учили составлять и читать алгоритмы. Базовая программа высшей школы, вхоящая в программу любого ПэТэУ. При всей своей ублюдочности, Си - функциональный язык программирования, и если у автора исходного кода есть хоть капля мозга, код написан на английском. Найти проблемное место поиском строки и почитать вокруг, чтобы примерно представить себе, что там происходит - не самая великая задача.

 

[Вурдалак]

Си - функциональный язык программирования

лол

 

[AnrDaemon]

Вурдалак, я надеюсь, ты в курсе разницы между C и С++ ?

 

[Вурдалак]

Вурдалак, я надеюсь, ты в курсе разницы между C и С++ ?

лол

 

[hell0w0rd]

процедурный, а не функциональный

 

[Bbldlo_Coder]

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

Но вообще задача вполне тривиальная, раздать пользователем задания в зависимости от параметров всех пользователей - кандидатов на получение. Тот код, который мне привели в пример, позволяет дать пользователю (одному) задание, если тот готов принять задание - примет, а нет - пошлет. А это как бы не совсем то... А вот как перебрать параметры всех кандидатов, используя объекты, а не массив я не понимаю.

Пусть даже это решение будет там в два экрана, а не в три строки... мне надо понять как это должно выглядеть..

Ты говоришь об ООП и MVC, а оперируешь массивами. Переведи это на нормальный язык.

// есть пользователи, у пользователей есть скилы.
// у пользователей есть задачи.
class Task {}
class Skill {}
class User {
    public function getTasks() {
        // выбираем откуда-то задачи
    }
    public function getSkills() {
        // выбираем откуда-то задачи
    }
    // теперь проверим может ли пользователь взять задачу.
    // он должен обладать нужным скилом и быть свободным
    public function addTask(Task $task) {
        if ($this->getSkills()->contains( $task->getSkill() )) {
           thow new Exception('Пользователь не обладает нужным скилом');
       }
       if ($this->getTasks()->count() > User::MAX_TASKS) {
           thow new Exception('Пользователь не может брать задач больше ' . User::MAX_TASKS);
       }
       $this->getTasks()->add($task);
       return $this;
    }
}

У тебя всё разбито на сущности, каждая из которой оперерует своей логикой, если нужна логика другого объекта передаёшь этот объект в качестве параметра. Это смысл MVC - независимые компоненты занимающиеся своей работой и взаимодействующие между собой, а не всякое мракобесие типо вид-модель-контроллер-база данных-шаблонизатор.....

У тебя всё разбито на сущности, каждая из которой оперирует своей логикой, если нужна логика другого объекта передаёшь этот объект в качестве параметра. - вот я думаю над этой фразой... Это мне выходит надо взять и передать куда-то N-ое количество объектов класса User. Как мне их передать? И как перебрать параметры самих объектов типа User? И где я их перебираю (в методе какого класса)?

 

[AnrDaemon]

процедурный, а не функциональный

Ы. *ушёл биться головой об стенку*

С есть структуры, что вообщем и есть объекты.
У тебя всё разбито на сущности, каждая из которой оперирует своей логикой, если нужна логика другого объекта передаёшь этот объект в качестве параметра. - вот я думаю над этой фразой... Это мне выходит надо взять и передать куда-то N-ое количество объектов класса User. Как мне их передать? И как перебрать параметры самих объектов типа User? И где я их перебираю (в методе какого класса)?

Ты вопросы неправильные задаёшь. Как только ты будешь знать, откуда у тебя берётся "энное количество", вопрос "как передать" решится сам собой.

 

[Bbldlo_Coder]

Ы. *ушёл биться головой об стенку*

Ты вопросы неправильные задаёшь. Как только ты будешь знать, откуда у тебя берётся "энное количество", вопрос "как передать" решится сам собой.

Конкретно у меня N-ое количество пользователей, это те пользователи которые сегодня на работе, и не ушли обедать например. (Ну положим на обед, это не суть важно, пусть будут те которые он-лайн в системе). Далее, когда задание переходит из одного состояния в другое (Вася собрал комплектацию), при смене состояния надо выбрать "жертву" из списка пользователей, кто может осуществить следующую операцию. Тут я как бы начинаю догадываться, что мой алгоритм это метод объекта TASK, мне так кажется. Вот этот метод у меня должен перебирать параметры N-ого количества объектов типа User, и определить на кого это задание повесить.

 

[AnrDaemon]

Ещё раз. Медленно.
Объекты - это не сферические кони в вакууме.
Это законченные и самодостаточные куски логики, имеющие чёткие входные и выходные данные, объединённые с некоторым внутренним хранилищем данных в единое функциональное целое. Ключевое слово - функциональное.
Если ты не понимаешь, как присобачить какую-то логику к какому-то объекту, скорее всего, эта логика никакого отношения к этому объекту не имеет и не должна быть к нему присобачена.
Поиск свободного исполнителя - это не задача задачи. И не задача исполнителя. Это задача проект менеджера или тим лидера. Т.е отдельного объекта-роутера, если это вообще должен быть объект. Вовсе не факт, что должен. Не надо считать объекты панацеей на все случаи жизни и пихать во все щели, как шпаклёвку.

 

[Bbldlo_Coder]

Ещё раз. Медленно.
Объекты - это не сферические кони в вакууме.
Это законченные и самодостаточные куски логики, имеющие чёткие входные и выходные данные, объединённые с некоторым внутренним хранилищем данных в единое функциональное целое. Ключевое слово - функциональное.
Если ты не понимаешь, как присобачить какую-то логику к какому-то объекту, скорее всего, эта логика никакого отношения к этому объекту не имеет и не должна быть к нему присобачена.
Поиск свободного исполнителя - это не задача задачи. И не задача исполнителя. Это задача проект менеджера или тим лидера. Т.е отдельного объекта-роутера, если это вообще должен быть объект. Вовсе не факт, что должен. Не надо считать объекты панацеей на все случаи жизни и пихать во все щели, как шпаклёвку.

Понятно, не имея какого-то механизма перебирать параметры объектов так делать не стоит. Пытаюсь разобраться, как без "костылей" - правильно оперировать с объектами и их параметрами.

 

[AnrDaemon]

Правильно - ими оперировать. Какие костыли вы имеете в виду?