проблемы объектного сознания

[fixxxer]

return (object)$assoc_array; // HA HA! I AM USING OOP!

P.S. Давайте не будем скатываться в религию?
P.P.S. Посмотрите например на nginx-овские фильтры - чем не chain of responsibility? Заметьте чистый си. Что не мешает городить свитчи и goto там где нужна максимальная производительность.

-~{}~ 16.03.09 00:43:

Вот кстати о компонентах. Щас подумалось что вопросы, связанные с образом мышления, они вовсе не объектному подходу свойственны, а компонентному. Хотя конечно второе обычно подмножество первого. Ну и еще мне тут подсказывают что об этом писал Spolsky в статье про leaky abstractions.

 

[whirlwind]

HraKK в статье все верно расписал и добавить нечего. только жиле на желе исправить =)

fixxxer Просто я не вижу аргументов кроме - все что ООП можно написать без ООП. Как по мне так это не аргумент. Примеров "плохого" ООП я в топике не видел.

 

[fixxxer]

Ну у меня есть два аргумента, но с обоими можно жить

1 - процедурному подходу можно научить школьника, и он будет писать вменяемый код. Чтобы научиться строить хорошую объектную архитектуру, нужны годы опыта, и все равно что-нибудь будет криво; плохо спроектированная объектная архитектура - это мина замедленного действия, и если не провести вовремя рефакторинг, масштабы бедствий в плане сложности поддержки будут хуже, чем с процедуркой. И в некоторых случаях действительно может получиться усложнение на пустом месте, как пример гротеска см. hello world in patterns.

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

Аргумент с инкапсуляцией отнесу пожалуй к подвиду п.1, т.к. при продуманной архитектуре он решается сам собой.

 

[fisher]

>>HraKK в статье все верно расписал и добавить нечего. только
>>жиле на желе исправить

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

>>Как по мне так это не аргумент
Ну странный человек, ты написал, что ты не понимаешь как сделать. Тебе написали, как это делается - так пишутся отчуждаемые/встраиваемые компоненты на си уже десятки лет. Ты не знал про это, но вместо того, чтобы узнать и расширить кругозор - ты это просто игнорируешь, теперь ты пишешь "не вижу примеров плохого использования ООП". Надеюсь, что ты всё-таки понял, о чем мы тут разговаривали.

 

[whirlwind]

Мой основной аргумент - полиморфизм. Есть любители сложной логики в БД? Нужны пару примеров тестирования хранимок.

 

[fixxxer]

слушай ну кто говорил о логике в бд???

-~{}~ 16.03.09 01:11:

и кстати вот вы товарищи ТДД инфицированные сами свой же подход в плане популяризации сводите на ноль заявлениями "это плохо потому что не тестируется". то, что из testability в подавляющем большинстве случаев является показателем качества архитектуры, и то, что что-то плохо тестируется, часто аукнется впоследствии в виде трудностей реюза кода или расширения, оно же совершенно непонятно интуитивно, это только из опыта понимаешь. а со стороны выглядит как психическое отклонение в виде мании тестирования =)

 

[whirlwind]

Автор оригинала: fisher
Ну странный человек, ты написал, что ты не понимаешь как сделать. Тебе написали, как это делаются - так пишутся отчуждающиеся/встраиваемые компоненты на си уже десятки лет. Ты не знал про это, но вместо того, чтобы узнать и расширить кругозор - ты это просто игнорируешь, теперь ты пишешь "не вижу примеров плохого использования ООП". Надеюсь, что ты всё-таки понял, о чем мы тут разговаривали.

Блин ну неохота сраться. Ну вот чего ты вырываешь слова из контекста? Я сказал - как сделать так же удобно как и factory. В сях я шарю но почему то все равно предпочитаю ООП-вариант. Наверное потому, что подменить функцию можно только ЕСЛИ РАЗРАБОТЧИК ЭТО ПРЕДУСМОТРЕЛ. В случае полиморфизма такое условие не требуется.

#include "CBodyTest.h"

namespace app {
    namespace ode {

CPPUNIT_TEST_SUITE_REGISTRATION(CBodyTest);

void CBodyTest::setUp()
{

}

void CBodyTest::tearDown()
{

}

void CBodyTest::testConstructor()
{
    CBody body(&world);
    CPPUNIT_ASSERT(0 != body.getId());
}

void CBodyTest::testDestructor()
{
    CBody* body = new CBody(&world);
    dBodyID id = body->getId();
    delete body;
    body = 0;
}

void CBodyTest::testGetPosition()
{
    CBody body(&world);
    dBodySetPosition(body.getId(), 10, 15, 20);
    irr::core::vector3df pos = body.getPosition();
    CPPUNIT_ASSERT_EQUAL((float)10, pos.X);
    CPPUNIT_ASSERT_EQUAL((float)15, pos.Y);
    CPPUNIT_ASSERT_EQUAL((float)20, pos.Z);
}

void CBodyTest::testSetPosition()
{
    CBody body(&world);
    dBodySetPosition(body.getId(), 100, 200, 250);
    body.setPosition(irr::core::vector3df(1, 2, 3));
    const dReal* pos = dBodyGetPosition(body.getId());
    CPPUNIT_ASSERT_EQUAL((dReal)1, pos[0]);
    CPPUNIT_ASSERT_EQUAL((dReal)2, pos[1]);
    CPPUNIT_ASSERT_EQUAL((dReal)3, pos[2]);
}

void CBodyTest::testGetRotation()
{
    CBody body(&world);
    irr::core::quaternion qs(10, 5, 15, 2);

    // normalize before comparison, otherwise lost accuracy
    dQuaternion q = {qs.W, qs.X, qs.Y, qs.Z};
    dBodySetQuaternion(body.getId(), q);
    
    irr::core::quaternion rot = body.getRotation();
    
    qs.normalize();
    CPPUNIT_ASSERT_EQUAL(qs.W, rot.W); 
    CPPUNIT_ASSERT_EQUAL(qs.X, rot.X);
    CPPUNIT_ASSERT_EQUAL(qs.Y, rot.Y);
    CPPUNIT_ASSERT_EQUAL(qs.Z, rot.Z);
}

void CBodyTest::testSetRotation()
{
    CBody body(&world);
    irr::core::quaternion iq(1, 2, 3, 4);
    body.setRotation(iq);
    const dReal* oq = dBodyGetQuaternion(body.getId());
    
    iq.normalize();
    CPPUNIT_ASSERT_EQUAL((dReal)iq.W, oq[0]);
    CPPUNIT_ASSERT_EQUAL((dReal)iq.X, oq[1]);
    CPPUNIT_ASSERT_EQUAL((dReal)iq.Y, oq[2]);
    CPPUNIT_ASSERT_EQUAL((dReal)iq.Z, oq[3]);
}

void CBodyTest::testGetRotationEuler()
{
    CBody body(&world);
    irr::core::quaternion i(60 * core::DEGTORAD,
			    30 * core::DEGTORAD,
			    10 * core::DEGTORAD);
    body.setRotation(i);
    irr::core::vector3df rot = body.getRotationEuler();
    CPPUNIT_ASSERT_EQUAL((float)60, rot.X);
    CPPUNIT_ASSERT_EQUAL((float)30, rot.Y);
    CPPUNIT_ASSERT_EQUAL((float)10, rot.Z);
}

void CBodyTest::testSetRotationEuler()
{
    CBody body(&world);
    body.setRotationEuler(irr::core::vector3df(10, 20, 30));
    
    irr::core::vector3df r = body.getRotationEuler();
    CPPUNIT_ASSERT_EQUAL((float)10, r.X);
    CPPUNIT_ASSERT_EQUAL((float)20, r.Y);
    CPPUNIT_ASSERT_EQUAL((float)30, r.Z);
}

    } // end namespace ode
} // end namespace app

-~{}~ 16.03.09 01:22:

Автор оригинала: fixxxer
слушай ну кто говорил о логике в бд???

а у нее такие же возможности как и у процедурного подхода

и кстати вот вы товарищи ТДД инфицированные сами свой же подход в плане популяризации сводите на ноль заявлениями "это плохо потому что не тестируется". то, что из testability в подавляющем большинстве случаев является показателем качества архитектуры, и то, что что-то плохо тестируется, часто аукнется впоследствии в виде трудностей реюза кода или расширения, оно же совершенно непонятно интуитивно, это только из опыта понимаешь. а со стороны выглядит как психическое отклонение в виде мании тестирования =)

Да ну. А ты вероятно проповедуешь error_reporting = 0 ?
Запахи кода и есть индикаторы. Не надо быть гением программирования, достаточно просто обращать внимание на запахи кода. это доступно даже школьнику.

 

[fixxxer]

То есть ты хочешь сказать что ты ничего не зная о ТДД сообразил когда то сам по себе что если код плохо тестируется то из этого следует блаблабла? НЕ ВЕРЮ

А агрессивная пропаганда без объясняния суть методики действительно отталкивает. Погугли по форумам/сообществам, куча примеров. Я и сам так долгое время относился, ну просто потому что из таких вот заявления складывается имидж программирования ради программирования, этакого интеллектуального онанизма.

 

[fisher]

>>Запахи кода и есть индикаторы
и тесты его покрывающие - стражи его! классический фимоз TDD

 

[fixxxer]

whirlwind
Ну вот видишь, и fisher так же считает. ) А все потому что здравые мысли окружили каким-то сектанством, за которыми суть потерялась. В результате люди с самостоятельным мышлением вырабатывают неприятие, и либо вообще забивают, либо доходят со временем своим умом чем это все же полезно.

 

[Long]

Это как водить автомобиль. Ты либо умеешь водить автомобиль либо не умеешь. Не бывает умеренного или неумеренного умения вождения автомобиля.

иметь большой водительский стаж и участвовать в какой-нибудь формуле-3000 два разных случая. вот fixxxer, ты можешь поручится за то, что через n-е время ты не посмотришь на текущую реализацию и не скажешь что она так же плоха как и предыдущие? если текущий работодатель по какой-то причине согласен оплачивать эксперименты - почему бы и нет. а что будет, если реальные нагрузки нагнут железо так, что потребуется не 53 фронта, а 103? при этом нам заранее было известно, что:

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

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

 

[whirlwind]

Давайте не будем отходить от темы и вернемся к аргументам

Повторю основной аргумент - полиморфизм, который позволяет заменять реализации участков кода. Аналога плиморфизму в процедурном стиле нет. Заменить реализацию в процедурном возможно только если код разработан с учетом последующей подмены реализации.

-~{}~ 16.03.09 01:37:

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

 

[fixxxer]

Long
Раскусил, я в каком то смысле и экспериментирую, но стараюсь держать все под контролем - и сроки, и производительность, пока что получалось. Вариант про 103 исключается, бенчмарки пусть и синтетические но не могут настолько расходиться с реальностью, методика выявления боттлнеков тоже отработана. Рискую кстати и собственными деньгами т.к. сам соучредитель. А если бы не было экспериментов, не появились бы например Unix и Си

Повторить - и даже улучшить - сможет думаю любой из участвующих в разработке. А какие то публикации, опен сорс фреймворк итд делать еще рано, пока еще много вещей которые можно улучшить =)

-~{}~ 16.03.09 01:44:

>> Аналога плиморфизму в процедурном стиле нет.

Посмотри исходники nginx.

-~{}~ 16.03.09 02:02:

Внимание, полиморфизм! На классическом до омерзения примере с фигурами.

<?

function draw_circle($circle) {
    echo "Circle!"; var_dump($circle);
}

function draw_rect($square) {
    echo "Square"; var_dump($square);
}

$circle = array(
    'methods' => array('draw' => 'draw_circle'),
    'center' => array(
        'x' => 100,
        'y' => 70,
    ),
    'radius' => 50,
);

$rect = array(
    'methods' => array('draw' => 'draw_rect'),
    'left' => 10,
    'top' => 20,
    'width' => 40,
    'height' => 5,
);

$figures = array( $circle, $rect );

foreach ($figures as $figure) {
    call_user_func($figure['methods']['draw'], $figure);
}

Я вовсе не призываю так писать, лишь хочу продемонстрировать, что объектная парадигма вполне реализуется и не на объектном языке. Кстати, первые компиляторы C++ и Objective C транслировали код в чистый Си и запускали Си- компилятор

 

[fisher]

>>Повторю основной аргумент - полиморфизм
что за аргумент, чего аргумент? ведь никто не говорит, что ООП - плохо. речь о том, чтобы понимать недостатки.

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

 

[fixxxer]

Народ, до меня только что дошло, что мы все разговариваем сами с собой )))))

 

[whirlwind]

<?

function draw_circle($circle) {
    echo "Circle!"; var_dump($circle);
}

function draw_rect($square) {
    echo "Square"; var_dump($square);
}

$circle = array(
    'methods' => array('draw' => 'draw_circle'),
    'center' => array(
        'x' => 100,
        'y' => 70,
    ),
    'radius' => 50,
);

$rect = array(
    'method' => array('draw' => 'draw_rect'),
    'left' => 10,
    'top' => 20,
    'width' => 40,
    'height' => 5,
);

$figures = array( $circle, $rect );

foreach ($figures as $figure) {
    call_user_func($figure['methods']['draw'], $figure);
}

йопта

Circle!array(3) {
  ["methods"]=>
  array(1) {
    ["draw"]=>
    string(11) "draw_circle"
  }
  ["center"]=>
  array(2) {
    ["x"]=>
    int(100)
    ["y"]=>
    int(70)
  }
  ["radius"]=>
  int(50)
}

Warning: call_user_func(): First argument is expected to be a valid callback in /home/whirlwind/test.php on line 31

И вперед выяснять где вася пупки н забыл буковку. Это кстати камень в сторону ассоциативных массивов. Все что основано на соглашениях будет глючить. Код должен требовать а не предполагать.

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

 

[fixxxer]

Я ж говорю сами с собой гыгыгы

 

[whirlwind]

кттто здесь?

-~{}~ 16.03.09 02:17:

PS. поглядел фильтры. я бы не сказал что решение изящное, но кто я такой что бы критиковать код сысоева

 

[fixxxer]

2х2 = 4!

PS - а решение кстати вполне стандартное в системном программировании, ничего особенного - просто пример

 

[AmdY]

а о чём вы спорите? слово class не нравится или само рассмотрения архитектуры как скопища объектов? вот fixxxer привёл пример процедурной реализации работы с _объектами_ $circle, $rect?
лучше бы расказали как вредно пытаться нацепить сомописную ORM на БД, очень актуальный вопрос, или как заменить front controller на nginx, или как реализовать статистику на основе логов, а не писать счётчик на php, или работу с потоками..... вещи где объекты не лучший выбор.