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

@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).
Это выглядит более логично, а не как сейчас

Новые блоги и статьи Все статьи Все блоги /
Контроль уникальности строк в табличной части документа Maks 18.06.2026 Алгоритм из решения ниже разработан на примере нетипового документа "ПланированиеСпецтехники" с табличной частью "НаличиеОборудования", разработанного в КА2. Задача: контроль уникальности строк в. . .	Клиент Uhbif79 18.06.2026 Здесь простой клиент для работы с сервером.	Сервер Uhbif79 18.06.2026 Выкладываю простейший сервер.	Дефенестрация kumehtar 18.06.2026 Узнал интересное слово. Дефенестрация. Это когда ты выбрасываешь кого-либо или что-либо из окна. Возьму на вооружение)))
Дихотомия добра и зла kumehtar 18.06.2026 Как Дзен-буддисты говорят о добре и зле: не нужно воевать против зла, нужно воевать против невежества. Тогда добро станет ествественным, и поэтому вечным. Но дело в том, что невежество всё время. . .	Своя Интернет-Компания iceja 18.06.2026 Я программист с экономическим образованием, пишу свой проект, это SaaS для бизнесов. Мне нужен co-founder с высшим экономическим образованием, и/ или инвестор. Сейчас проект в интенсивной разработке,. . .	24 Мат модель здравосохранения: функциональные требования к строительству пищеблока anaschu 18.06.2026 СРесурсами1: финансовый SD-контур, калькулятор функциональных требований пищеблока Сегодня разделили затраты в агенте Экономика по образцу модели НАСОСЫ, добавили расчёт ROI и построили первый. . .	23. что сделано за последнее время. anaschu 17.06.2026 • Эталон: Клиника НИИ питания РАМН, Москва — централизованный пищеблок, 225 коек, 180 пациентов • Git: репозиторий med2, ветка абсентеизм. Рабочий файл: СРесурсами1_v4. alp • Смежный проект:. . .

@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