Что здесь не правильно с точки зрения ООП

@maruo · Регистрация: 26.04.2013

Студворк — интернет-сервис помощи студентам

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

Я большую часть своих классов пишу с использование private\public - static
Часто использую статические методы.На сколько это дурной подход??

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

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
class VKoAuth {
 
        private $appID;
 
        private $secret_key;
        
        private $redirect_uri;
 
        private $url_acess_token;
 
        private static $url_auth;
 
        private $access_token;
 
        public function __construct($appID,$secret_key,$redirect_uri = 'index.php',$url_auth = 'https://oauth.vk.com/authorize'){
            $this->$appID           = $appID;
            $this->$secret_key      = $secret_key;
            $this->$redirect_uri    = $redirect_uri;
            self::$url_auth     = $url_auth;
        }
 
        public static function auth($access='offline',$response_type = 'code'){
            echo self::$url_auth;
            // $url = $this->url_auth.'?client_id='.$this->appID
            //                    .'&scope='.$access
            //                    .'&redirect_uri='.$this->redirect_uri
            //                    .'&response_type='.$response_type;
            // return $url;
        }
 
    }

Добавлено через 41 минуту
А не я немного ошибся, у меня тут public static function auth статический метод, поэтому я не мог использовать то что в комментариях.
Но все равно , хочу услышать на сколько это неверно

@maruo · 08.09.2016, 03:16 **[ТС]**

Para bellum, ну я так понимаю это исключительно для коллективного "Кодинга"?

@Para bellum · 08.09.2016, 06:47

Да нет. Для одного разработчика тоже. Можно сказать: "а зачем мне это нужно, если я и так знаю, что туда передавать". Но люди не машины, чтобы помнить весь код и его тонкости.
Уточнение типа поможет не ошибиться.

@Gcom · 08.09.2016, 06:58

Para bellum, да там не сколько из-за "помнить" код, все таки намного важнее что не устанавливается зависимость, приведу цитату из той статьи:

Наиболее эффективный подход, при создании сложных приложений — это создание отдельных частей, на которые можно опираться в дальнейшем. Частей, о которых можно перестать думать, в которых можно быть уверенным. Например, при вызове статического Database::fetchAll(...), нет никаких гарантий, что соединение с БД уже установлено или будет установлено.

PHP
1
2
3
function (Database $database) {
   ...
}

Если код внутри этой функции будет выполнен — это значит, что экземпляр Database был успешно передан, что значит, что экземпляр объекта Database был успешно создан. Если класс Database спроектирован верно, то можно быть уверенным, что наличие экземпляра этого класса означает возможность выполнять запросы к БД. Если экземпляра класса не будет, то тело функции не будет выполнено. Это значит, что функция не должна заботиться о состоянии БД, класс Database это сделает сам. Такой подход позволяет забыть о зависимостях и сконцентрироваться на решении задач.

Без возможности не думать о зависимостях и зависимостях этих зависимостей, практически невозможно написать хоть сколь-нибудь сложное приложение. Database может быть маленьким классом-оберткой или гигантским многослойным монстром с кучей зависимостей, он может начаться как маленькая обертка и мутировать в гигантского монстра со временем, Вы можете унаследовать класс Database и передать в функцию потомок, это все не важно для Вашей function (Database $database), до тех пор пока, публичный интерфейс Database не изменяется. Если Ваши классы правильно отделены от остальных частей приложения с помощью внедрения зависимостей, Вы можете тестировать каждый из них, используя заглушки вместо их зависимостей. Когда Вы протестировали класс достаточно, чтобы убедиться, что он работает как надо, Вы можете выкинуть лишнее из головы, просто зная, что для работы с БД нужно использовать экземпляр Database.

Однозначно, нужно всегда делать такие "привязки".

@Para bellum · 08.09.2016, 07:10

Сообщение от Gcom

все таки намного важнее что не устанавливается зависимость

Что значит не устанавливается зависимость?

Сообщение от Gcom

о которых можно перестать думать, в которых можно быть уверенным

Про это и говорил. Что при уточнении типа мы уверены, что работаем с нужным объектом.

@Gcom · 08.09.2016, 07:17

Сообщение от Para bellum

Что значит не устанавливается зависимость?

Не так выразился, ну это значит, что нам не важно как будет "создан" входящий объект, главное что бы он был (типа соответствовал нужному типу).

@Madrid · 06.10.2016, 02:05

Статика доступна без создания экземпляра объекта.
Публичная статика доступна из любого места программы.

self:: ссылается на класс, в котором определен метод, из которого вызывают (На самом деле все еще более запутанно

).
static:: ищет класс, в котором вызываемый метод/член определен по цепочке наследования. Это называется позднее статическое связывание.
Если переопределения не было, то в обоих случаях все наследники копошаться друг в друге (через родителя), нужно быть осторожным

Если переопределение было, то static работает с переопределенными свойствами, self будет копошиться не совсем понятно где.
Нужно аккуратней работать со статикой, а то можно выстрелить себе в ногу.

Кмк, стоило бы добавить модификатор для доступа только к текущему классу (вместо static), самому первому определившему (вместо self).
Это выглядит более логично, а не как сейчас

Новые блоги и статьи Все статьи Все блоги /
FSharp: interface of module DevAlt 16.05.2026 Интерфейс модуля F# позволяет управлять доступностью членов, содержащихся в реализации модуля. По-умолчанию все члены модуля доступны: module Foo let x = 10 let boo () = printfn "boo" . . .	Хитросплетение родственных связей пантеона греческих богов. russiannick 14.05.2026 Однооконник, позволяющий узреть и изучить отдельных героев древней Греции. <!DOCTYPE html> <html lang="ru"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible". . .	[golang] Угол между стрелками часов alhaos 12.05.2026 По заданным значениям часа и минуты необходимо определить значение меньшего угла между стрелками аналогового циферблата часов. import "math" func angleClock(hour int, minutes int) float64 { . . .	Debian 13: Установка Lazarus QT5 ВитГо 09.05.2026 Эта инструкция моя компиляция инструкций volvo https:/ / www. cyberforum. ru/ blogs/ 203668/ 10753. html и его же старой инструкции по установке Lazarus с gtk2. . .
Нейросеть на алгоритме "эстафета хвоста" как перспектива. Hrethgir 06.05.2026 На десерт, когда запущу сервер. Статья тут https:/ / habr. com/ ru/ articles/ 1030914/ . Автор я сам, нейросеть только помогает в вопросах которые мне не известны - не знаю людей которые знали-бы. . .	Асинхронный приём данных из COM-порта Argus19 01.05.2026 Асинхронный приём данных из COM-порта Купил на aliexpress термопринтер QR701. Он оказался странным. Поключил к Arduino Nano. Был очень удивлён. Наотрез отказывается печатать русские буквы. Чтобы. . .	попытка написать игровой сервер на C++ pyirrlicht 29.04.2026 попытка написать игровой сервер на плюсах с открытым бесконечным миром. возможно получится прикрутить интерпретатор питон для кастомизации игровой логики. что есть на текущий момент:. . .	Контроль уникальности выбранного документа-основания при изменении реквизита Maks 28.04.2026 Алгоритм из решения ниже разработан на примере нетипового документа "ЗаявкаНаРемонтСпецтехники", разработанного в КА2. Задача: уведомлять пользователя, если указанная заявка (документ-основание). . .

@maruo 133 / 133 / 48 Регистрация: 26.04.2013 Сообщений: 1,356
	08.09.2016, 03:16 [ТС]
	Para bellum, ну я так понимаю это исключительно для коллективного "Кодинга"? 0

@Para bellum 5755 / 4134 / 1508 Регистрация: 06.01.2011 Сообщений: 11,276
	08.09.2016, 06:47
	Да нет. Для одного разработчика тоже. Можно сказать: "а зачем мне это нужно, если я и так знаю, что туда передавать". Но люди не машины, чтобы помнить весь код и его тонкости. Уточнение типа поможет не ошибиться. 0

@Madrid 14 / 50 / 3 Регистрация: 26.12.2009 Сообщений: 406
	06.10.2016, 02:05
	Статика доступна без создания экземпляра объекта. Публичная статика доступна из любого места программы. self:: ссылается на класс, в котором определен метод, из которого вызывают (На самом деле все еще более запутанно ). static:: ищет класс, в котором вызываемый метод/член определен по цепочке наследования. Это называется позднее статическое связывание. Если переопределения не было, то в обоих случаях все наследники копошаться друг в друге (через родителя), нужно быть осторожным Если переопределение было, то static работает с переопределенными свойствами, self будет копошиться не совсем понятно где. Нужно аккуратней работать со статикой, а то можно выстрелить себе в ногу. Кмк, стоило бы добавить модификатор для доступа только к текущему классу (вместо static), самому первому определившему (вместо self). Это выглядит более логично, а не как сейчас 0

Опции темы