- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
function GetOrderSkidka(&$arrData)
{
if($this->flag_opt){
$arrData['skidka'] = ($this->admin_mode) ? $arrData['skidka'] : 0;
$arrData['allsum'] = $arrData['sum'] - $arrData['skidka'];
return;
}
if(!$this->flag_in_action){
$arrData['cnt_s_prod'] = $arrData['cnt'];
}elseif(in_array($this->flag_action_type,array(2,3))){
$this->calcCntProd($arrData);
}else{
$arrData['cnt_s_prod'] = 0;
}
$this->discount->GetOrderSkidka($arrData);
}
Работаю с сайтом, в котором все методы классов работают со своими параметрами таким образом.
Метод может ничего не возвращать, а вызывать другие методы (которые также могут вызывать какие-то методы),
которые в зависимости от множества условий меняют переданные по ссылке параметры.
Итог работы модифицированный параметр- массив. Только XDebug выручает.
Follow us!
В }{ацкеле она хотя бы возвращает новое состояние...
Вполне жизнеспособный способ управления.
Разные функции, куда передаются параметры, -- разные аспекты работы системы.
Каждая что-то своё обрабатывает, переопределяет, дописывает, убирает и т.д.
На выходе -- нужное.
А чтобы отлаживать было легче, нужно не забывать писать пред- пост- условия. Тогда после неправильно отработавшей функции выскочит что-нибудь: statusCode, assert, exeption и т.п.
Всё чики-пуки.
Чем плохо?
$_POST -- не более, чем зарегистрированные атрибуты запроса.
О том, что это действительно $_POST может знать только элемент верхнего уровня управления.
Использование $_POST, конечно, неприлично... Но не особенно страшно, по-моему.
Главное -- тестировать части отдельно. Полагаю, это и есть самая большая проблема кода, с которым вы работаете: его части не тестировались. А ещё хуже, если у этих частей, в результате популярного нынче "заплатчаного программирования", которое официально транслируется через умное название "рефакторинг" разными "почитаемыми авторами", у этих самых частей сместились, пересеклись и т.д. аспекты работы; дебажить такое -- адская мука программиста.
> использование $_POST неприлично
Почему? С какой стати? Вы так говорите, как будто это что-то плохое. Зависит же от структуры кода, от того, кто и что с этим $_POST делает, и как защищает.
И да, вы, если я не ослышался, обругали рефакторинг и почитаемых авторов. Да это ж как прийти в ковбойский "салун" и заказать молока.
видимо, чувак обладает исключительным талантом писать идеальный для каждого случая код, словно после рефакторинга, чё.
$_POST определяется не нашим сценарием, а машиной PHP для нас. То есть, некоторый сторонний программист получает информацию о том, что такое $_POST из инструкции к PHP. А мы обманываем его: кладём какие-то посторонние к запросу данные. Потому использование $_POST в подобных целях -- не есть хорошо. Лучше считать этот массив read-only.
Рефакторинг в современном виде возник из того, что объектное проектирование "оказалось" много-много-много сложнее существовавших методик. То есть, это и так было очевидно, ибо цель ООП скрыть сложность реализации сложностью структуры, таким образом и произошло перераспределение сложности из конструирования в проектирование. И вот когда это стало очевидно рядовым пользователям ООП, то во спасение был придуман "рефакторинг". Суть его: перебросить сложность проектирования обратно в конструирование. То есть, по сути своей рефакторинг прикрывает собой "миф" ООП о том, что оно "проще" и "удобнее". Естественно, что "уважаемые" авторы пытаются спасти ситуацию.
Оно не проще. И не удобнее. Это миф. Но без него никак.
Как вы прекрасно знаете, человек совершенно не приспособлен для решения сложных задач. Все чего люди добились - они добились за счет разбиения на подзадачи. "Разделяй и властвуй", говорили еще в древности.
При решении любой более-менее реальной задачи рано или поздно наступает момент, когда человек уже не может справиться с ее сложностью, не может вместить у себя в голове ее полностью. У кого-то этот момент наступает раньше, у кого-то позже. Но сам программист тут не виноват, виновата сложность задач и ограничения человеческого мозга...
Так вот. ООП (при грамотном его применении) позволяет уменьшить число сущностей, над которыми человеку приходится задумываться одновременно.
Да, кода выходит больше, да, в целом понять задачу теперь сложнее. Но зато теперь ее можно решать по частям.
Вторая проблема начинается в тот момент, когда мы хотим внести какие-то изменения. Если программа монолитна - нам пиздец. Если же программа разбита на модули\объекты - можно спроектировать изменения на верхних уровнях, и составить более мелкие задачи, которые нужно будет решить на нижних.
P.S. Если вы скажете, что тоже самое позволяет и структурное программирование - вы будете правы. Но... В вашей структурной программе, если она достаточно большая, как бы вы не старались, появятся все три кота ООП - инкапсуляция, наследование и полиморфизм... либо ваша программа скатится в неподдерживамое говно.
Минусунул.
Проектировать задачу до мельчайших деталей не имеет смысла: так мы зависнем на стадии проектирования, и проект, скорее всего, потеряет актуальность ещё до написания первой строчки кода. Программист (иногда) - не дурак, и часть задач может решить лучше архитектора. Об этом пишут и сами архитекторы, например, тут http://www.ozon.ru/context/detail/id/2456415/.
Тесты очень полезны, когда на стадии проектирования был очерчен интерфейс модуля, а его реализация лежит на плечах разработчика. Другим модулям должно быть важно как модуль себя ведёт по отношению к ним, а не как он устроен. В идеале, изменив внутреннюю структуру модуля (т.е. отрефакторив), мы можем сделать его более производительным и поддерживаемым, при этом его интерфейс не изменится, а другие модули даже ничего не заметят. Ничего плохого ни в тестах, ни в рефакторинге нет.
Ничто не рождается идеальным с первого раза, кроме музыки Моцарта (а вот произведения более образованного и глубокого, на мой взгляд, Бетховена рождались в муках и претерпевали много изменений, а ведь он был гений).
Попробую на гиперболизированном примере.
Выпускаете вы телевизоры. Вы их спроектировали и склепали.
Теперь вас просят добавить в телевизор функциональность пылесоса. Что делать?
Можно провести рефакторинг и прикрутить скотчем пылесос к телевизору, а можно провести перепроектирование нового устройства: пылесос с экраном или телевизор со шлангом.
Это пример ситуации, когда уже нет готовых точек инверсии управления. Ну никто не мог подумать, что телевизор совместиться с пылесосом.
Но какие-то точки инверсии существуют.
Если понадобится добавить функцию картинка в картинке, то не нужно проектировать совершенно новый телевизор. Скорее всего в нём есть части, которые по проекту делегируют функциональность друг другу, телевизор не монолит. Можно вычленить эти самые единицы и провести реинжениринг только там. Получить новый блок обработки изображение и новый экран, например. А идеология рефакторинга -- приклеить к основному экрану маленький, создав где-то в недрах телевизора одну костыльную точку инверсии, через которую будет делегироваться картинка в маленький экран.
Проблема сильной связи между алгоритмом и интерфейсом -- это вообще головная боль не только ООП, но и вообще разработки какой бы то ни было. Потому так популярны методы итерационные с перекрывающимися этапами проектирования и конструирования.
И то лишь в моём нике.
Толковые парни тоже уважают его:
http://www.youtube.com/watch?v=x9SZVOzNcAc
http://www.youtube.com/watch?v=cQCQRLA05AA
Когда вычисляют погоду, то в кодах содержится 30% физики и 70% поправочных функций, которые, что-то подкручивают, чтобы получить правильно.
Вот и современное программирование состоит из программирования как науки об управлении алгоритмами на 30%, а на 70% из костылей, которые позволяют сделать что-то при минимуме понимания. И ответ всегда один: "а вам это и не нужно".
При этом, человек может существовать гармонично только тогда, когда он делает дело хорошо или не делает вообще. Если происходит что-то промежуточное, то возникает сильная деградация.
Так вот, рефакторинг -- это как раз та самая кошка: и не хорошо, и делается.
Например, существуют ситуации, когда "рефакторинг" не является "рефакторингом". Есть методики создания ПО, которые просто смешивают этап проектирования с конструированием. Здесь нет рефакторинга, потому что проектирование продолжается, но оно "тестируется" в коде.
Типичный рефакторинг происходит тогда, когда вы писали код "и вдруг заметили", что у вас две функции имеют близкое тело. И вот вы ищите и выделяете куски, чтобы "убрать" дублирование кода.
То есть, чтобы изменение кода действительно называть рефакторингом, необходимо выполнить условие, что код предшествует рефакторингу. Сначала вы спроектировали код с двумя одинаковыми функциями, а потом с чего-то решили из двух сделать одну -- рефакторинг. Если же вы поняли на этапе проектирования, что где-то получаются две близкие функции, и начинаете исправлять проект -- это не рефакторинг.
Ну это ладно, с натяжкой можно отнести к оптимизации. А как насчёт ситуации, когда проект постоянно развивается, и на этапе проектирования было просто невозможно угадать что ещё может понадобиться через пару лет? Потом просят что-то добавить - а архитектура не позволяет. Что делать? Можно лепить, как вы выразились, костыли (РНР - вообще идеальный для изготовления костылей инструмент :) ). Быстро и дёшево, но через полгода сами себя проклинать будете. А можно провести рефакторинг: упростить или лучше разграничить код, подготовить его к переезду на новый фундамент.
Вообще даже вики довольно неплохо описывает зачем это нужно:
1. необходимо добавить новую функцию, которая недостаточно укладывается в принятое архитектурное решение;
2. необходимо исправить ошибку, причины возникновения которой сразу не ясны;
3. преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.
Или в английском варианте польза от рефакторинга:
1. Maintainability. It is easier to fix bugs because the source code is easy to read and the intent of its author is easy to grasp. This might be achieved by reducing large monolithic routines into a set of individually concise, well-named, single-purpose methods. It might be achieved by moving a method to a more appropriate class, or by removing misleading comments.
2. Extensibility. It is easier to extend the capabilities of the application if it uses recognizable design patterns, and it provides some flexibility where none before may have existed.
рефакторинг - это адаптация кода к архитектурным изменениям для поддержания или улучшения качества кода.
И вот из-за того, что это дорого, придумали себе костыль -- рефакторинг.
Вы сами всё понимаете знаете. Чего вы тогда голову морочите и говорите, что рефакторинг -- хорошо? о.О
Сделайте работу над ошибками и приходите завтра!
Это просто вам пыль в глаза пускают, чтобы оправдать основную цель подпорки.
Если у вас есть хоть какой-то намёк на функциональность, которая никаким образом не учтена в исходном проекте -- вы упираетесь в перепроектирование.
Но заменяя его более дешёвым рефакторингом, преобразуете код в говно.
Сразу из написанного вами сквозит говнокод: большую функцию разделить на маленькие. (!)
Если у вас спроектирован некоторый алгоритм, который не требует делегирования (100500 математических операций, которые всегда делаются в программе монолитно), то разделение на куски этого алгоритма быстро приведёт к тому, что участники проекта разрушат инвариант алгоритма и создадут несколько, что, вне всяких сомнений, скажется на безопасности алгоритма.
Не нужно создавать функций! Нужно написать красивые комментарии и руководство.
А вот если вы "промахнулись" при проектировании и оказалось, что кусок кода большой функции нужен где-то ещё -- то тогда и получается у вас "рефакторинг": тут натянул, тут повисло.
Во всех остальных случаях дешевле и удобнее спроектировать только межмодульные API и архитектуру, оставив тонкости реализации модулей на откуп отвечающих за них разработчиков.
Если интерфейсы модулей хорошо документированы, а реализации им строго соответствуют, то внутримодульный рефакторинг и говнокод никого не ебёт. Пока оно крякает как утка и плавает как утка - это утка.
Настоящий реинжиниринг здесь потребуется только в тех случаях, когда изменение затронет несколько модулей, в остальных случаях с чистой совестью можно обойтись, как вы правильно заметили, дешевым рефакторингом.
Вы же предлагаете делать монолитные куски, которые даже с документацией понимать и править будет нереально. И каждое изменение потребует именно дорогого реинжиниринга, в силу монолитности проекта.
P.S. Выходите уже из анабиоза. Идеальный код можно писать вечно, а софт нужен здесь и сейчас. И в большинстве случаев насрать на говнокод, главное, чтобы код надежно и корректно выполнял поставленную задачу.
Рефакторинг - процесс изменения внутренней структуры программы (или модуля, класса, функции), не затрагивающий её внешнего поведения.
Реинжиниринг - процесс создания новой функциональности или устранения ошибок, затрагивающий внешнее поведение программы (модуля, класса, функции).
Получается, что рефакторинга не существует вообще. Есть только реинжиниринг.
Практически любой значимый кусок кода что-то куда-то делегирует. То есть, изменение этого куска приведёт к изменению внешнего поведения этих внутренних подчастей.
Получается, что рефакторинг -- это разве что переименование переменных внутри функции или, скажем, перераспределение арифметических действий.
Однако, на деле всё обстоит гораздо печальнее...
Т.к. внешних сущностей намного больше, внутренними можно пренебречь и назвать это рефакторингом.
хоть рефакторинг, хоть уруккето, при этом на деле, методологически, рефакторинга, согласно вашему представлению, не существует.
По сути, для того, кто смотрит на вашу функцию как на делегата глубоко всё равно, что там за реинжиниринг, с точки зрения клиента ничего не произошло. Ему не нужно этот процесс какими бы ни было словами обзывать, он вообще ничего о них не знает.
А вот для делегата -- это полноценное перепроектирование.
Если пользоваться подобным определением, как вы предлагаете, то стоит добавить туда важную детать: рефакторинг всегда оперирует заранее определёнными условиями алгоритма. Во время рефакторинга, до начала этого самого рефакторинга, уже известно где он закончится, какой конкретно кусок не должен изменить поведения с точки зрения клиента. Таким образом, уже до начала проектирования определены пред- и пост- условия, а также инварианты, и рефакторинг может себе позволить только такие изменения кода и проекта, которые сидят внутри множества этих самых ограничений.
Полноценного перепроектирования, которое бы остановилось в тех точках, где это уже было бы заранее "предусмотрено" архитектурой, вы не проводите. Почему? Потому что это дорого. Заранее не известно, где это может кончиться, так как подходящей точки инверсии может и не существовать вовсе (как в примере с пылесосом)!
Отсюда все беды.
Рефакторинг можно зачеркнуть рефакторинга не существует. Забудьте! Есть перепроектирование. Это нормальный путь развития системы, если в неё вносятся изменения. Либо найдётся точка инверсии, которая была определена заранее, либо система перепроектируется полностью.
Ой зря вы это сказали...
Если большую систему нужно перепроектировать полностью по каждому мало-мальскому поводу, который не был учтен изначально - то архитектура - ебучее монолитное говно, а архитектор мудак, которого лучше не подпускать к проектированию.
Все-таки хорошо спроектированная система подразумевает некоторую изоляцию подсистем друг от друга. И большинство изменений (но, конечно, не все) локализуются в одной или нескольких подсистемах, не касаясь других.
P.S. И никогда не поздно перепроектировать ряд подсистем и добавить новые точки инверсии (как вы любите выражаться) без перепроектирования всей системы.
Но вот некоторую часть придётся. А если изменится эта часть, то могут измениться и условия работы этой части и даже интерфейс (жизнь так устроена, что алгоритм диктует условия, а условия -- это и есть интерфейс). Получается, что сначала вам нужно понять то, как должна быть устроена новая функциональность в конечном алгоритме, затем искать подходящие точки инверсии, а не надеяться, что вы их угадаете in advance).
Именно в этом смысле вы НИКОГДА не сможете заранее спланировать ваше ООП приложение, а потом дописать функциональность. Это не сработает. Потому и приходится "хитрить". И вот эти дыры хитроумности и называются "рефакторингом".
А на деле это обман!
Слово это нужно убрать из лексикона программистов. Признаться честно: проектирование ООП сложно, дорого и долго, плотно связано с конструированием.
Рефакторинг -- заплатка на теле ООП, которая прикрывает срам сложности. Вливалось то в уши программистам, что всё будет "чики-пуки", что вот он "Святой Грааль". А получилось как всегда... Вот и начали "корифеи" крутиться в колесе. А воз и ныне там. Мифы, мифы, мифы...
И вечный рефакторинг... И, что ещё печальнее, молодым умам говорится вовсе не то, что вы пишите, а именно в таком плане: сейчас не будем допроектировать, потом дорефакторим... А потом оказывается, что проектирование было из рук вон плохое, что точек инверсии удобных не хватает, что модульность потеряна. Вернуть её никаким "частным" перепроектированием невозможно. Увидев это и осознав, люди подставляют под систему костыли, чтобы не убиться об стену переписывая своё "ебучее говно".
Каким бы красивым ни был костыль-рефакторинг, он костыль.
Кто меня звал? Я уже не выдерживаю этого размаха троллинга или батхерта. У меня вся страница в жиру.
Пожалуйста, назовите наконец нам замену ООП, не обладающую вышеназванными недостатами?
Обсирать языки я тоже горазд. Когда я это делаю, то почти всегда говорю, что мол в том то и том то языке этого говна нет. (Зато есть другие, но я это стыдливо умалчиваю, но не в этом суть).
А теперь суть:
Отвергаешь? Предлагай замену!
Поддержу эту мысль.
@interested, вы так яростно стоите против ООП и рефакторинга. Но... все ваши аргументы они применимы против практически любой идеологии.
>>>Рефакторинг -- одна из заплат на теле ООП.
Это всё, о чём я говорил.
Заменять нужно не ООП, а ООП программистов.
Так это я и пытаюсь до вас донести... Вы никогда не сможете заранее спланировать ваше приложение в рамках любой парадигмы, какой бы хорошей она не казалась. К тому же требования постоянно меняются, такова природа нашего мира.
И вот именно поэтому, вам, в любом случае придется заниматься модификацией системы. Не будем называть ее рефакторингом или реинжинирингом, чтобы не придираться к словам. Назовем ее просто модификацией. И это не какая-то там хитрость. Это просто необходимость.
А если модификацией все равно придется заниматься, то зачем тратить средства и время на излишне подробный проект? Ведь дешевле и быстрее составить скелетный проект, детали которого будут определяться позже...
Я сам иногда говно пишу... Намеренно. Когда менеджер заказчика пытается влезть во внутреннюю реализацию. Хотите за меня спроектировать модуль - пожалуйста, получите своё говно, если не слушаете человека, который ближе знаком с реалиями... А потом рефакторим, когда до менеджера дойдёт, что так жить нельзя. :) Тут как раз тот рефакторинг, который имел в виду г. заинтересованный. :) Но он не всегда такой. :)
>я и пытаюсь до вас донести...
Lowezar
>...Как вас всех понесло...
А теперь вопрос к interested: а что нужно, по вашему, ему на замену? Поделитесь своими мыслями. Пока вы лишь готовы переименоваться в OOPGovno, но не предоставили ничего более хорошего взамен.
Есть и ФП, и АОП, модульное... Инструментов хватает - главное, чтобы мозгов хватило применять наиболее подходящий инструмент.
Да, ООП не универсально, это надо признать - например, не вышло проецировать объекты реального мира 1:1 в классы ООП - но никто не заставляет вас придерживаться одной парадигмы, даже на Джаве, которая ООП до мозга костей, можно программировать модульно, процедурно, функционально....
думаю заняться скалой после груви
Шучу. Обещаю не регистрировать, если не найду говна. Как с лиспом я просчитался, так ошибку со скалой я не повторю.
- Слышь scala, говно есть?
- Нет
- А если найду?
Там, по-моему, была тупизна и нежелание разобраться в основах, а не говно в языке.
Типичный диалог.
Гумно:
- "вот какой-то код. он не работает. поэтому Хаскелл - говно. ЧЯДНТ?"
Роман:
- "Хуйню написал. Надо так и так."
Гумно:
- "Ясно. Спасибо."
Вы сказали глупость.
Развивающийся проект либо имеет запас точек инверсии, либо перепроектируется.
Рефакторин нужен ТОЛЬКО для одной цели: быстрее выбросить сырой продукт, потом "дорефакторить". Обыкновенно, такие продукты содержат массу говнокода во всех версиях. И их полно на этом сайте.
Мы все люди, мы не видим полной картины, не умеем предсказывать будущее, совершаем ошибки.
Да, часто мы пишем говнокод, но решение не может быть сразу и красивым, и оптимальным по потребляемым ресурсам.
А еще мы ленивы.
ОПП придумали не для того чтобы вам голову морочить, а для оптимального использования кода. А как конкретно читайте умные книжки.
>Другой крупный критик ООП — это известный специалист по программированию — Александр Степанов, который работая в Bell Labs участвовал в создании C++ вместе c Бьерном Страуструпом, а впоследствии, уже по приглашению в HP Labs, написал Standard Template Library (STL).
Александр Александрович полностью разочаровался в парадигме ООП, в частности он пишет:
«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.
Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».
> Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома
Аксио́ма — исходное, принимаемое без доказательства положение какой-либо теории, лежащее в основе доказательств других ее положений.
По поводу аксиом: Степанов как бы намекает, что сначала в математике находят некие соотношения (теоремы), и только потом выделяют в них общее и составляют набор аксиом (как правило, это делают следующие поколения математиков).
Индийские математики начали использовать отрицательные числа задолго до того, как их формализовали в Европе.
Комплексные числа появились ещё в 15 веке в формулах решения кубических уравнений, теорией функций комплексной переменной начали заниматься много позже.
Наивную теорию множеств дал нам Кантор, доработали и формализовали эту теорию Цермело и прочие Франкели.
Многие уважаемые авторы пишут, что "правильная" архитектура приложения, как бы проста она не выглядела в итоге, рождается только после того, как начинается реализация системы, т.е. формальный подход декомпозиции "сверху-вниз" практически никогда не работает.
А я вот всегда думал: "может я что-то не так делаю?" Спасибо. :)
при подходе "снизу-вверх",т.е. реализовывая отдельные разной величины независимые модули, частенько затруднительно определить, что нужно будет реальной системе, а что лишь потеря времени на "универсальность".
таким образом, гибридный подход позволяет преодолеть недостатки упомянутых противоположных подходов
Кстати (тут уже без сарказма:) ), по последнему пункту - оно хоть одно? А хотя нет, раз XDebug - значит размазано по разным...
То есть, очень даже применяется в жизни.