Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата --Ins-- @ 31.01.11, 18:40

Кто, история изменений? А ты, случайно, модель и вид в одну кучу не смешал, а? Флаг модификации - это модель, а показывать диалог или что-то в этом роде, и какой именно диалог и в какой момент - это вид, друг мой

Можно и так сделать.

Цитата --Ins-- @ 31.01.11, 18:40

Флаг модификации - это модель

Далеко не факт. С точки зрения модели документа флаг модификации может совершенно не иметь смысла. Еще раз, задача не конкретная.

Цитата Повстанець @ 31.01.11, 18:41

Можно и так сделать.

Значит вопрос в силе.

Цитата --Ins-- @ 31.01.11, 18:34

2. Для состояния Modified (и не более) ты будешь отдельный класс городить?

Цитата --Ins-- @ 31.01.11, 18:42

Значит вопрос в силе.
Цитата (--Ins-- @ Сегодня, 20:34)
2. Для состояния Modified (и не более) ты будешь отдельный класс городить?

Почему нет? Какая раздница сколькими полями описывается состояние некой сущности?

Цитата D_KEY @ 31.01.11, 18:42

С точки зрения модели документа флаг модификации может совершенно не иметь смысла.

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

Добавлено 31.01.11, 18:46

Цитата Повстанець @ 31.01.11, 18:43

Почему нет?

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

Цитата --Ins-- @ 31.01.11, 18:45

Цитата D_KEY @ 31.01.11, 18:42

С точки зрения модели документа флаг модификации может совершенно не иметь смысла.

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

Возможно и так. А в другом случае, удобно будет иметь отдельную кнопочку "применить". И изменения в одной вкладке, будут применены ко всему документу. Например, html-редактор и html-просмторшик.
По разному может быть. Задача-то не конкретная

Сообщение отредактировано: D_KEY - 31.01.11, 18:49

Цитата --Ins-- @ 31.01.11, 18:45

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

Я не думаю, что интегрирование одного из видов (а судя по его повидению он именно видом и является) есть избавление от избыточности.

Цитата --Ins-- @ 31.01.11, 18:45

Система не станет лучше от того что в ней нагородить много разных уровней абстракций.

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

Цитата --Ins-- @ 31.01.11, 16:45

Для установки Set - да, а для сброса - Reset - нет И не должно быть оно подконтрольно потомкам. Оно сбрасывается только в трех случаях и баста. Эти случаи:
1) После создания нового документа
2) После загрузки из файла
3) При сохранении в файл
Все, другого не дано. И давать потомкам руками сбросывать это состояние - это глубость полнейшая. Не должно быть у них такой возможности даже, так как все случаи когда это нужно уже учтены. Ты только дашь ему возможность поломать поведение. Если ты этого не понимаешь, то я открыто выражаю сомнение в твоей квалификации. Инкапсуляция - это прежде всего защита от возможности сделать что-то не то, предоставляя клиенту ограниченный интерфейс

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

Цитата Qraizer @ 31.01.11, 16:34

Он забыл определить такие действия. Дальше что?

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

Цитата --Ins-- @ 31.01.11, 16:45

Qraizer, смешной ты человек.
1. Я тебя в эту тему не звал
2. Я тебя здесь силой не держу
Хочешь - участвуй, если есть что сказать, не хочешь - чем ты мне угрожаешь?

Да, я угрожал. Хорошо, ты сам нарвался.
Если ты хочешь определённого поведения от потомка - заставь его так поступать. Иначе ты по-любому будешь тщётно пытаться в универсальном коде базового класса заткнуть все дыры, что невозможно, ибо быдлокодеры очень изобретательны. (Жирные интерфейсы проходили, переросли ещё во отрочестве.) Если у тебя нет возможности заставить потомка поступать так, как тебе надо, у тебя два варианта: либо ты перестаёшь закладываться на быдлокодерство, что тебе и предлагает в частности D_KEY, передавая частичный контроль над modified потомкам и обзывая нарушивших контракт базового класса ССЗБями, либо пересмотри проектное решение, чтобы всё-таки заставить быдлокодеров играть по твоим правилам. Твоё решение даже не половинчатое, оно просто бессмысленное. Ты ничего им не достиг. Быдлы по-прежнему могут тебя поломать как два пальца, достаточно забыть Set всего в одном методе, и каюк несохранённому документу целиком.
Для примера только два производных класса в иерархии.

class TBaseDoc
{
  /* ... */
  virtual bool IsModified() const = 0;
 
public:
  void OnClose() { if (IsModified()) /* blah-blah */; }
};
 
bool TBaseDoc::IsModified() const { return false; }
 
class TMyDoc: public TBaseDoc
{
  /* ... */
  bool IAmModifed() const;
  virtual bool IsModified() const { return IAmModifed() || TBaseDoc::IsModified(); }
};
 
class TCoolDoc: public TMyDoc
{
  /* ... */
  bool IAmModifed() const;
  virtual bool IsModified() const { return IAmModifed() || TMyDoc::IsModified(); }
};

Этот код лучше. Разделение ответственности чёткое: каждый класс ответственен только за свою часть состояния объекта. Пусть все предки приватные, пусть предок ничего не знает о потомках, даже не знает, а есть ли они вообще. Правило простейшее: если тебя спросили, изменён ли ты, отвечай только за себя, за остальное ответят другие. ВСЁ. Нет глобального состояния, нет проблем с ответственностью за его роль. Если быдло забыло перекрыть у себя IsModified(), только быдло от этого и пострадает, остальная часть документа будет сохранена.
Есть ещё что нам рассказать о граммотности проектирования разделения ролей в Дельфях? Давай, научи нас граммотно проектировать бизнеслогику.

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

Цитата --Ins-- @ 31.01.11, 20:28

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

И вывод не верен Ты не понимаешь разницы между процессом конструирования объекта и его временем жизни. Ты не понимаешь важность разделения ответственности. Базовый класс(даже абстрактный) должен отвечать за то, за что должен отвечать, но не более того. У тебя логика размазана. Пойми ты, что базовый класс предоставляет интерфейс как для клиента, так и для потомка(интерфейс наследования - виртуальные методы), но не наоборот.
Основная причина, как мне кажется в том, что ты привык работать один или в небольшой группе. Ты делаешь как базовый класс, так и производные, всегда помнишь взаимосвязи и подразумевающиеся неявно контракты.
ИМХО.

D_KEY, расскажи это все разработчикам VCL или .NET Framework Тебя очень удивят вирт. методы CreateParams; CreateWnd и там и там А меня - нет. И никого из Delphi программистов. Или разработчики этих библиотек тоже работали одни или в узких группах и помнили о всех взаимосвязях и неявных контрактах Ага, только их разработка - это библиотечные классы для всех, а не для них самих. Открой ты уже для себя полиморфное поведение, блин

Цитата --Ins-- @ 31.01.11, 21:15

D_KEY, расскажи это все разработчикам VCL или .NET Framework Тебя очень удивят вирт. методы CreateParams; CreateWnd и там и там А меня - нет. И никого из Delphi программистов.

Они меня тоже не удивят. И не такое видели
Еще раз тебе повторяю, что поведение Delphi мне понятно(и почему ты все-время настаиваешь, что нет?), мне не понятны причины решений проектировщиков языка. В С++ мне например понятно многое, то, что было не совсем ясно - прояснила D&E. В Java тоже(кстати, из явы я бы перенес в С++ проверяемые исключения(это уже невозможно) и внутренние классы). Питон, в принципе, прозрачен. Пролог? Понятен. Лисп? Без вопросов(крое разве что eq/eql/equal/etc).
.NET спроектирован не очень удачно, но не сказать что плохо(Это мнение некоторых моих знакомых, перешедших на .NET. Я пока только немного знаю шарп, изучение .NET только в планах)
Да даже Java не без греха(которые компенсируются такими языками под ява-машину, как groovy и scala). У всех свои недостатки. Питон правда вот практически их лишен(для своей ниши).
Относительно VCL - ничего толокового в архитектуре не заметил. Есть какие-нибудь интересные приемы и паттерны?

Цитата Qraizer @ 31.01.11, 19:40

Этот код лучше.

неужели?
1. да, TMyDoc обязан перекрыть IsModified, но TCoolDoc уже нет...
2. например в TMyDoc добавили поле int, какой будет реализация IAmModifed?

Цитата Qraizer @ 31.01.11, 19:40

Если быдло забыло перекрыть у себя IsModified(), только быдло от этого и пострадает, остальная часть документа будет сохранена.

каким образом?

Цитата DesweR @ 31.01.11, 13:27

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

Вы перечислили все пункты, которые я ставлю в минус D! Поздравляю! Теперь вам нужно только лишь поменять мировоззрение на противоположное, и я признаю ваш профессионализм

Цитата --Ins-- @ 31.01.11, 13:32

Миксины - это что, агрегация? Так она много где используется, пуская в расход множественное наследование, и в Delphi тоже

Слышал, как говорится, звон... Вы бы хоть вики почитали.

Цитата --Ins-- @ 31.01.11, 13:39

Т.е. если у меня в классе 20 параметров, я должен сделать двадцать конструкторов? Или один с 20-ю параметрами? Как будет правильнее?

Вы должны сделать интерфейс для наследников в виде protected доступа к свойству modified. Потомок установит его в нужное ему состояние.

Цитата D_KEY @ 31.01.11, 17:03

--Ins--, относительно синглетона. Так как ты хочешь не сделать без шаблонов

D_KEY, ну что ты ведёшься на эти разговоры про "плюсы без шаблонов"? А почему без шаблонов, а не без цикла for? Или int выпилим? Ну, детский сад же!