ООП или процедурка?

ООП это более красиво, расширяемо, логично (имхо)

Если крупные проекты писать в процедурном стиле там сам черт голову сломит)) Он больше подходит для проектов типа "написал и забыл" )

Сапе клиентской класс конечно нужен как зайцу стоп-сигнал ... с одной стороны, а с другой стороны - чем мешают-то? Ничем. Поэтому в данном конкретном примере - с сапой - разницы нет.

В общем скучный холивар-то Вы затеяли, опоздали с ним лет эдак на 7 минимум:)

Задайте себе вопрос - как появляются классы в проекте если взять некоего абстрактного программера.

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

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

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

И еще небольшой довесок - приемы программирования. Разбуди ООПшника ночью и спроси что такое синглтон или фабрика - он оппа и воткнет о чем речь. А функциональнику Вы будете 2 часа сначала объяснять что это такое и как надо реализовывать и почему. Сокращает время.

Тут главное чувство меры на самом деле.

Принципиальной разницы - нет. Но иногда в проекте нужны ООП-шные доп.фишки. И тогда глупо не выбрать его.

Если конечно не идет речь о мегаскорости и мегапроизводительности. Потому что функции все-таки жрут в случае пхп раза в 2-3 меньше памяти в целом и все-таки быстрее чем классы.

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

Я так понимаю, вы говорите про PHP. Я сам пишу уже несколько лет на Java, так что мое мнение может быть необъективно :)

Крупная компания, пишущая много больших проектов, с определенной текучкой кадров. В остальных случаях ООП - зло.

Бред, любой ваш кривоцикл сожрет больше памяти чем класс сам по себе.

+ 1, еще можно вспомнить инклуды библиотек функций где на сотню функций дай Бог десяток используется

edogs Вас читать как хорошую книгу иногда интересно! Со всем согласен... но нераскрытой осталась тема:

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

Опять же примеров...

:) Прям рассказали сейчас почему лично я не люблю фреймворки... :)

1)

на разных языках по разному, объект просто переменная (или другой тип данных) к которой прицеплены удобно методы (и т.д.)

есть еще Role OOP есть только в Smaltalk (я не давно увидел, интеренсо, можно писать так как там)

очень удобно: наследование, полиморфизм, инкапсуляция

если без ООП, то данные хранить и передвать через структуру наверное

на php часто смешивают OOP и процедурное

во фремворках как правило все очень красиво

2)

вот примеры:

#Class.pm
package Property;
BEGIN {*UNTIE=*DESTROY}
sub TIESCALAR {
    print "creating layer..\n";
    my$self=\{};
    bless $self, $_[0];
    if(defined $_[1]) {
        $self->STORE($_[1]{-default})             if exists $_[1]{-default};
        $$$self{-getter}=$_[1]{-getter}           if exists $_[1]{-getter};
        $$$self{-setter}=$_[1]{-setter}           if exists $_[1]{-setter};
        $$$self{-destroyer}=$_[1]{-destroyer}     if exists $_[1]{-destroyer};
        $$$self{-aftertie}=$_[1]{-aftertie}       if exists $_[1]{-aftertie};
    }
    $$$self{-aftertie}($self, @_) if exists $$$self{-aftertie};
    +$self
}
sub FETCH     {
    if(exists $${$_[0]}{-getter}) {
        +$${$_[0]}{-getter}(@_)
    } else {
        print "getter called..\n";
        +${+shift}
    }
}
sub STORE     {
    if(exists $${$_[0]}{-setter}) {
        +$${$_[0]}{-setter}(@_)
    } else {
        print "setter called..\n";
        +${+$_[0]}=$_[1]
    }
}
sub DESTROY   {
    if(exists $${$_[0]}{-destroyer}) {
        +$${$_[0]}{-destroyer}(@_)
    } else {
        print "destroyer of worlds..\n";
        +shift
    }
}
package Class;
#описание класса для размножения
sub new {
    my($class, $self)=(shift, {@_});
    foreach(keys %{$self->{-properties}||={}}) {
        tie $self->{$_}, Property, $self->{-properties}{$_};
        print $_, "\n";
    }
    delete $self->{-properties};
    +bless $self, $class;
}

#test.pl
package Child;
push @ISA, 'Class';
#пример дочернего класса
package main;
my$o1=Child->new( #описание объекта с нужными свойствами
    -properties=>{
        p1=>{
            -default=>1,
            -getter=>sub {
                print "Your getter\n";
                +${+shift}
            }
        },
        p2=>{
            -default=>3,
            -destroyer=>sub {
                print "Your destroyer\n";
            }
        }
    }
);
print $o1->{p1}, "\n";
$o1->{p1}=2;

3) а вот пример на процедурном

в принципе тоже самое

еще круче чем на Java 😆

package qxp;
use strict;

sub H($){pack'H*',$_[0]}
sub by{map{[splice@_,1,$_[0]]}!($#_%$_[0])..$#_/$_[0]}
sub is($){$_ eq$_[0]}
sub cat{join'',@_}
sub list{@_}
sub wa{wantarray?@_:cat@_}
sub yuki(&@){shift->();@_}
sub fopen(;$){open my$z,$_[0]||$_;$z}{my %file;
sub file($){readline($file{$_[0]}||=fopen$_[0])}}
sub slurp(;$){wa map{yuki{close$_}<$_>}fopen$_[0]}
#sub spew($;$){sub{map{print $_ $_[1];close$_}fopen$_[0]}->($_[0],$#_?$_[1]:$_)}
sub spew($;$){open my$z,">$_[0]";print $z $#_?$_[1]:$_;close $z}
sub table{map{chomp;[split/\t/]}@_}
sub trim{map{s/^\s+|\s+$//g}@_?@_:$_}
sub count{my%z;$z{$_}++for@_;\%z}
sub uniq{keys%{count@_}}
sub copy{wa local@_=@_}
sub find(&@){no strict 'refs';local(*{(caller).'::a'})=\(my$a=$_[1]);&{$_[0]}||($a=$_)for(@_[2..$#_]);$a}
sub first(&@){$_[0]->()&&return$_ for@_[1..$#_]}
sub min{find{$a<$_}@_}
sub max{find{$a>$_}@_}
sub section{map{$_->[$_[0]]}@_[1..$#_]}
*#=sub{map$#$_,@_};
sub zip{map section($_,@_),0..max &#(@_)}
sub char{substr$#_?shift:$_,$_[0],1}
sub via(&$){local $_=$_[1];$_[0]->()}

*\=sub{map[section($_,@_)],0..max &#(@_)};

{my%ops;*?=sub{ref$_[-1]?map&?($_[0],@$_),&\(@_[1..$#_]):wa do{my@z=$_[1];@z=$ops{$_[0]}->($_,@z)for@_[2..$#_];@z}};
{no strict 'refs';(*$_,$ops{$_})=eval"sub{&?('$_',\@_)},sub{wa(\@_[1..\$#_]) $_ \$_[0]}" for qw'** =~ !~ * / % x + - . << >> < > <= >= lt gt le ge == != <=> eq ne cmp & | ^ && || .. ... = , => and or xor'}}
my%refs=(''=>'_',map{$_=>lc substr $_,0,1}qw{SCALAR ARRAY HASH CODE REF GLOB LVALUE});
sub refs{wa map{$refs{ref $_}||'o'}@_}
sub _{cat map{
  is '' ? $_:
  is 'a' ? @{$_[0]}:
  ()
}refs@_}

sub wday{(int(365.25*($_[2]-($_[1]<3)))+int(30.6*(1+$_[1]+12*($_[1]<3)))+$_[0]-621050)%7+1}
sub leap{$_[0]%4?0:$_[0]%100?1:$_[0]%400?0:1}
sub days{(31,(28+leap $_[1]),(31,30,31,30,31)x2)[$_[0]-1]}
sub cal{by 7,((undef)x(wday(1,@_)-1),1..days @_)}

sub all{@_==grep$_,@_}
sub one{1==grep$_,@_}
sub none{!grep$_,@_}
sub any{!&none}

sub import{no strict 'refs';*{caller(0)."::$_"}=${"$_[0]::"}{$_} for grep !/^(BEGIN|__ANON__|a|import)$/, keys%{"$_[0]::"}}

package L2;

use strict;
use qxp;

sub kludges{cat map{(join': ',@$_)."\n"}by 2,@_}

sub tree2(&$@){
  wa map{
    {
      ARRAY=>sub{$_[0]->(1,$_[1],$_[2],cat tree2($_[0],$_[1]+1,@{$_[3]}))},
      ''=>sub{$_[0]->(0,@_[1..3])}
    }->{ref($_->[1])}->(@_[0,1],@$_)
  }by 2,@_[2..$#_]
}

sub templator(&@){
  my($s,%s,%x)=shift;
  my$x=join'|',map{$x{$_->[0]}=quotemeta$_->[1];$s{$_->[0]}=$_->[2];quotemeta$_->[0]}by 3,@_;
  sub{wa map{s;((??{$x}))(.*?)(??{$x{$1}});$s{$1}($2,$_[1]);eg;$_}$s->($_[0])}
}

sub subst{
  my%s=@_;
  my$s=join'|',map quotemeta,keys%s;
  sub{wa map{s/($s)/$s{$1}/eg;$_}copy @_}
}



# 2do: move to module
sub import{no strict 'refs';*{caller(0)."::$_"}=${"$_[0]::"}{$_} for grep !/^(BEGIN|__ANON__|a|import)$/, keys%{"$_[0]::"}}

666;

rtyug добавил 05.12.2009 в 12:01

в php на сколько мне говорили, и на сколько я видел, то наоборот... т.к. доступ к методу через указатель всегда

Пример? Да пожалуйста, почти любая игрушка. Возьмем какую-нить стратегию - массы юнитов с разными характеристиками и умениями, как Вы думаете это реализуеться внутри движка? Обычно есть какой-нить базовый класс, скажем Human, у него есть общие для всех игровых людей свойства, такие как жизнь, сила, скорость передвижения и т д. и умения, вроде двигаться, плавать... От него наследуеться скажем класс Warrior, он обладает теми же свойствами но плюс умеет еще сражаться, носить броню, etc. А теперь вспомните сколькими юнитами Вы оперируете, а есть еще AI, которому тоже нужно управлять игровым процессом. Если Вы создаете 200 воинов, скорее всего "внутри" игры создаеться коллекция обьектов типа Warrior. Когда поступает команда группе людей идти сражаться выполняться что-то вроде:

foreach(HumanIterator hi, SelectedHumans)

   hi.Attack(Enemy);

и метод Attack двигает персонажа к врагу (Enemy) и заставляет их сражаться. При том, что неважно что там в SelectedHumans, хоть Warrior, хоть какой-нить Harvester )

Удобно? Очень.

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

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

За сим откланяюсь, извините, если немного сумбурно получилось.

В саповской библиотеке об ООП речи не идёт, там просто собрали функции в класс.

ООП предполагает:

• Полиморфизм
• Наследование
• Инкапсуляция
• Абстракция данных

Только 3-е используется, и условно.

http://pyha.ru/forum/topic/1648.msg28183#msg28183 - пример.