Разбор ООП с Delphinum

# ramzes (20.01.2017 / 21:32)
в пхар хотя бы утечку памяти то пофиксили? че то я как то забыл поинтересоваться

От версии РНР зависит.

# Koenig (20.01.2017 / 21:27)
Delphinum, я имел ввиду что между модулями могут быть тоже зависимости, то есть response ожидает request определённый, а то что модуль несёт в себе свой интерфейс, то оно не факт что совместимо

я думаю нам стоит определить, что есть модуль, а что пакет ) это разные вещи

# Delphinum (20.01.2017 / 21:35)
я думаю нам стоит определить, что есть модуль, а что пакет ) это разные вещи

Логично
---
Лично я модулем считаю набор бизнес-логики, объединенный по общей цели, к примеру Форум, или Блоги. Там может быть куча файлов, классов и т.п., но все они объединены в свои тематические модули.

Пакет - это то, что раньше называли "библиотека", но библа это обычно (раньше) был 1 класс, иногда очень громадный, (пример upload.class что применяется у нас).
Пакет, это... ну проще гляньте в репозиторий Зенда: https://github.com/zendframewo ... nents Там ссылки ведут именно на пакеты.
Я себе их именно так и представляю.
Пакеты - это ядро системы (фреймворк), которыми могут пользоваться модули.

AlkatraZ, интересно что ты думаешь об этом http://rukeba.com/by-the-way/e ... ects/

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

# Jahak (20.01.2017 / 21:43)
AlkatraZ, интересно что ты думаешь об этом http://rukeba.com/by-the-way/e ... ects/

Не, я как и Delphinium предпочитаю Зендовские стандарты оформления кода + PSR
Этому и следую.
Уже давно все описано.

AlkatraZ, ну я делю код на:
1. Класс
2. Пакет
3. Модуль
4. Приложение
Каждый последующий пункт больше предыдущего.

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

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

Приложение же это система, нацеленная на решение конкретных бизнес-задач.

# Jahak (20.01.2017 / 21:43)
AlkatraZ, интересно что ты думаешь об этом http://rukeba.com/by-the-way/e ... ects/

Теоретически, и Зендовские и PSR инструкции - это просто рекомендации.
Да, авторитетные, но тебя не заставляют им следовать. У отдельной компании, или проекта вполне могут быть свои требования к оформлению кода.
===
Просто на сегодня хорошим тоном считается Zend + PSR

Окей, ну мне понравился его подход

# Delphinum (20.01.2017 / 21:47)
AlkatraZ, ну я делю код на:
1. Класс
2. Пакет
3. Модуль
4. Приложение
Каждый последующий пункт больше предыдущего.

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

Я такое понятие как "модуль" в ядре системы (фреймворке) вообще не приемлю.
Ты наверно раньше работал с Симфонией, у тебя похожая на их интерпретация.