Всё так связано, что одни и те же слова возымеют разные результаты только от того, что их произнесли люди различного духовного уровня и различного душевного расположения.
Люди опытные, глубокие и любящие просто скажут одно-два слова, и этого уже будет достаточно - в этих одном-двух словах будет рождаться всё необходимое.
понедельник, 5 января 2009 г.
После этих слов из Евангелия от Иоанна гностицизм не выдерживает никакой критики, потому что получается, что Книга сама свидетельствует против её частичных почитателей:
Духа Божия и духа заблуждения узнавайте так: всякий дух, который исповедует Иисуса Христа, пришедшего во плоти, есть от Бога; а всякий дух, который не исповедует Иисуса Христа, пришедшего во плоти, не есть от Бога, но это дух антихриста, о котором вы слышали, что он придет и теперь есть уже в мире.
(1 Ин 4:2-3)
вторник, 30 декабря 2008 г.
Парадоксы...
Уход от индивидуальности делает человека глубже и уникальнее, раскрывает его сущность, а стремление к индивидуальности приводит человека к однородному пестрению, такому, что человека можно вполне справедливо отнести к какому-нибудь психотипу, предсказать его поведение, потому что он становится обсуловленным, теряя возможность выбирать.
Уход вниз - это всегда одновременно и подъём вверх, потому что нет низа и верха, есть глубина и широта.
Уход вниз - это всегда одновременно и подъём вверх, потому что нет низа и верха, есть глубина и широта.
А "восшел" что означает, как не то, что Он и нисходил прежде в преисподние места земли?
Нисшедший, Он же есть и восшедший превыше всех небес, дабы наполнить все.
(Еф. 4.9-10)
пятница, 26 декабря 2008 г.
Доменные объекты - это такие объекты, которые выражают в программе сущности из предметной области. Например, "сотрудник", "заказ", "рабочая группа", "здание", доменные объекты могут быть и более абстрактными - "тип материала", "единица измерения". Программисты, используя парадигму ООП (объектно-ориентированного программирования), стараются сводить написание кода к таким вот доменным объектам, абстрагируясь от более подробного уровня детализации, обусловленного самим языком. Доменные объекты могут обслуживаться обычными объектами, т.е. не имеющими представления в предметной области, но необходимыми для реализации программы, такими объектами могут быть, например, адаптеры базы данных.
Поскольку доменные объекты надо где-то хранить, они обычно представлены в системе в двух разных формах: программной в виде рабочего объекта, обладающего как атрибутами, так и методами, и фиксированной форме, т.е. такой, которая удобна для хранения и содержит всю необходимю информацию для восстановления объекта в том состоянии, в котором он был сохранён. Под состоянием подразумевается вся совокупность атрибутов объекта. Как правило, объекты хранятся в базе данных, но в роли хранилища может выступать и файл какого-нибудь формата.
По причине того, что формы существования объекта отличаются, программисту необходимо иметь инструменты для их двустороннего преобразования: из программной формы в фиксированную и обратно. Одним из механизмов такого преобразования является ORM (object relational mapping - "объектно-ориентированная проекция"), т.е. такая структура объектов, которая позволяет программисту абстрагироваться и от базы данных тоже. С точки зрения программы, объекты всегда остаются объектами.
Доменный объект хранит какие-то атрибуты, определяемые его классом. Эти атрибуты могут быть типизированы, хранить информацию о том, как их надо извлекать из внешнего хранилища и т.п. В плохих реализациях ORM информация об атрибуте "таскается" вместе со значением атрибута (описание и значение сливается в один объект во время инстанцирования). Это неблаготворно сказывается на объёме занимаемой оперативной памяти, потому что информация об атрибуте может быть весьма обширной, а экземпляров объекта может быть много сотен, а то и тысяч.
К сожалению, в языке PHP очень плохо продумана работа со статическими методами (эту проблему частично обещают исправить в версии 6.0), поэтому крепить информацию об атрибутах к классу неудобно (разве что создавать гигантский ассоциативный массив у самого главного родительского класса), значительно приятнее было бы иметь карту данных (совокупность описаний атрибутов) всегда под рукой у любого экземпляра доменного объекта, но при этом не хранить её в нём.
И тут нам на помощь приходит такая вещь, как статическая переменная внутри метода. Методом владеет каждый экземпляр класса, а вот статическая переменная в нём хранится одна на весь класс. Почти тем же приёмом пользуются, когда проектируют класс по паттерну Singleton.
Потомок такого класса может выглядеть как-нибудь так:
Сразу после инстанцирования экземпляра объекта DomainObjectRack, мы всегда как извне, так и изнутри можем обратиться к описанию его внутренней структуры.
Поскольку доменные объекты надо где-то хранить, они обычно представлены в системе в двух разных формах: программной в виде рабочего объекта, обладающего как атрибутами, так и методами, и фиксированной форме, т.е. такой, которая удобна для хранения и содержит всю необходимю информацию для восстановления объекта в том состоянии, в котором он был сохранён. Под состоянием подразумевается вся совокупность атрибутов объекта. Как правило, объекты хранятся в базе данных, но в роли хранилища может выступать и файл какого-нибудь формата.
По причине того, что формы существования объекта отличаются, программисту необходимо иметь инструменты для их двустороннего преобразования: из программной формы в фиксированную и обратно. Одним из механизмов такого преобразования является ORM (object relational mapping - "объектно-ориентированная проекция"), т.е. такая структура объектов, которая позволяет программисту абстрагироваться и от базы данных тоже. С точки зрения программы, объекты всегда остаются объектами.
Доменный объект хранит какие-то атрибуты, определяемые его классом. Эти атрибуты могут быть типизированы, хранить информацию о том, как их надо извлекать из внешнего хранилища и т.п. В плохих реализациях ORM информация об атрибуте "таскается" вместе со значением атрибута (описание и значение сливается в один объект во время инстанцирования). Это неблаготворно сказывается на объёме занимаемой оперативной памяти, потому что информация об атрибуте может быть весьма обширной, а экземпляров объекта может быть много сотен, а то и тысяч.
К сожалению, в языке PHP очень плохо продумана работа со статическими методами (эту проблему частично обещают исправить в версии 6.0), поэтому крепить информацию об атрибутах к классу неудобно (разве что создавать гигантский ассоциативный массив у самого главного родительского класса), значительно приятнее было бы иметь карту данных (совокупность описаний атрибутов) всегда под рукой у любого экземпляра доменного объекта, но при этом не хранить её в нём.
И тут нам на помощь приходит такая вещь, как статическая переменная внутри метода. Методом владеет каждый экземпляр класса, а вот статическая переменная в нём хранится одна на весь класс. Почти тем же приёмом пользуются, когда проектируют класс по паттерну Singleton.
abstract class DomainObject {
#...
public function get_map() {
static $map;
if (! $map) {
$map = $this->config();
self::check_map($map);
}
return $map;
}
abstract protected function config();
#...
}
Потомок такого класса может выглядеть как-нибудь так:
require_once 'class.DomainObject.php';
class DomainObjectRack extends DomainObject {
protected function config() {
$map = self::create_map();
$map->add(new APrototype('id', 'ID', 'fixnum'));
$map->add(new APrototype('name', 'NAME', 'string'));
$map->add(new APrototype('is_active', 'ACTIVE', 'bool'));
return $map;
}
}
Сразу после инстанцирования экземпляра объекта DomainObjectRack, мы всегда как извне, так и изнутри можем обратиться к описанию его внутренней структуры.
class TestDomainObjectRack extends UnitTestCase {
public function test_same_map() {
$rack = new DomainObjectRack();
$other_rack = new DomainObjectRack();
$this->assertReference($rack->get_map(), $other_rack->get_map());
// это один и тот же объект, но внутри экземпляра его нет
$this->dump($rack);
// дамп объекта не покажет нам карты данных, поскольку она доступна
// только из метода
}
}
понедельник, 22 декабря 2008 г.
Машины на тротуарах
Есть такая проблема: автомобилистам некуда ставить свои машины, потому что а) не предусмотрено достаточное количество бесплатных парковочных мест, б) не предусмотрено строительство гаражей и пр.
Что делают автомобилисты? Ставят свои авто на любое свободное место: на тротуары, на газоны, на въезды в переулки (а на дороге - на остановки, на пешеходные переходы). Это, разумеется, противозаконно и бесчеловечно по отношению к пешеходам.
Ведь, допустим мама с ребёнком идёт вдоль дома. Где им идти, если машины заняли весь тротуар? По дороге. А по дороге едут автомобили, даже не притормаживая, когда проезжают мимо людей. Ребёнок может рвануться и попасть под колёса, мать может сделать шаг в сторону, не услышав машины, и оказаться сбитой. Машины на тротуарах - это всё равно, как если бы дороги строили без тротуаров вовсе. Это очень опасно (особенно зимой, когда можно поскользнуться и уехать ногами под проезжающий мимо автомобиль).
Хорошо бы взять, да и убрать все машины с тротуаров (по закону они не имеют права на нём стоять, кроме особых случаев). Но этого никто делать не будет: есть привычка, да и водители возмутятся "Куда же нам ставить свои авто, если для них не предусмотрено место?"
И тут имеет место подмена понятий. Если будущему водителю некуда ставить свою машину, он не должен её покупать. Да, это проблема, но это проблема водителей и государства, она должна решаться только на этой линии. А происходит иначе: машина покупается, государство -- "причина проблемы", но страдать будут пешеходы, потому что с пешеходами либо не надо, либо легче препираться, чем с государством.
Эта поразительная подмена понятий стоит многим жизней и здоровья, ну, и почти всем приходится ежедневно мириться с неудобством, когда ты лавируешь между проезжающими машинами, теснишься, пытаешься выгадать, кто куда поедет, вжимаешься в грязные дверцы.
А какова, как правило, причина покупки машины? Так ли нам нужно столько машин? И каких? Легковой автомобиль обычно расчитан на 4 посадочных места, из которых ежедневно используется только одно--два. Всё остальное пространство, как на парковочных местах, так и на дорогах занимается впустую. А как обычно используются машины? Обычно, считается, что на машине ездят на работу (в условиях Москвы это ничуть не быстрее общественного транспорта, зато дороже и иногда дольше). Но обычно покупка машины является только способом скрыться от какой-то внутренней проблемы.
Что делают автомобилисты? Ставят свои авто на любое свободное место: на тротуары, на газоны, на въезды в переулки (а на дороге - на остановки, на пешеходные переходы). Это, разумеется, противозаконно и бесчеловечно по отношению к пешеходам.
Ведь, допустим мама с ребёнком идёт вдоль дома. Где им идти, если машины заняли весь тротуар? По дороге. А по дороге едут автомобили, даже не притормаживая, когда проезжают мимо людей. Ребёнок может рвануться и попасть под колёса, мать может сделать шаг в сторону, не услышав машины, и оказаться сбитой. Машины на тротуарах - это всё равно, как если бы дороги строили без тротуаров вовсе. Это очень опасно (особенно зимой, когда можно поскользнуться и уехать ногами под проезжающий мимо автомобиль).
Хорошо бы взять, да и убрать все машины с тротуаров (по закону они не имеют права на нём стоять, кроме особых случаев). Но этого никто делать не будет: есть привычка, да и водители возмутятся "Куда же нам ставить свои авто, если для них не предусмотрено место?"
И тут имеет место подмена понятий. Если будущему водителю некуда ставить свою машину, он не должен её покупать. Да, это проблема, но это проблема водителей и государства, она должна решаться только на этой линии. А происходит иначе: машина покупается, государство -- "причина проблемы", но страдать будут пешеходы, потому что с пешеходами либо не надо, либо легче препираться, чем с государством.
Эта поразительная подмена понятий стоит многим жизней и здоровья, ну, и почти всем приходится ежедневно мириться с неудобством, когда ты лавируешь между проезжающими машинами, теснишься, пытаешься выгадать, кто куда поедет, вжимаешься в грязные дверцы.
А какова, как правило, причина покупки машины? Так ли нам нужно столько машин? И каких? Легковой автомобиль обычно расчитан на 4 посадочных места, из которых ежедневно используется только одно--два. Всё остальное пространство, как на парковочных местах, так и на дорогах занимается впустую. А как обычно используются машины? Обычно, считается, что на машине ездят на работу (в условиях Москвы это ничуть не быстрее общественного транспорта, зато дороже и иногда дольше). Но обычно покупка машины является только способом скрыться от какой-то внутренней проблемы.
пятница, 19 декабря 2008 г.
Не могу понять страсть некоторых программистов помечать приватные и защищённые переменные и методы класса ведущим нижним подчёркиванием (
$_data, $_createMap() и т.п.). Это может сказаться на проекте так же отрицательно, как использование префиксации для обозначения типов данных (arItems, intPrice, strBeginDate и т.п.), поскольку название переменной содержит дополнительную информацию, которая может поменяться во время разработки проекта. В этом случае придётся менять название переменной всюду, где она встречается.
Подписаться на:
Сообщения (Atom)