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

[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]

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