ООП (складно, тому що ДужеБагатоВаріантів)

[gdekjifgb]

Забуваєм все (але не все) що написано вище. Вирішив що поки що буде клас (поняття, абстрація) що буде давати відповідь на питання "чи може користувач виконати щось?"


"Проблеми" пов'язані з ПараметрамиДоступу я обрав не випадково. Обрав для того щоб все написання було якось логічно пов'язано. На попередні питання, проблеми конкретної чіткої відповіді не отримав. Мабуть тому що конкретної чіткої відповіді тут не може бути. Та і запитував я трішки взагалі-по-загалях. Та і вникати в суть написаного ніхто не хоче.


Пишемо далі.
Спочатку опис предпроблеми:

ПараметрДоступу для перегляду
1 - пост можуть переглядати всі користувачі. І залогінені, і не залогінені.
2 - пост можуть переглядати тільки друзі користувача, користувач повинен бути залогінений
3 - пост може переглядати тільки автор поста, користувач повинен бути залогінений.

Як у мене в процедур-функц стилі (точно не пам'ятаю, дивитись в код не хочу):
Іде перевірка і залогіненості, і переметрів доступу, і статусу дружби.
Якщо ..., то показати пост, або вивести "пост тільки для друзів", або "автор обмежв доступ до поста".
Все це типу спагетті-коду, тому що багато перевірок підряд.


ПИТАННЯ: Якщо згідно наукових рекомендацій стосовно ООП, потрібно розділяти вся і все на найменші складові, то...
Чи потрібно окремо реалізовувати методи для перегляду поста з ПараметромДоступу 1, 2, і 3 (showOpenPost, showFrendPost, showAvtorPost)?
---
Тут я запитую тільки про Пост, але цей підхід буде застосовуватись і до Фото, і до Фотоальбому, та інш.

[gdekjifgb]

"всьо чухня"

А як бути при створенні поста/фотоальбому??? Доведться самому набивати шишки. Здається що все це вирішується створенням окремого класу AccessParam - так як я з самого початку думав.

[ysenko]

Забуваєм все (але не все) що написано вище. Вирішив що поки що буде клас (поняття, абстрація) що буде давати відповідь на питання "чи може користувач виконати щось?"


"Проблеми" пов'язані з ПараметрамиДоступу я обрав не випадково. Обрав для того щоб все написання було якось логічно пов'язано. На попередні питання, проблеми конкретної чіткої відповіді не отримав. Мабуть тому що конкретної чіткої відповіді тут не може бути. Та і запитував я трішки взагалі-по-загалях. Та і вникати в суть написаного ніхто не хоче.


Пишемо далі.
Спочатку опис предпроблеми:

ПараметрДоступу для перегляду
1 - пост можуть переглядати всі користувачі. І залогінені, і не залогінені.
2 - пост можуть переглядати тільки друзі користувача, користувач повинен бути залогінений
3 - пост може переглядати тільки автор поста, користувач повинен бути залогінений.

Як у мене в процедур-функц стилі (точно не пам'ятаю, дивитись в код не хочу):
Іде перевірка і залогіненості, і переметрів доступу, і статусу дружби.
Якщо ..., то показати пост, або вивести "пост тільки для друзів", або "автор обмежв доступ до поста".
Все це типу спагетті-коду, тому що багато перевірок підряд.


ПИТАННЯ: Якщо згідно наукових рекомендацій стосовно ООП, потрібно розділяти вся і все на найменші складові, то...
Чи потрібно окремо реалізовувати методи для перегляду поста з ПараметромДоступу 1, 2, і 3 (showOpenPost, showFrendPost, showAvtorPost)?
---
Тут я запитую тільки про Пост, але цей підхід буде застосовуватись і до Фото, і до Фотоальбому, та інш.

Ще раз - чому пост має знати щось про доступ до себе (чому у нього мають бути будь які методи show...())? Пост це пост і він як сутність нічого не знає про параметри доступу і різні способи відображення. Якщо спростити, то має бути якась сутність (наприклад клас, функція) яка дасть відповідь на запитання isAuthorized(action, user, entity) -> bool. Де action це дія, яку намагається виконати користувач (наприклад VIEW, EDID, DELETE, CREATE, і так далі), user - це користувач який намагається виконати дію, entity - це сутність, над якою намагаються виконати дію (наприклад екземпляр поста, фото, і т.д).

[gdekjifgb]

Пишемо далі.
Спочатку опис предпроблеми:

ПараметрДоступу для перегляду
1 - пост можуть переглядати всі користувачі. І залогінені, і не залогінені.
2 - пост можуть переглядати тільки друзі користувача, користувач повинен бути залогінений
3 - пост може переглядати тільки автор поста, користувач повинен бути залогінений.

Як у мене в процедур-функц стилі (точно не пам'ятаю, дивитись в код не хочу):
Іде перевірка і залогіненості, і переметрів доступу, і статусу дружби.
Якщо ..., то показати пост, або вивести "пост тільки для друзів", або "автор обмежв доступ до поста".
...


ПИТАННЯ: Якщо згідно наукових рекомендацій стосовно ООП, потрібно розділяти вся і все на найменші складові, то...
Чи потрібно окремо реалізовувати методи для перегляду поста з ПараметромДоступу 1, 2, і 3 (showOpenPost, showFrendPost, showAvtorPost)?
---
...

... Якщо спростити, то має бути якась сутність (наприклад клас, функція) яка дасть відповідь на запитання isAuthorized(action, user, entity) -> bool. Де action це дія, яку намагається виконати користувач (наприклад VIEW, EDID, DELETE, CREATE, і так далі), user - це користувач який намагається виконати дію, entity - це сутність, над якою намагаються виконати дію (наприклад екземпляр поста, фото, і т.д).

Ще раз - чому пост має знати щось про доступ до себе (чому у нього мають бути будь які методи show...())? Пост це пост і він як сутність нічого не знає про параметри доступу і різні способи відображення.

Трішки не так зрозуміли. І тут я далі зв'язно(?) описую наступне. КОРИСТУВАЧ переглядає  пост.

Користувач може бути:

- незалогінений

- залогінений, але не друг
- залогінений друг
- автор поста
Якщо користувач не залогінений, то він може переглянути тільки відкритий пост ViewOpenPost (парамДоступу =1),

якщо друзі ViewFrendPost (парамДоступу =2),
автор поста ViewAvtorPost, (парамДоступу =3)

Я запитував (запитую) чи потрібно код розділяти на такі складові частини. Повторюсь: КОРИСТУВАЧ матиме такі методи. А сам КОРИСТУВАЧ може бути незалогін, залогін, друг, автор.


Думаю що потрібно розділяти це. У мене в проц-функц стилі це все в купі оброблюється.

---
Питання: Чому пост не може себе показувати? Якщо пост переглядає незалогінений Користувач, то пост звертатється до свого метода showOpenPost, якщо пост переглядає Автор поста, то пост звертається до СВОГО метода showAvtorPost... (не плутайте show... та view...)

Про абстракції що повинні відповідати реаліям - я знаю.

Все це так цікаво і складно  .
Знову я передумав. Мабуть все-таки дотримаюсь ваших рекомендацій. Буде окремий клас UserAvtorize.
---
Чому я виділяв роботу з параметрами доступу в окремий клас AccessParam? Тому що "наукові методи в розумних книгах" рекомендують розділяти все на найменші складові. І до того ж в цьому класі є перевірка ПараметрівДоступу при запису в базу даних. Але над цим також іще необхідно подумати - можливо зробити окремий клас для перевіруи $_POST масиву(?) або по іншому щось сотворити.
Дякую за намагання роз'яснити, для мене це дуже важливо і цікаво.


Коли дійду до цієї частини (коли буду переписувати цю частину коду), то покажу як воно у мене буде реалізовано. Ви ж нікуди не збираєтесь зникати?

бл.кі, бб-кодЄ. При відправці повідомлення текст (форматування тексту) псується!

[gdekjifgb]

Off-topic:

Відключаюсь від інтернетів і займаюсь кодуванням. Погода мокра - нема ніякого інтернету. Навіщо так з себе знущатись?Коли інтернети є, займась не тим чим потрібно.

Чому ніхто з вас не вказав/не сказав/не написав про необхідність вивчання патернів? Я і їх підучую.

[vbnnm]

Все чудово, розібрався (питань і варіантів стало іще більше), але переписувати не хочу , Лінь заважає.

[BeSiDa]

Чому я виділяв роботу з параметрами доступу в окремий клас AccessParam? Тому що "наукові методи в розумних книгах" рекомендують розділяти все на найменші складові. І до того ж в цьому класі є перевірка ПараметрівДоступу при запису в базу даних. Але над цим також іще необхідно подумати - можливо зробити окремий клас для перевіруи $_POST масиву(?) або по іншому щось сотворити.
Дякую за намагання роз'яснити, для мене це дуже важливо і цікаво.

Правильно обирати абстракції - відповідно до домену задачі

Чому ніхто з вас не вказав/не сказав/не написав про необхідність вивчання патернів? Я і їх підучую.

Хоч тема й стара, але її можуть ще читати, кому цікаво що то таке ООП взагалі.
Все, про що тут написали, то лише одна частина розуміння ООП.
Існує зовсім інша (доповнення до загального сприйняття ООП).
Інша не має нічого спільного ні з доменами (наприклад, "веб застосунок" чи "форум"), ні з тематикою застосування (наприклад, визначенням того що є "пост", "права доступа", "дія", "особа" та ін), ні з паттернами (це фактично "метапрограмування", коли з однієї мови програмування виліплюють іншу, яка не була відтворена в головній частині самої мови).
Вся плутанина зі словом типізація, яке має два одночасні та протилежні значення, це технічний тип реалізації (для копьютера, наприклад int, unsigned int, pointer) чи змістовний тип реалізації (для людини, наприклад, X та Y за змістом різні типи, а от технічно обидва одночасно можуть маюти тип int).
Так само є два паралельні та одночасні ООП 1) технічний, 2) змістовний.
І от про перший майже ніхто не пише (то можуть бути ієрархії технічних типів от як String, Number, Vector, Matrix).
От саме задля першого й був створений ООП, а все інше то потім повидумували, тому його й складніше зрозуміти.

А наслідування технічних типів потрібно задля "виділення підмножини". Наприклад, є множина "число" з неї виділяють меншу множину "число >=0", з неї ще менше "парне число >=0" і ще менше "парне >=0 та <1000".
Дуже простий приклад. Є й складніші з матрицями чи графами та різними варіантами зберігання в структурах пам'яті (пакуавання та серіалізації між архітектурами процесорів).

А приєднання до того "методів" то ще більша "пастка" (особливо щодо серіалізації та пересилання між різними мовами програмування).

Та до дого ж є ООП яке "існує тільки до моменту компіляції" (після того бінарно його немає), чи весь час (будь який об'єкт можна не тільки "створити" але й "модифікувати" його склад (списки властивостей та іншого). І це теж зовсім інше ООП.

А от "ООП як мова взаємодії команди людей" (кому "можна" та кому "не можна" та що саме чіпати в загальному коді проекту) то взагалі не ООП. Хоча дехто так і вважає, бо вибрав саме цей технічний засіб задля того щоб когось примусити щось робити чи не робити.