Снова про ООП

[proWoke]

Я понимаю, что это уже на флуд похоже, но хочется задать вопрос. Вот это уже ООП?

Есть пользовательский тип данных монстры из вакрафта. Он содержит информацию о типе монстра и количество их. Дальше мы можем убивать или воскрешать их через методы kill и revive.

<?

class WС3_Monstrs {

 protected $type;
 protected $count;
 protected $current;

 public function __construct($type,$count=0) {
  $this->type = $type;
  $this->count = $count;
  $this->current = $this->count;
 }

 public function kill($count) {
  $this->current = $this->count - $count;
  if ($this->current < 0) throw new Exception("Вы пытаетесь убить существ больше, чем их есть!");
 }

 public function revive($count) {
  $this->current = $this->current + $count;
  if ($this->current > $this->count) throw new Exception("Нельзя восстановить существ больше, чем их было до битвы!");  
 }

 public function __toString() {
  echo "За битву было убито ".("{$this->count}" - "{$this->current}")." {$this->type}";
 }
}

Используем

<?
require_once "lib/config.php";
require_once "WC3/Monstrs.php";

try {
$fight = new WС3_Monstrs('orc',14);
$fight->kill(1);
$fight->revive(1);
echo $fight->__toString();
}  catch (Exception $e) {  echo $e->getMessage(); }

 

[Духовность™]

Есть пользовательский тип данных монстры из вакрафта

Он реально есть или ты задачи на ходу придумываешь?

 

[proWoke]

Он реально есть или ты задачи на ходу придумываешь?

Кто есть? Вопрос не понял, но задачу просто придумал, что теоретически можно построить какого нить монстра в игре в количестве n и пойти им воевать.

 

[c0dex]

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

 

[Духовность™]

Давай обойдемся без монстров и убийств. Создай для начала интерфейс объекта человека и создай мужчину, наследующего этот интерфейс. Выложи тут код. Если получится - создадим потом ещё женщину и научим их делать детей.

 

[Вурдалак]

WC3 forever!

 

[proWoke]

Давай обойдемся без монстров и убийств. Создай для начала интерфейс объекта человека и создай мужчину, наследующего этот интерфейс. Выложи тут код. Если получится - создадим потом ещё женщину и научим их делать детей.

Я понял это так:

 interface Human {
  public function born ();
 }
interface Men extends Human {
 public function train(); 
}

WC3 forever!

Да уж..

 

[Вурдалак]

Создай для начала интерфейс объекта человека и создай мужчину, наследующего этот интерфейс

— нахрена? На таких абстрактных примерах далеко не уедешь. Резонный вопрос: а нахрена? А нахрена создавать интерфейс?

 

[Духовность™]

На таких абстрактных примерах далеко не уедешь.

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

А нахрена создавать интерфейс?

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

Я понял это так:

 interface Human {
  public function born ();
 }
interface Men extends Human {
 public function train(); 
}

Стоп. У тебя разве есть метод Born? Что это за метод такой? Как ты представляешь этот метод на реальном человеке? А метод train? - это что такое?

Давай лучше так:

interface Human {
  public function go($lengthInMeters); // умеем ходить на заданную длину метров $lengthInMeters
  public function relax(); // отдыхаем, ничего не делаем (стоим, лежим)
 }

Теперь надо добавить свойства - рост, вес, пол. Сделаешь?

 

[флоппик]

А мне понравилась идея с монстрами, набросал кусочек ООП:
https://gist.github.com/809180

Использовать можно было бы примерно так:

<?php

$andy = new Skeleton();
$pierre = new Death_Magican();
$angus = new Human_Hero();

$angus->put_on_fire($andy);
$andy->attack($angus);
try {
  $pierre->magic_attack(angus);
} catch (Exception $e )
{
  echo $e->getMessage();
}
?>

По этому коду видно немножко Правильного ООП™. Ну, и немножко неправильного, впрочем.

 

[craz]

abstract class Attack_Type {
// Basic types
const PIERCING = 1;
const CUTTING = 2;
const BLUNT = 4;
const FIRE = 8;
const WATER = 16;
const ICE = 32;
const EARTH = 64;
const LIFE = 128;
const DEATH = 256;

}

а зачем так делать? че за патерн?

 

[HraKK]

craz
Убираем magic numbers.

 

[флоппик]

Там по идее было по маске, можно было несколько типов одновременно указывать, типа

$this->attack = Attack_Type::DEATH & Attack_Type::FIRE;

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

 

[craz]

craz
Убираем magic numbers.

не понял(

 

[craz]

Там по идее было по маске, можно было несколько типов одновременно указывать, типа

$this->attack = Attack_Type::DEATH & Attack_Type::FIRE;

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

короче это как раз

Ну, и немножко неправильного, впрочем.

дя?

 

[флоппик]

Соответственно, можно сделать было:
MAGIC_DEFENCE = AT:EATH & AT::LIFE & AT::FIRE .... и т.д., что бы описать защиту от любой магии. Ну или то же самое для защиты от физ. атак.

 

[флоппик]

Нет, это правильное, просто лишнее для понимания. Битовые операции не тема этого кода

А неправильное там — хардкодить в конструкторах HP и MP. Там надо вводить еще один тип, что то вроде Unit_Stats и передавать его в конcтруктор.
Соотвественно, для всяких сравнений тоже пользоваться этим объектом. Но для короткого кода это тоже сложно для понимания будет.

 

[Духовность™]

не понял(

числа не должны быть явно прописаны в коде.

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

 

[whirlwind]

Нас окружают не просто объекты, нас окружают модели взаимодействия. И проектирование надо начинать не с деталей объектов, а с деталей взаимодействия объектов. Непродуманная модель взаимодействий приводит к Big_ball_of_mud. Архитектура разрабатывается сверху, а реализуется снизу. А вы пытаетесь наоборот - разработать архитектуру от объектов, а не от связей. Это интеллектуальное изнасилование модели.

 

[флоппик]

Ну, автор не совсем полный имбецил. Что-то пишет, пытается. Значит, читать — в состоянии. Не поймет, так спросит. А предметную область он сам выбрал, значит она ему близка.
Так же, игры как раз удобнее всего для таких объяснений — они достаточно прочно вошли в жизнь, что бы их «правила» понимались интуитивно, но при этом они изначально заточены под программирование, и хорошо «раскладываются» на объекты.