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

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

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Desktop (MinGW): Рисуем цветные прямоугольники с помощью рисовальщика SDL3 на Си и C++ 8Observer8 17.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-rectangles-sdl3-c. zip finish-rectangles-sdl3-cpp. zip	Символические и жёсткие ссылки в Linux. algri14 15.03.2026 Существует два типа ссылок — символические и жёсткие. Ссылка в Linux — это запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая ссылка» (hard link),. . .	[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .	делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью
SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .

@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