Правила     Закладки     Карма    Календарь    Журналы    Помощь    Поиск    PDA    Чат   
        СМС-ки
   
Пейджер выключен!
Страницы: (7) 1 [2] 3 4 ... Последняя » ( Перейти к первому непрочитанному сообщению )  
Фильтр авторов:    показать 
  скрыть
  Ответ в темуСоздание новой темыСоздание опроса

> Очередной холивар по методологиям, Флуд от "биографии" twin'a
Ron  
 ۩  Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 1047
Пользователь №: 41686
На форуме: 1 год, 4 месяца
Карма: 13




Цитата (twin @ 4.04.2016 - 04:07)
Я искренне не понимаю, что за качество поддержки.

Это когда на чтение забытого кода уходит не 10 часов а 10 минут. Хороший уровень абстракции при правильном разделении на слои абстракции. Допустим, использовать в качестве "транспорта" не массив и не список переменных, а объект. Использовать геттеры и сеттеры в нем для записи и чтения нужной информации. Я передал объект из одной подсистемы в другую при этом что одной, что другой подсистеме глубоко начхать что из себя представляет реализация этого класса. Потому что он реализован от интерфейса, через который идет согласование. Это ООП или нет? Я считаю что да. Простенькое, конечно, но уже ООП.

Чуть посложнее это внедрение зависимостей (через полиморфизм). Опять же лучше всего плясать от интерфейса.

Может быть я не прав, но я считаю основной инструмент ООП это не наследование нифига ниразу а полиморфизм. На нем строится большинство паттернов. Задача создать в коде микро API, но более низкого уровня. Эти API и есть интерфейсы по сути-то. Они нас подталкивают к полиморфизму а дальше идет то самое внедрение зависимостей и т.д. паттерны и прочее. Всё. Вот оно ООП, вся его суть, мощь и прелесть.

Нет никаких жестких стандартов, он один: хорошая читаемость и легкая расширяемость.

Некоторые думают, что ООП это попытка разделить на сущности AKA реальный мир. Полная глупость, и близко ничего такого нет. Фишка в инверсии потока вызовов и изоляция вышестоящей архитектуры от деталей реализации подчиненной.



--------------------
Жду 5.11.2017
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15562
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 6 дней
Карма: 299

Трезвый :
5 лет, 11 месяцев, 15 дней


Цитата (Ron @ 4.04.2016 - 01:45)
Я передал объект из одной подсистемы в другую при этом что одной, что другой подсистеме глубоко начхать что из себя представляет реализация этого класса. Потому что он реализован от интерфейса, через который идет согласование.
Вот мой предшественник на этом и попался. Потому что ему было глубоко начхать (с), что из себя представляет реализация класса "user". Он передал его в касс формирования списка анкет и возрадовался. А то, что в итоге плучилось сто запросов - не важно. Важно, что соблюлась инкапсуляция.

Там вообще все было через задницу, не только этот момент. Это можно было еще исправить. Весь код был таким. Как ты говоришь - легко поддерживаемым. Вот только уволиться ему все же пришлось.

А то, что на чтение забытого кода уходит время, так причем тут вообще методология? Любой код можно забыть. И уж тем более плохо, когда не знаешь, да еще забудешь. Я же не просто так спросил. В чем проще разобраться, в иерархии 149 классов, или в 20-30? Когда первый раз видишь код. Или когда забыл.

А когда с этим работаешь ежедневно с утра до вечера, как можно забыть вообще?


--------------------
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
chee  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Сын полка
Сообщений: 1780
Пользователь №: 38654
На форуме: 2 года, 11 месяцев, 6 дней
Карма: 40




twin, программист должен иметь хррошую память, как минимум для того чтобы накапливать опыт. Запоминать все 150 классов не надо, практически 2/3 инфраструктурные.


--------------------
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Мой блог
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Ron  
 ۩  Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 1047
Пользователь №: 41686
На форуме: 1 год, 4 месяца
Карма: 13




Цитата (twin @ 4.04.2016 - 05:56)
А когда с этим работаешь ежедневно с утра до вечера, как можно забыть вообще?

Ну как же, есть понятие "ось изменений". Через некоторые модули системы она проходит очень редко, к примеру. В плохой архитектуре любая ось изменений либо цепляет дофига модулей, либо постоянно проходит через одни и те же независимо от задачи.

Судя по вопросу дела с архитектурой обстоят неочень... Или нет? wink.gif




--------------------
Жду 5.11.2017
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15562
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 6 дней
Карма: 299

Трезвый :
5 лет, 11 месяцев, 15 дней


Цитата (chee @ 4.04.2016 - 06:46)
twin, программист должен иметь хррошую память, как минимум для того чтобы накапливать опыт. Запоминать все 150 классов не надо, практически 2/3 инфраструктурные.

Про память не я сказал. Я как раз говорил о том, в чем проще разобраться, когда видишь код в первый раз. С инфраструктурой тоже нужно разбираться, иначе как же её использовать. А про память понятно и так. Как можно забыть то, с чем постоянно работаешь.

Цитата (Ron @ 4.04.2016 - 06:57)
Ну как же, есть понятие "ось изменений". Через некоторые модули системы она проходит очень редко, к примеру. В плохой архитектуре любая ось изменений либо цепляет дофига модулей, либо постоянно проходит через одни и те же независимо от задачи.
Да, есть. И что? Есть у меня такие классы, которым триста лет в обед, и которые вообще изменять не нужно. Но их мало, это такие классы, которые нужны постоянно и везде.

А то, что ты называешь плохой архитектурой, я не понял. Обоснуй. Просто я часто слышу это определение, но оно обычно сводится к банальному "не как у всех".

Если у меня есть минимальный набор общих классов (ядро), а остальное не зависит друг от друга, это плохая архитектура? Общие, я имею ввиду такие как роутер, класс для СУБД, постраничка, шаблонизатор и так далее. Именно такие, которые вообще не относятся к функциналу, а помогают ему. То, что chee назвал инфраструктурой. Только у меня этого минимум. Реально то, без чего никак.

И нет никакого желания настраивать систему так, чтобы она сама в себе могла разобраться только с помощью 150 классов. Выкинь или сломай один из них и всё. Что жил, то зря.

Если я работаю с несколькими платежными системами к примеру, и у меня нет для них общего абстрактного класса (ну не юзаю я для этого полиморфизм), это значит плохая архитектура?

Я понимаю, для чего это нужно вам. Для того, чтобы поменьше кода было. Но по сути получается больше. И кода, и файлов, и заморочек. Я проще адаптер напишу в пределах модуля, отвечающего за конкретную платежку. Модель выберет тот, какой ей надо. Нужно добавить - просто написал модуль, она сама подхватит. И я буду знать, что никто выше этого модуля не полезет, ломать там всё.

По сути та же абстракция, только нет лишнего слоя. Все просто и прозрачно, не как слоеный пирог.

Вообще, меня тоже частенько подмывает накуралесить разных паттернов и абстракций. Но меня всегда останавливает индейский ритуал "нахуа". smile.gif Зачем 150 файлов, когда можно легко обойтись двадцатью.

И еще, мне нравится, как сказал Гаррет.
Цитата
Сначала учите науку программирования и всю теорию. Далее выработайте свой программистский стиль. Затем забудьте все и просто программируйте.


Я получаю от работы удовольствие и деньги. А ходить строем и делать "как все"... Ну не моё.

Присоединённое изображение
Присоединённое изображение


--------------------
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
chee  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Сын полка
Сообщений: 1780
Пользователь №: 38654
На форуме: 2 года, 11 месяцев, 6 дней
Карма: 40




Цитата (twin @ 4.04.2016 - 11:46)
Зачем 150 файлов, когда можно легко обойтись двадцатью.

А ни кто не ставит вопрос о количестве подключаемых файлов. Это походу у тебя такой фитиш. Если бы мы дрочили на количество файлов, то делали бы минификаторы или пихали несколько классов в один файл.

Вернемся опять же к вопросу: зачем 150 файлов? А ни кто не решает задачу так, что было как можно больше файлов, просто есть множество классов, каждый из них несет свою функциональность в пределах описаных интерфейсов.


--------------------
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Мой блог
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15562
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 6 дней
Карма: 299

Трезвый :
5 лет, 11 месяцев, 15 дней


Ну ладно, не буду говорить про файлы. Буду про классы. Хотя меня коробит такое количество обращений к ФС, но не суть.

Суть в том, что
Цитата (chee @ 4.04.2016 - 08:31)
есть множество классов, каждый из них несет свою функциональность в пределах описаных интерфейсов.

Вот это для меня загадка. Какая цель преследуется этим в инфраструктуре, когда можно обойтись малым количеством. Ведь это и прозрачнее и ремонтопригоднее и вообще. Есть же какая то цель. Вот тут мы и расходимся. Для тебя не важна ресурсоемкость, ты не работаешь на хайлоад проекте, иначе бы так не рассуждал. Для тебя не важна прозрачность, иначе в формировании страницы не было бы задействовано одновременно такой кучи инфраструктурных классов. Так что для тебя важно?

У меня вообще такое впечатление, что вы пишите код раз и до скончания времен. Расширяемость, абстракции... Да он через несколько лет один фиг устареет. И все равно придется все переделывть. Мы живем в обществе потребителей. Всем хочется 6-й айфон, даже если еще не успел покорябаться пятый. Все настолько бренно, что о таких вещах, как буквы в редакторе и говорить не стоит.

Ты же сам меня упрекал в том, что я использую старые технологии. А по сути получается наоборот. Ты сейчас конечно применил DI, это новая фишка. Но стоит ли оно того, чтобы так расшиперить код, что нужно 150 классов для элементарного "Привет, мир"? Все равно не так долго ждать того, что придется все выкинуть и забыть. smile.gif


--------------------
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
chee  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Сын полка
Сообщений: 1780
Пользователь №: 38654
На форуме: 2 года, 11 месяцев, 6 дней
Карма: 40




Цитата (twin @ 4.04.2016 - 12:57)
Но стоит ли оно того, чтобы так расшиперить код, что нужно 150 классов для элементарного "Привет, мир"?

А кто вообще говорит про hello world? Я могу тебе расписать зачем там 150 файлов и что они делают, в моей системе.


--------------------
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Мой блог
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15562
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 6 дней
Карма: 299

Трезвый :
5 лет, 11 месяцев, 15 дней


Цитата (chee @ 4.04.2016 - 11:53)
Я могу тебе расписать зачем там 150 файлов и что они делают, в моей системе.
Да я видел. От того и не понимаю - зачем. Не что они делают. А зачем они это делают. Когда можно все сделать на много проще.

Анекдот вспоминается времен перестройки. Два новых русских в Америке. Один хвастается галстуком - во какой за 1000 баксов купил! А второй - да ты лох. В соседнем магазине точно такие же по 2000 продаются!

Хотя расскажи, если не лень. Может я действительно чего не догоняю.


--------------------
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
chee  
[x] Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Сын полка
Сообщений: 1780
Пользователь №: 38654
На форуме: 2 года, 11 месяцев, 6 дней
Карма: 40




Цитата (twin @ 4.04.2016 - 16:00)
А зачем они это делают. Когда можно все сделать на много проще.

Они делают тоже самое что и у тебя, просто они сгрупированы по разным классам и имеют свои контексты. Как показывает моя практика процедурный код - не позволяет подменять поведение без изменения кода, ООП код (я имею ввиду не классы как контейнеры для функций) поведение позволяет подменить, ну или как минимум позволяет это сделать более выразительно (за меньшее количество строк).

Вот тебе лайв пример:

Процедурка, немного строчек, все как ты любишь

function export($sql)
{
$data = getData($sql);
$content = prepareContent($data);

download($content);
}

export("SELECT * FROM users");


ООП вариант, различий в логике практически нет,

class Export
{
public $dataProvider;
public $contentDriver;
public $output;

public function download($sql)
{
$data = $this->dataProvider->getData($sql);
$this->contentDriver->setData($data);

$this->output->put($this->contentDriver);
}
}


$export = new Export;
$export->dataProvider = new DataProvider;
$export->contentDriver = new ContentProvider;
$export->output = new Output;
$export->download("SELECT * FROM users");


Вроде бы логично, что процедурка рулит, а нет, приходит смена требований, нужно в зависимости от количества данных выдавать разный контент

Функция export, ПЕРЕПИСЫВАЕТСЯ на половину, логика УСЛОЖНЯЕТСЯ, добавляются ДВЕ НОВЫХ функции, которые не могут наследовать функционал от предыдущей фунции prepareContent, а могут лишь только вызвать ее полностью.

function export($sql)
{
$data = getData($sql);
if (count($data) > 100000) {
$content = prepareCsvContent($data);
} else {
$content = prepareXmlContent($data);
}

download($content);
}

Возможно ты подумаешь, что можно и так

function prepareContent($data)
{
if (count($data) > 100000) {
$content = prepareCsvContent($data);
} else {
$content = prepareXmlContent($data);
}

return $content;
}

function export($sql)
{
$data = getData($sql);
$content = prepareContent($data);

download($content);
}

Но это приводит к тем же результатам, ты вносишь ЗНАЧИТЕЛЬНЫЕ ИЗМЕНЕНИЯ в существующую функциональность, просто по ветке вызова это будет немного дальше.




В ООП вариант будет лишь ОДНО НЕЗНАЧИТЕЛЬНОЕ ИЗМЕНЕНИЕ (в передаче зависимостей) и ТРИ НОВЫХ класса, два из которых при необходимости могут НАСЛЕДОВАТЬ функциональность устаревшей версии функционала

class ContentProviderManager
{

public function setData($data)
{
if (count($data) > 100000) {
$this->contentProvider = new ContentProviderCsv;
} else {
$this->contentProvider = new ContentProviderXml;
}

$this->contentProvider->setData($data);
}

public function __toString()
{
return $this->contentProvider->__toString();
}

}


$export = new Export;
$export->dataProvider = new DataProvider;
$export->contentDriver = new ContentProviderManager;
$export->output = new Output;
$export->download("SELECT * FROM users");


Если ты считаешь, что существенно изменять существующий код это в разы лучше чем создавать новый, то у меня нет больше аргументов.


--------------------
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Мой блог
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
Arh  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



146%
******

Профиль
Группа: Форумчанин
Завсегдатай форума
Сообщений: 2110
Пользователь №: 27172
На форуме: 5 лет, 8 месяцев, 7 дней
Карма: 70




А как правильно сделать каждого пользователя объектом и нахуа? =)


--------------------
:)
PMСайт пользователя
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
[x] Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15562
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 6 дней
Карма: 299

Трезвый :
5 лет, 11 месяцев, 15 дней


Цитата (chee @ 4.04.2016 - 14:28)
Если ты считаешь, что существенно изменять существующий код это в разы лучше чем создавать новый, то у меня нет больше аргументов.

Да, я именно про это.

Тут вот в чем печенюшка. Есть такой принцип YAGNI. Так вот, ООП методология по своей философии, это прямое и активное нарушение этого принципа. Ты заранее думаешь, что понадобится то-сё, пято-десято. И сознательно, заблаговременно усложняешь систему. Причем довольно значительно. Со всеми вытекающими последствиями - потерей прозрачности, ресурсоемкостью, увеличением веса приложения, усложнением дебаггинга и кучей других прелестей.

Это похоже на еврейскую мудрость. Когда на ночь ставится два стакана. С водой и пустой. Один - если захочется пить, второй - если не захочется.

И всё бы хорошо, однако я не вижу профита. Не вижу разницы по трудозатратам в том, что придется изменить код или дописать новые классы. А вот то, что при изменении вводных старый, никому не нужный функционал останется, вижу четко. И таким образом у тебя
1. Нарушается YAGNI
2. Приложение зарастает мертвым кодом.

Кроме того, ты сам написал:
Цитата (chee @ 4.04.2016 - 14:28)
добавляются две новые функции,
и
Цитата (chee @ 4.04.2016 - 14:28)
три НОВЫХ класса

И я не понял, в чем преимущество.

И еще, я не увидел селектора. Где ты будешь менять зависимости при разном количестве данных? Твой код не полный, а значит и сравнение некорректно.

А если потребуется разный контент не от количества данных, а по другим критериям? Как ты все предусмотришь?

Кроме того, почему ты решил, что нужно использовать функции. Если есть такая потребность, статические классы тоже можно наследовать. Хотя этого не нужно, от наследований свои проблемы. Но всё же.

Я понимаю, откуда это желание. Это все идет от фреймворков. Все почему то стараются делать по образу и подобию. Ну если это фреймворк - то тогда все понятно и оправдано. Там оптимальность давно положили на алтарь универсальности. И в сорцы лезть нельзя.

Но если это конечный, конкретный продукт, для чего так мудрить?

Вот твою CMS взять. Ты там один единственный разработчик. Для чего тебе такая куча контрактов? Неужели сам боишься заблудиться в своем коде? Причем, как я понял, некоторые из них используются единожды, что вообще нонсенс. Ну тут могу ошибаться, не вдавался особо в подробности.

Но оставим это, о другом сейчас. О том, что это твой проект. Не опенсорсный мейнстримный фреймворк, где нужно предусмотреть всё для всех. Это CMS, законченное приложение. Ты не знаешь, что ждать от самого себя? Зачем стараться так усложнять систему в погоне за универсальностью и расширяемостью, если все равно модифицировать тебе одному.

Точно так же и на конечных проектах с техзаданиями. Или как у меня, на долговременном обслуживании. Загадывать на будущее - дело не благодарное. Хотелки могут так измениться, что и тебе придется все переписывать. Ну или засерать приложение мертвячиной.

Много слов, покажу, как я бы решил такую задачу.
class Export
{
public static function download($sql)
{
$data = DataProvider::getData($sql);
$content = self::prepareContent($data);

Output::put($content);
}

protected static function prepareContent($data)
{
// do sommeting
return $content;
}
}



Export::download("SELECT * FROM users");

ВСЁ!

Поступит вводная, нужно изменить один метод и добавить два новых:
    protected static function prepareContent($data)
{
if (count($data) > 100000) {
$content = self::prepareCsvContent($data);
} else {
$content = self::prepareXmlContent($data);
}

return $content;
}


А может и не поступит, зачем заранее голову греть. И себе и серверу.

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

Не нужно тут наследования никакого, тут можно организовать состояние и юзать разные методы в зависимости от. Ну если функционал большой, то можно и разнести по классам, можно и отнаследоваться при большом желании.

    protected static function prepareContent($data)
{
if (count($data) > 100000) {
$content = Csv::prepareContent($data);
} else {
$content = Xml::prepareContent($data);
}

return $content;
}


Все равно это будет на много меньше кода (про файлы молчу user posted image) и будет прозрачнее. И сервак не загнется. :)

Единственное что нельзя - это сделать классические юнит-тесты. Так они и придуманы для вас. И DI по большому счету для них придумали. Вполне работоспособны фабрики к примеру.

А тесты можно организовать по другим принципам. Не так часто они нужны кстати, чтобы из-за них так усложнять систему.


--------------------
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15562
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 6 дней
Карма: 299

Трезвый :
5 лет, 11 месяцев, 15 дней


Пока я писал, ты успел исправить. smile.gif

Я не буду комментировать, собственно ты и сам почти дошел до того, как оптимальнее.

С __toString() вообще отдельная тема. Тоже не буду заострять внимание. Думаю понятно, почему. smile.gif


--------------------
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
chee  
[x] Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Здесь живет
******

Профиль
Группа: Сын полка
Сообщений: 1780
Пользователь №: 38654
На форуме: 2 года, 11 месяцев, 6 дней
Карма: 40




Цитата (twin @ 4.04.2016 - 19:48)
Вот твою CMS взять. Ты там один единственный разработчик. Для чего тебе такая куча контрактов? Неужели сам боишься заблудиться в своем коде? Причем, как я понял, некоторые из них используются единожды, что вообще нонсенс. Ну тут могу ошибаться, не вдавался особо в подробности.

Зачем контракты(интерфейсы)

1. Я использую DI, зависимостям нужно описывать интерфейс, конкретную реализацию для описания интерфейса нет смысла ставить, так как вообще теряется смысл использования DI.
2. Я могу быть "будущим разработчиком", потому как "предыдущий разработчик" я обязан будущему оставить хоть какую-то документацию, и интерфейсы очень хорошо для этого подходят.
3. Это больше к первому пункту, но у меня в проекте есть автокомплит для вложенных зависимостей, который строится на основе их интерфейсов.
4. Использование интерфейсов дисциплинирует, позволяет задумываться над реализацией.
5. Если я буду продвигать этот продукт в массы мне не нужно будет его переписывать.


Цитата (twin @ 4.04.2016 - 19:48)
Зачем стараться так усложнять систему в погоне за универсальностью и расширяемостью

Я не стремлюсь к универсальности, мне важна расширяемость. За счет расширяемости можно достигнуть универсальности, потому мне и важна расширяемость.


Цитата (twin @ 4.04.2016 - 20:13)
Пока я писал, ты успел исправить. Я не буду комментировать, собственно ты и сам почти дошел до того, как оптимальнее. И ошибки найти не сложно. Другое дело, что ты допустил их прямо в демонстрации преимущества.

А собственно я ничего не правил, я конкретизировал что там внутри классов, что бы ты не начал вопить
Цитата (twin @ 4.04.2016 - 19:48)
И еще, я не увидел селектора. Где ты будешь менять зависимости при разном количестве данных? Твой код не полный, а значит и сравнение некорректно.

Цитата (twin @ 4.04.2016 - 19:48)
Да, я именно про это.

Тут вот в чем печенюшка.

На чем и порешали, давай закроем эту тему. У нас принципиально разное понимание требований к разрабатываемому ПО. Мы не придем к общему мнению.


Цитата (twin @ 4.04.2016 - 19:48)
Ты заранее думаешь, что понадобится то-сё, пято-десято.

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


--------------------
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Мой блог
PMПисьмо на e-mail пользователю
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
twin  
Дата
Цитировать сообщение

Пользователя сейчас нет на форуме



Глухой нуб
******

Профиль
Группа: Администратор
Почтальон группы
Сообщений: 15562
Пользователь №: 6543
На форуме: 8 лет, 2 месяца, 6 дней
Карма: 299

Трезвый :
5 лет, 11 месяцев, 15 дней


Цитата (chee @ 4.04.2016 - 17:11)
На чем и порешали, давай закроем эту тему. У нас принципиально разное понимание требований к разрабатываемому ПО. Мы не придем к общему мнению.

Да к общему мнению ни кто и не стремился. Да, у нас разные понимания, это факт. Но они оба имеют право на жизнь. Смотря какие цели преследуются. Вот к этому мы пришли, это и результат. Давай закроем дебаты, не вопрос.

Она ремарочка только:
Цитата (chee @ 4.04.2016 - 17:11)
Цель примера была именно в том что бы показать тебе на сколько дешево обходится поддержка кода на ООП, нежели при использовании процедурки.


Не увидел я дешевизны. Это ты показал квинтэссенцию, но даже она проиграла. А ведь ты же на этом не остановишься. Добавишь DIC или локатор, еще кучу плюшек, в итоге и вылезеут те 150 классов при генерации маломальской странички. Какая тут дешевизна...

Чем эти накладные оправданы, я так и не понял. Ну наверное мировоззрением и особым пониманием разработки ПО. На том и порешаем.


--------------------
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Зачем ворошить старое, когда можно наворотить новое?

user posted image
PMСайт пользователяICQ
    0   Для быстрого поиска похожих сообщений выделите 1-2 слова в тексте и нажмите сюда Для быстрой цитаты из этого сообщения выделите текст и нажмите сюда
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:

Опции темыСтраницы: (7) 1 [2] 3 4 ... Последняя » Ответ в темуСоздание новой темыСоздание опроса