Отношения многие ко многим

[stikriz]

Совершенный код - крайне рекомендую. Основы ООП там разобраны прекрасно.

Ну,Вы и демонстрируете отличное знание этой книги.

Добавлено спустя 8 минут 44 секунды:

Перекрестные ссылки - это хорошо и правильно! Косяк в том что я не могу их реализовать в разных модулях!

А я могу Делегирование метода используйте.

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

А я говорю, что надо думать о том, кто кем владеет, а потом уже не прятать ничего, а делать систему проще.

Код: Выделить всё

TGetGradeOfPupil = Function (Const aPupil: TPupil): TGrade of Object;
...
Pupil:=TPupil.Create;
Pupil.OnGetGrade:=@GetGrade;


Добавлено спустя 46 секунд:
И это не нужно - надо спрашивать у школы, и не парить мозги.

[Brainenjii]

<второй мат за день>. Я не могу использовать в интерфейсах необъявленные классы. А необъявлены они потому что нет поддержки пространств имён. Продемонстрируйте, уж очень прошу, пример интерфейсных частей модулей. Задача - я хочу знать в каком школе и классе учится ученик, а класс - какой школе он принадлежит и какие ученики у него есть. В рамках одного модуля - плёвое дело. Разнесите на несколько, пожалуйста. Без дополнительных классов и директив компилятору

[stikriz]

<второй мат за день>.

?!

Задача - я хочу знать в каком школе и классе учится ученик, а класс - какой школе он принадлежит и какие ученики у него есть.

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

[Brainenjii]

другой причины Вы так и не озвучили

http://freepascal.ru/forum/viewtopic.php?p=63356#p63356 - первая строчка.

объявите в первом модуле полностью абстрактные три класса, а реализацию уберите в три других

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

. Почему-то в рамках одного модуля 3 абстрактных класса мне не нужно. И при современных реализациях пространств имён - тоже. Но нет же, надо горой стоять за негибкие архитектурные решения. Зачем развиваться, если можно городить костыли с абстрактными классами. А то и вообще, отказываться от прямых перекрестных ссылок между объектами. Вы правда считаете, что проверять искать - а в каком же классе учится ученик (а как ещё вы реализуете AScool.Grade[APupil];) - архитектурно более удачное решение, чем держать актуальную прямую ссылку прямо рядом с учеником? Обскурантизм какой-то... Я дважды просил назвать минусы решения с пространством имён. Кроме аггрессии к банальному кешу (или опревержений, что нет, это не кеш, а что-то другое) ничего не слышал.
Вот если честно. Вы считаете что я не прав в корне, и проблемы, которую я озвучил (см. ниже) не существует в принципе?

----
это сноска ^_^ Проблема - я не могу разбить конструкцию

Код: Выделить всё

Type TOwned = Class;
Type TOwnedList = Specialize TFPGList<TOwned>;
Type TOwner = Class
  Public Owned: TOwnedList Read fOwned;
End;
Type TOwned = Class
  Public
    Property Owner: TOwner Read fOwner;
End;


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

[stikriz]

http://freepascal.ru/forum/viewtopic.php?p=63356#p63356 - первая строчка.

Да, там кроме 700 строк еще и "один класс - один модуль". Объявление трех абстрактных классов - это не то же самое, что там же их и реализовать.

. Почему-то в рамках одного модуля 3 абстрактных класса мне не нужно.

Да, и мне не нужно, да и "почему-то" - не аргумент. Напоминает жалобу больного:
- Доктор, когда я делаю вот так, то мне больно!
- Так, не делайте так, голубчик...

Зачем развиваться, если можно городить костыли с абстрактными классами

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

правда считаете, что проверять искать - а в каком же классе учится ученик (а как ещё вы реализуете AScool.Grade[APupil];) - архитектурно более удачное решение, чем держать актуальную прямую ссылку прямо рядом с учеником

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

Вот если честно. Вы считаете что я не прав в корне, и проблемы, которую я озвучил (см. ниже) не существует в принципе?

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

[zub]

>>надо горой стоять за негибкие архитектурные решения
Вообщето юниты это плюс паскаля. Если мозги работают в пространстве имен - велком, есть много крутых современных языков))
>>А то и вообще, отказываться от прямых перекрестных ссылок между объектами
Да, надо отказываться - 99.[9]% багов будут от неподдержания этих ссылок в актуальном состоянии

[Brainenjii]

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

>_< Некоторые паттерны проектирования почти не отличаются между собой физически, но довольно сильно - назначением использования. Так и здесь, абстрактные классы, безусловно, полезны и нужны, и если в коде нет интерфейсов, то это скорее более развитый процедурный код, чем код с действительным ООП. Но использовать их, чтобы заткнуть дырку областях видимости - это костыль.

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

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

Вообщето юниты это плюс паскаля

То что Interface и Implementation части модуля находятся в одном исходном файле - это несомненный плюс. А то что нынешняя реализация этих модулей заставляет меня держать связанные классы в одном модуле - это минус. Мир не черно-белый.

>>А то и вообще, отказываться от прямых перекрестных ссылок между объектами
Да, надо отказываться - 99.[9]% багов будут от неподдержания этих ссылок в актуальном состоянии

Тут мне нечего сказать... И как только LCL/FCL и прочие библиотеки до сих пор работают ещё, непонятно...

Самое главное, что Вы легко можете задать такое условие, которое невыполнимо

условия одно. В некоторых вариациях (но не меняясь по сути своей) оно встречается и самой первой страницы обсуждения. И оно действительно невыполнимо в текущей реализации модульной системы.

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

[stikriz]

хорошо, кеш под запретом.

Какой еще кэш? Данные в оперативной памяти. Зачем кэш? Это не кэш, а дублирование указателей со всеми вытекающими багами.

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

Какие проблемы вызвать этот метод? Первая часть фразы - мягко говоря, непонятна. Опять неправильно применяете термин инкапсуляции. Инкапсуляция - это сокрытие реализации.

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

Чем?

А то что нынешняя реализация этих модулей заставляет меня держать связанные классы в одном модуле - это минус.

Этотолько Ваши детские трудности.

И как только LCL/FCL и прочие библиотеки до сих пор работают ещё, непонятно...

Они так работают, потому, что нужно поддерживать компонентно-ориентированную разработку. Это данность.

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

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

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

У Вас есть кирка и лопата, но Вы хотите копать воздушным змеем. Порочно-ли это? И порочно, и смешно. Что непонятно? На Ваш вопрос ответили исчерпывающе. Что хотите доказать? Что Ява рулит? Ну, идите и рулине с Явой. Делов-то.

[zub]

Brainenjii
Напишите фичреквест на багтрекер.Завязываю флеймить

[Brainenjii]

Какой еще кэш? Данные в оперативной памяти. Зачем кэш?

да ну... *facepalm*

Первая часть фразы - мягко говоря, непонятна. Опять неправильно применяете термин инкапсуляции. Инкапсуляция - это сокрытие реализации.

viewtopic.php?p=63376#p63376 - второе предложение первого абзаца.

Чем?

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

Они так работают, потому, что нужно поддерживать компонентно-ориентированную разработку. Это данность.

Модуль db в FCL - это тоже компонент? Или fpSock? И DOM? *facepalm* Вообще шикарный аргумент - "Они компонентные, им можно". Что за компонентные, почему им можно, всем остальным нельзя? Я их использую как обычные классы, это неправильно? Надо срочно всё переписать с наследованием от TComponent или как? Подскажите?

У Вас есть кирка и лопата

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

В Вашем случае, как Вы описали - это плохо.

viewtopic.php?p=63381#p63381 С идентичной структурой написаны десятки тысяч строк кода. Ах, да, они же компонентные

Напишите фичреквест на багтрекер.Завязываю флеймить

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

[stikriz]

Ах, да, они же компонентные

Не надо передергивать. Там списки на самих себя. Список у компонента на компоненты, список у контрола на контролы, у компонента овнер - это компонент. У контрола парент - это контрол. Списки у колекций - чтобы не писать ридеры-райтеры - вот, посмотрите, там невидимые компоненты ставятся на форму, а их проперти редактируются через Айтем колекции. Это совсем другая песня. Вы же хотите немного не так.

Почему-то перенимать удачные решения многим кажется предательством.

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

Добавлено спустя 2 минуты 19 секунд:

viewtopic.php?p=63376#p63376 - второе предложение первого абзаца.

Если бы не прятали, то система не была бы сложной Школе проще всего иметь списки и соответствие

Добавлено спустя 1 минуту 50 секунд:

Один в поле воин

Это с каких пор хотелкины стали воинами?

[Brainenjii]

stikriz. Я хочу так же. Вот честно! Просто я хочу разбить это дело по разным модулям, не создавая лишних классов. И всё, что я пытаюсь добиться этим флеймом - обратить на это внимание. Да и то, что необходимость ссылки на владельца - неудачная архитектура - ну не могу согласиться. Это как с дженериками - ругают, но в контраргументах - только размер. Тут - ругают, но в контраргументах только целостность данных, причем напрочь игнорируется вариант, когда целостность сохраняется (см.варианты с Getter'ами). А с таким игнорированием вес такового аргумента несколько теряется не так ли?

При чем тут поддержка общества? Вы флеймите для поддержки общества?

Если бы хоть один согласился, что да, действительно существующая система модулей позволяет устраивать перекрестные ссылки в рамках одного модуля и запрещает - для нескольких. Но ответ один - "Хотите? Валите на другие языки" ^_^ Причем приправленный некоторой долей агрессии и обучения.
Силы свои я тоже оцениваю, так что компилятор не напишу. Препроцессор, который будет эмулировать Java'овские пакеты написать,в принципе, можно, но без поддержки модулей с точкой в CodeTools и общей костыльностью решения - смысл такое писать имеет разве что в качестве proof of concept.

Если бы не прятали, то система не была бы сложной

А мне казалось, что прятать реализацию - давно уже всеми одобренная практика ^_^

Это с каких пор хотелкины стали воинами?

[stikriz]

А с таким игнорированием вес такового аргумента несколько теряется не так ли?

Если у Вас 3(ТРИ) класса в программе, то как угодноможно делать. С повышением сложности, перекрестные ссылки - это источник граблей.

[Brainenjii]

Да у меня 191 класс. Но среди них есть взаимосвязанные группки по 2-3 класса (в основном отношениями владелец -> элемент). Причем там где это нужно - я не всегда (да никогда, на самом деле) хочу делать абстрактные классы. [offtop]но выбора нет, потому что в один модуль я не могу объединить,потому что теряю поддержку со стороны кодогенератора[/offtop]

[alexs]

Причем там где это нужно - я не всегда (да никогда, на самом деле) хочу делать абстрактные классы.

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