Структура vs класс

>то может лучше было бы изменить процедуру инициализации объекта

В описываемом примере бэкенд данных у каждого объекта, инициализируемого через ORM свой. Одни объекты инициализируются из БД, другие из файловой системы, третьи из Интернета. Т.е. есть отдельный метод storage(), возвращающий класс-загрузчик. Но, естественно, это всё скрыто в фабрике объектов. Даже сохранение результата модификации. То есть я пишу, скажем:

$design_bureau = object_load('design_bureau', 125);
$design_bureau->set_country($data['country'], true);

Всё. Первая строчка создаст объект, указываемый по ID=125, проинициализирует нужными данными, сохранит в кеше для будущего использования и т.д. и т.п.

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

После завершения работы скрипта (напомню, речь идёт о PHP, тут каждая операция имеет момент завершения) автоматически сохранятся все изменения.

В критичных местах, понятно, можно запрещать кеширование, сохранять принудительно в заданные моменты, защищаться от конфликтов модификации в параллельных процессах семафорами и т.п. Но в 99% случаев всё этого не требуется. Зато работа на высоком уровне упрощается чрезвычайно.

Аналогичную систему (с поправкой на лишний код из-за статичности языка) планировал и в Java вводить, но проект распался раньше, чем я успел заняться автоматизацией работы с объектами. Так и осталось отложенным в долгий ящик, там всё вручную делать приходилось.

>Ведь в момент присваивания далеко не все проверки можно выполнить, правильность поля может зависеть и от других полей.

Поэтому есть методы, типа pre_process(&data), post_process(&data), наконец, можно переопределять сам storage_engine расширяя его функционал в нужную сторону. Наследование - не всегда зло :)

> а в варианте 2?

а в варианте 2 эта функция будет работать только с классом Town, и потроха класса User ей будут до лампочки

и какое это вообще имеет отношение к обсуждаемой теме?

как минимум вариант 2 упростит рефакторинг класса User — я уже написал

еще вполне возможно эту функцию придется сделать приватной для Town, и в случае варианта 1 придется ее френдить еще и к User-у. офигеть как красиво.

- как минимум вариант 2 упростит рефакторинг класса User — я уже написал

+ как минимум вариант 2 упростит модификацию класса User — я уже написал

> Аналогичную систему (с поправкой на лишний код из-за статичности языка) планировал и в Java вводить, но проект распался раньше, чем я успел заняться автоматизацией работы с объектами. Так и осталось отложенным в долгий ящик, там всё вручную делать приходилось.

подозреваю что можно и без лишнего кода (на дженериках)

$design_bureau->set_country($data['country'], true);

если уж говорить о РНР, то там ЕМНИП с 5 (и бэкпортированы в дебиане (?) в 4) есть возможность переопределять сеттеры и аксессоры

$persistent->design_bureau->country = $data['country'];

>подозреваю что можно и без лишнего кода

В Яве нельзя обойтись (не потеряв слишком производительность) без явного описания методов. Соответственно, геттеры и сеттеры должны быть описаны явно, что в отсутствии готовых кодогенераторов усложняет код.

Я планировал решать этот вопрос на JBForth2, генерируя классы на лету. Сейчас это сделать проще, так как в Java появилась возможность компиляции в рантайме. Но, в любом случае, пока стимулов к оживлению проекта нет :) А других проектов на Java пока не ожидается. Как впрочем, вообще проектов вне Web'а :)

>есть возможность переопределять сеттеры и аксессоры

Есть. Но производительность падает и сильно. И потом не соптимизирвать. Скажем, если класс пишется вручную и меня ломает описывать метод, то $object->set_country(...) у меня будет работать (через __call(..)) независимо от наличия такого метода в классе. Пусть и тоже ценой падения производительность (но меньше, чем с __set(...)). Это позволяет быстро написать и оттестировать код, не заморачиваясь ручной работой и копипастой. Если же профайлинг потом покажет (или это будет очевидно сразу), что данный объект будет инициализироваться/читаться слишком часто, то делом считанной минуты будет прогнать сорец класса через скрипт, который допишет все недостающие геттеры/сеттеры сам. Логика от этого не изменится ни в малейшем, зато будет быстро и на уже просто написанном/отлаженном классе.

> А в редких случаях, когда нужно отличить существительное от глагола использую префиксы do или on. Типа, do_job() (а, да, ещё предпочитаю snake_style :) - это ближе к естественному языку)

прям Command/Query Separation Principle, только в эйфеле это похоже получилось неудачно, а вот такой вариант мне нравится

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

не понял, что за скрипт?

> http://typicalprogrammer.com/?p=23

Correct object-oriented design requires an object to encapsulate and hide its data, and to expose methods that are verbs acting on the object (not on individual properties of the object).

ООП-шный наивняк. Если бы так было всегда, SQL бы давно умер.

Достаточно дописать в конце $design_bureau->save(), где и реализовать все проверки и сохранение. А перед этим использовать простые присваивания. Если их будет десяток, то мы в десять раз меньше насилуем базу.

Хотя насчет базы и не очевидно. Как говорится, преждевременная оптимизация. Зато код прозрачнее.

> Correct object-oriented design requires an object to encapsulate and hide its data, and to expose methods that are verbs acting on the object (not on individual properties of the object).

если быть более точным, то:

да, на первом шаге к этому Correct object-oriented design надо стремится

но на втором шаге, когда выяснилось, что individual properties of the object все-таки нужны, возникает вопрос топикстартера

> Аналогичную систему (с поправкой на лишний код из-за статичности языка)

Мне было бы очень интересно обсудить «аналогичную систему».

Для меня — с точки зрения «каким должен быть статически типизированный язык, чтобы лишнего кода в этой ситуации *не было* ».

Для тебя... тут надо придумать зачем :-)

Мне было бы очень интересно обсудить «аналогичную систему».
Для меня — с точки зрения «каким должен быть статически типизированный язык, чтобы лишнего кода в этой ситуации *не было* ».

Я думал о кодогенерации по Java-файлу. Скажем, на PHP в моём фреймворке для описания записи в блоге будет использоваться такая структура:

<?php

class blog_record extends base_page_db
{
    function main_table() { return 'blog_records'; }
    function main_table_fields()
    {
        return array(
            'id',
            'title',
            'create_time',
            'source',
        );
    }
}

В принципе, этого уже достаточно, для использования объекта.

$blog = object_new_instance('blog_record', array('title' => 'Hello!', 'source' => 'Это тест!'));

$blog = object_load('blog_record', 17);
$blog->set_title('А тут мы отредактировали', true);

То есть профит в том, что нам не нужно описывать переменные класса, не нужно описывать методы для них (с учётом того, что даже вышеописанное нередко генерится кодогенератором, то для нашей лени вообще всё роскошно становится).

На Java такой подход в лоб не прокатит, так как статическая типизация требует явного описания переменных и методов доступа к ним.

Но у нас такое описание уже присутствует, хотя бы, в перечислении полей БД.

Следовательно, можно слепить некий препроцессор, который будет генерировать нам на упрощённом описании полноценные классы. Как я уже говорил, я планировал использовать для этого так и ненаписанный JBForth2, который бы генерировал Java-байткод, но сейчас это излишне, так как в Java появились механизмы байткомпиляции на лету. Т.е. можно тупо дописать в наш сорец отсутствующие компоненты, скомпилировать результат, сохранить его в .class или .jar, добавить результат в class path и собирать уже оставшуюся часть системы.

Разумеется, это делать надо не вручную, а каким-нибудь ant'ом, повесив препроцессинг на отдельные расширения, в которых и писать эти упрощённые классы.

В общем, на практике этим не занимался, как уже и отмечал, но препятствий навскидку не вижу.

...

Кстати, с препроцессором даже без байткодогенерации можно обойтись - просто сохранять полученные «полные» Java-файлы в отдельную иерархию, с которой уже и компилировать основной проект.

...

Хотя будут вылезать трудности при подключении произвольных классов с произвольными полями в уже работающую систему. Тут, наверное, без потери на reflection уже не обойтись.

но на втором шаге, когда выяснилось

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

> сеттер для размера контейнера смысла не имеет

4.2

4.2

примеры будут?

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

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

Также у человека как правило бывают (обычно, ложные) представления об изоляции частей и о том, какие части он потом будет менять. Соответственно, в структуре проекта возникают шлейфы и разъёмы, где можно было бы сделать просто печатную плату. Это тоже усложняет дело.
При этом, пользователю выдаётся весьма ограниченный интерфейс, с расчётом на то, что он потом будет изменён. Тем самым, обобщённые решения начинают проигрывать в конкурентном соревновании.

Как правило, в итоге выясняется, что расширять придётся в другую сторону, шлейфы и разъёмы бывают нужны, но не в тех местах, где они были заложены, на изменение второстепенных вещей вообще не остаётся сил или вдохновения (а потом и страшно трогать то, что работает). Пользователь остался с убогим интерфейсом, рассчитанным на всевозможную не имеющую будущего гибкость и являющимся общим знаменателем всех частично совместимых между собой компонент, но выучил хаки, использующие разного рода недокументированные возможности. И со временем даже перестал трястись над тем, что завтра всё изменится.

В т.ч., я столкнулся с подобной ситуацией и в Qt, когда мне пришлось копипастить «правильно спроектированные» приватные классы (слава Богам, что хотя бы исходники доступны). За счёт «правильного проектирования» кода получилось в полтора раза больше, зато функций - в полтора раза меньше.

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

Я не говорю, что всё обязательно действительно так плохо и ничего нельзя предсказать. Но это довольно типично. Что-то у меня сегодня ворчливое настроение.

> инициализируемого через ORM свой. Одни объекты

инициализируются из БД, другие из файловой системы,

третьи из Интернета

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

Примеры реальных трудностей:
1. Загрузка из файла практически гарантирована. С СУБД в конкурентной среде это чуть сложнее. В случае с интернетом - вообще нет гарантии, и нужно распараллеливать процесс загрузки, если медленное соединение.
2. Для эффективной работы с СУБД нужно загружать не весь объект, а только некоторые поля, нужные для конкретного алгоритма. Итерация по множеству пар объектов (a,b), где a ссылается на b, делается одним sql запросом, но в ORM нужно очень сильно извратиться, чтобы это выразить. Нужен, фактически, компилятор, который проанализирует весь доступ к данным в пределах функции, определит набор полей, нужных таблиц и соответствующие join's. Или то же самое делать вручную (а чем тогда хуже просто чистый SQL). Если этого не делать, то потери производительности будут просто катастрофичны. То, что делается по-нормальному одним запросом, будет в ORM делаться тысячей и одним запросом.

В общем, бросьте это безнадёжное дело!

>В случае с интернетом - вообще нет гарантии, и нужно распараллеливать процесс загрузки, если медленное соединение.

Здравствуйте, Кэп, не узнал Вас на этом логине. Да, всё перечисленное верно. И что?

Для эффективной работы с СУБД нужно загружать не весь объект, а только некоторые поля, нужные для конкретного алгоритма.

1. Да сколько угодно. Даже хитростей никаких не придётся предпринимать. Просто вместо общего чтения всего объекта через ORM будут грузиться поля при обращении.

2. Это совершенно не так. При загрузке всего объекта сразу - мы все поля получим одним запросом. При загрузке по полям - по запросу на каждое поле. Где выгода-то?

Итерация по множеству пар объектов (a,b), где a ссылается на b, делается одним sql запросом, но в ORM нужно очень сильно извратиться, чтобы это выразить

У меня просто один простой запрос сменяется двумя простыми. Подобный механизм используется очень часто - скажем, owner для каждого post.

Нужен, фактически, компилятор

KISS.

и соответствующие join's

Почти всегда один JOIN'овый запрос работает дольше двух простых. Иногда разница бывает просто огромная.

Если этого не делать, то потери производительности будут просто катастрофичны.

Да-да. Уж в скольких чужих проектах я ускорял систему, избавляясь от JOIN'ов...

То, что делается по-нормальному одним запросом, будет в ORM делаться тысячей и одним запросом.

Только в Вашем представлении.

В общем, бросьте это безнадёжное дело!

Да я за такой безнадёжный вариант, как у Вас и не возьмусь. Зачем, когда есть простые, быстрые и надёжные решения?

Пример со стеком был выше. Если нужно сократить стек, выкинув данные, будет setSize().

Пример со стеком был выше

сколько ты знаешь структур данных, в которых это имеет смысл? в скольких стандартных библиотеках вообще есть такие структуры данных?

да, размер может входит в интерфейс контейнера как свойство - однако это исключение, а не правило

[История успеха] Вот так внезапно человек открыл принцип KISS.

Эксперты в таких случаях рекомендуют писать shrink, drop или remove. Хотя для стека все же правильно писать pop.

>Кроме того, у человека в начале проекта бывают (обычно, ложные) представления о том, в какую сторону он будет его расширять

Есть два шага на пути избавления от этой болезни:

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

2. Осознать принципиальное отсутствие в надобности в наследовании вообще.

После этих двух шагов находит просветление и ООП используется только по прямому назначению.

> в скольких стандартных библиотеках вообще есть такие структуры данных?

В стандартных библиотеках такие АТД не нужны.

сколько ты знаешь структур данных, в которых это имеет смысл?

Это зависит не от структуры данных, а от её назначения.

однако это исключение, а не правило

Да, разумеется.

> Осознать отсутствие надобности в множественном наследовании

Осознать принципиальное отсутствие в надобности в наследовании вообще.

Конкретно в плюсах наследование от абстрактного предка - способ реализации интерфейса. А интерфейсы нужны, да. Без них грустно.

Это зависит не от структуры данных, а от её назначения.

да ну? интересная точка зрения

>Почему использование функций предпочтительнее?

Потому что Ъ. Области доступа там, контроль за изменением переменной и тд. Допустив в get можно еще вставить счетчик для отладки. А структуры это процедурное программирование, если не следуешь строго канонам ООП и текст небольшой то структуры будут работать на порядок быстрее и код будет попроще.

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

я уже 1 пример привел (посчитать расстояние между юзерами и стоимость посылки между ними), приведу еще:

2. посчитать, сколько юзеров в первых 10 городах, где их больше всего

3. (допустим, у нас есть еще и магазины) посчитать количество городов, где юзера есть, а магизинов — нет

и т.д. можно придумывать по аналогии с любым SQL запросом

_______________________________

все это может быть переделано «под ООП», но тогда в примере 2 тебе придется иметь класс Город, и делать Юзер и Магазин производными от него, и повторение такой финт для многих полей привет к множественному наследованию

_______________________________

все это может быть переделано «под ООП», но тогда в примере 3 тебе придется иметь класс Город, и делать Юзер и Магазин производными от него, и повторение такого финта для многих полей привет к множественному наследованию // FIXED

> все это может быть переделано «под ООП»,

Вообще-то в ООП есть не только наследование. Relationships в нем тоже есть.

>класс Город, и делать Юзер и Магазин производными от него

Ё-маё, ну и бред. А И.Ф. Крузенштерна тогда надо делать производным от парохода. И человека.

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

можно, конечно, вырезать гланды автогеном. но зачем?

>но тогда в примере 3 тебе придется иметь класс Город, и делать Юзер и Магазин производными от него

Вот поэтому я в http://www.linux.org.ru/jump-message.jsp?msgid=4464779&cid=4477923 и привёл оба пункта :) До какого-то момента тоже хотелось множественного наследования, и даже совсем недавно: http://www.linux.org.ru/view-message.jsp?msgid=2041488

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

...

Юзер и Магазин должны иметь свойство-класс Город (или более общий Место_Жительства), но ошибка - считать их наследниками места жительства.

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

я объяснял тебе, откуда беруться требования иметь доступ к полям

> Юзер и Магазин должны иметь свойство-класс Город (или более общий Место_Жительства), но ошибка - считать их наследниками места жительства.

тут честно говоря все тоже не очень просто

конечно, в реальном проекте на с++ я бы не делал тут множественное наследование, однако рассмотрим 2 задачи:

1. найти 10 городов где количество юзеров максимально

2. найти 10 городов где количество магазинов максимально

очевидно их сходство :-)

в случаей свойств (без мн. насл.) на с++ можно эти две задачи решить 1 шаблонной функцией, на яве — невозможно, т.е. ява тут потребует мн. насл.

(с другой стороны, в шаблоны плюсов могут быть менее устойчивы)

>1. найти 10 городов где количество юзеров максимально

2. найти 10 городов где количество магазинов максимально

очевидно их сходство :-)

Угу. И если это часто используемая задача, требуется высокая производительность, не хочется мараться о прямую работу с SQL, то я в таком случае просто в объекте Город ввожу поля ЧислоПользователей и ЧислоМагазинов. Пересчёт этих полей вызываю на каждом сохранении объектов Пользователь или Магазин (или прямой вызов или через механизм связывания кеш-групп) и тогда задача становится тривиальной:

$top10_cities_by_users = objects_array('city', array('order' => '-num_users', 'limit' => 10));

или

$top10_cities_by_stores = objects_array('city', array('order' => '-num_stores', 'limit' => 10));

Действительно, механизм работы сходный :D И наследование нигде не фигурирует даже одиночное :)

> Ё-маё, ну и бред. А И.Ф. Крузенштерна тогда надо делать производным от парохода. И человека.

речь шла именно о том, что такой подход заходит в что-то, похожее на тупик :-)

> Вообще-то в ООП есть не только наследование. Relationships в нем тоже есть.

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

Критерием «есть или эмуляция» предлагаю выбрать такой: если ни одно наименование класса, переменной, ... не повторяется лишний раз, то фича есть, иначе — эмуляция.

Далее, предположим что с++/ява поддерживают ООП (пора бы ведь уже! 30+ лет прошло)

Если бы было можно записать:

class User {...};
class Town {...};
relationship_one Town to_many User;

или хотя бы

class User {...};
class Town {...};
relationship1N<Town::*user, User::*town>;

то тогда можно было бы сказать, что «ООП поддерживает Relationships», иначе — эмуляция.

Все равно есть возражения:

1. с++/ява с шаблонами уже больше, чем ООП

2. сходу не скажу, можно ли не повторять названия классов, или потребуется:

class User {...};
class Town {...};
relationship1N<Town,Town::*user, User,User::*town>;

> Юзер и Магазин должны иметь свойство-класс Город (или более общий Место_Жительства), но ошибка - считать их наследниками места жительства.

Зачем решать все задачи, используя ООП? Особенно те, где ООП совсем не нужно. Неужели ещё кто-то считает, что ООП — серебряная пуля?

>Зачем решать все задачи, используя ООП?

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

Дрова колоть хорошо топором, а суп варить - из картошки.

> Зачем решать все задачи, используя ООП? Особенно те, где ООП совсем не нужно. Неужели ещё кто-то считает, что ООП — серебряная пуля?

Вот и 2-й человек не понял, о чем я говорил, так как (видимо) не рассмотрел контекст.

Началось все с jtootf, скавшего «поля/геттеры/сеттеры не нужны, так как плохой дизайн», я продемонстрировал задачи, где надо либо вводить поля/геттеры/сеттеры, либо (если поупорствовать в подходе наивного ООП) заменять их сетью множественного наследования.

> Все задачи решать с помощью ООП глупо. Но также глупо избегать ООП там, где оно даёт существенный выигрыш в скорости разработки, надёжности, расширяемости.

Ага, но если человек «знает» ООП и ничего больше, то у него ничего не остаётся, кроме как решать с «существенным выигрышем в скорости разработки, надёжности, расширяемости» на его любимом языке и с помощью ООП в понимании этого человека.

Дрова колоть хорошо топором, а суп варить - из картошки.

Взявший в руки молоток видит кругом гвозди.

В первой половине треда ты защищал свой код и пытался предложить «сделать красиво», переписав только один класс. Хотя сам же прекрасно понимаешь, что это невозможно. Особенно, если «система» сделана «криво»

> Вот и 2-й человек не понял, о чем я говорил, так как (видимо) не рассмотрел контекст.

Видимо ты недостаточно точно сформулировал свою мысль

Началось все с jtootf, скавшего «поля/геттеры/сеттеры не нужны, так как плохой дизайн», я продемонстрировал задачи

Задачи? Ты предложил задачу и сам же предложил вариант решения. Я не могу назвать это «задачей»

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

Ну-ну. Я забыл, мы уже выяснили или ещё нет, что нет «нормальных» ООП языков, которым по плечу «настоящий» ООП без кучи ad-hoc вещей?

> Задачи? Ты предложил задачу и сам же предложил вариант решения. Я не могу назвать это «задачей»

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

Я забыл, мы уже выяснили или ещё нет, что нет «нормальных» ООП языков, которым по плечу «настоящий» ООП без кучи ad-hoc вещей?

не выясняли

можешь определить свой «настоящий» ООП

Ты выдумал задачу, сам же решил, и сам сделал выводы на основе своего решения. Отличный способ показать свою правоту %)

> > Я забыл, мы уже выяснили или ещё нет, что нет «нормальных» ООП языков, которым по плечу «настоящий» ООП без кучи ad-hoc вещей?

не выясняли

можешь определить свой «настоящий» ООП

Не могу. Это был стёб. Серебрянной пули нет. Разве что писать по DSL на каждую задачу.

Тут люди обсуждают непонятно что, и это что-то называют «ООП», причём каждый до сих пор говорит о своём. Один настаивает на повсеместном использовании геттеров/сеттеров (крон), другой говорит, что getX()/getY() не нужны, так как не повышают уровень абстракции и данные не скрывают (jtootf, с ним я согласен).

Ты же вообще цепляешься к словам и пытаешься доказать непонятно что (С++ не позволяет сделать то, что тебе захотелось, и сделать это так, как тебе хочется?)

Несмотря на то, что тебе ясно написали, что «твоя мысль» сформулированна размазанно и недостачно точно (да и сам ты пишешь, что тебя поняли не так) - ты продолжаешь выяснять какие-то мелочи