Добрый день. Сразу оговорюсь. Я не являюсь архитектором ПО и не занемаюсь проектированием.
Все что я пишу просто мои мысли полученые из многолетней практики програмирования. И так:
Иногда в практике наталкиваюсь на следующую проблему:
В сложных системах допустим в некотором IDE например как VisualStuduio
существует множество возможных действий и множество событий сообщающих о них.
на практике часто подрозумевается некоторый правильный порядок вызова действий
который ни где фомально не специфирован. Это и понятно. Иногда описать это практически невозможно учитывая
что порядок является не статическим и вполне может зависеть от состояния в котором находится программа.
И если учитывать что количество состояний может расти экпотенциально при ленейном росте переменных состояния то какое либо описание вообще затруднительно. Обычно все сводится на уровень здравого смысла.
Можно сколько угодно применять подходы типа Design By Contract итд , но мы не в состоянии удержать всю картину в целом.
И если со статическим описанием программы все уж как то утряслось с годами (статическая типизация и тд.) то с динамикой — порядком вызова функций все по прежнему как мне кажется стоит на месте. И я не утверждаю что нет методов. Просто на практике они слабо пременимы.
Я пишу код , добавляю методы классу, и я не знаю кто и когда и в каком порядке будет их вызывать. Даже если все обложить условиями или try/catch.
При разширении системы даже правельный порядок может стать не верным.

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

Собственно этот пост не вопрос , а приглашение к обсуждению этой темы для всех кому это интересно.
В догонку — Вам когдани-будь помогал перед на асинхронные сообщения? Решил ли он какието проблемы или это всеголишь перенос той же проблемы на другой уровень?

Спасибо.

Здравствуйте, chudo19, Вы писали:

C>Можно сколько угодно применять подходы типа Design By Contract итд , но мы не в состоянии удержать всю картину в целом.
C>И если со статическим описанием программы все уж как то утряслось с годами (статическая типизация и тд.) то с динамикой — порядком вызова функций все по прежнему как мне кажется стоит на месте. И я не утверждаю что нет методов. Просто на практике они слабо пременимы.
C>Я пишу код , добавляю методы классу, и я не знаю кто и когда и в каком порядке будет их вызывать. Даже если все обложить условиями или try/catch.
C>При разширении системы даже правельный порядок может стать не верным.

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

Здравствуйте, chudo19, Вы писали:

C>Собственно этот пост не вопрос , а приглашение к обсуждению этой темы для всех кому это интересно.
Советую вам посмотреть Spec#, JML, splint, singularity

Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?

. Там все это есть.

Здравствуйте, chudo19.
Очень красиво сказал(а) _doctor!!! Хочется добавить просмотр книги (а в последующем это должна стать HollyBible Гамма, Хелм, Джонсон, Влиссидес "Приемы объектно ориентированного программирования." Design Patterns) и подвести под всем этим тезис "Расделяй и Властвуй"!!! Все сводиться к тому что все задачи практически однотипные и решаются схожими путями. Т.е. того зверя которого вы написали нужно было сначала спроектировать (кстати при помощи IDEF0 модели, самое простое), а потом реализовывать с учетом будующей модернизации!!! И не будет никого кошмара, а тесты придадут уверенности в работоспособности написанного кода и помогут избежать ошибок при внесении новых функциональностей.

Здравствуйте, newObject, Вы писали:


O>Очень красиво сказал(а) _doctor!!! Хочется добавить просмотр книги (а в последующем это должна стать HollyBible Гамма, Хелм, Джонсон, Влиссидес "Приемы объектно ориентированного программирования." Design Patterns) и подвести под всем этим тезис "Расделяй и Властвуй"!!! Все сводиться к тому что все задачи практически однотипные и решаются схожими путями. Т.е. того зверя которого вы написали нужно было сначала спроектировать (кстати при помощи IDEF0 модели, самое простое), а потом реализовывать с учетом будующей модернизации!!! И не будет никого кошмара, а тесты придадут уверенности в работоспособности написанного кода и помогут избежать ошибок при внесении новых функциональностей.

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

Насчет unit тестов: последнее время я занимаюсь разроботкой игр.в этой области возникают ситуации когда много объектов взаимодействуют между собой не тривиальным образом. описать такие взаимодействия в юнит-тестах довольно сложно. да и не совсем ясно что в таких ситуациях является еденицей тестирования. если писать юнит тесты скажем на каждый игровой объект отдельно то это является не эфективным и довольно бессмысленым занятием.

Здравствуйте, chudo19, Вы писали:

C>Насчет unit тестов: последнее время я занимаюсь разроботкой игр.в этой области возникают ситуации когда много объектов взаимодействуют между собой не тривиальным образом. описать такие взаимодействия в юнит-тестах довольно сложно.
Если вы не можете описать поведение объектов в тесте, то после релиза вам остаётся только молиться, надеясь что всё работает как задумано
Никто не заставляет писать тесты для всех возможных вариантов — это нереально. Однако автоматическое тестирование, проверяющее всего 20% возможных ситуаций (по возможности наиболее типичных и особых случаев), уберёт 80% проблем

C> да и не совсем ясно что в таких ситуациях является еденицей тестирования. если писать юнит тесты скажем на каждый игровой объект отдельно то это является не эфективным и довольно бессмысленым занятием.
Я сознательно писал о не только юнит-тестах. Тестирование — многоуровневая штука: от юнит тестов проходом, через functional-тесты, integration-тесты и вплоть до тестирования человеком всего процесса. Ни один из этих уровней не способен гарантировать абсолютной корректности. Ни один из этих уровней не способен покрыть всё. Как вы сами сказали, юнит-тестами не всегда удобно/эффективно проверять взаимодейтсвие кучи объектов.

Тем не менее, каждый уровень позволяет очень дешёвым способом прикрыть значительное количество потенциальных проблем попутно работая примерами использования тех или иных фич. Грубо говоря, чем больше удастся поймать/задокументировать юнит-тестами, тем легче и более эффективно будет писать functional-тесты,... тем легче, дешевле и более эффективно можно будет использовать тестеров-людей.

Здравствуйте, chudo19, Вы писали:

C>Здравствуйте, newObject, Вы писали:

C>Насчет unit тестов: последнее время я занимаюсь разроботкой игр.в этой области возникают ситуации когда много объектов взаимодействуют между собой не тривиальным образом. описать такие взаимодействия в юнит-тестах довольно сложно. да и не совсем ясно что в таких ситуациях является еденицей тестирования. если писать юнит тесты скажем на каждый игровой объект отдельно то это является не эфективным и довольно бессмысленым занятием.

Согласен с тем что большие проекты тяжело тестируемы вплане взаимодействия объектов. Но если существует функциональная модель взамодействия и вся ее функциональность покрыта тестами то проект становится вполне прозрачным и понятным. Более того когда пишешь тесты могут прити идеи о дизайне проекта, и с новым дизайном с старыми тестами проект становится понятным.
Может возникнуть проблема тестирования GUI, но это другая проблема и к топику не относится.

Здравствуйте, chudo19, Вы писали:

C>Я пишу код , добавляю методы классу, и я не знаю кто и когда и в каком порядке будет их вызывать. Даже если все обложить условиями или try/catch.
C>При разширении системы даже правельный порядок может стать не верным.

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

Вариант №1
Интерфейс

class MyFile {
    void open(string filename);
    Data read();
    void close();
}

Использование

MyFile myFile;
// . . .
myFile.open("filename.txt");

myFile.read();

myFile.close();

В данном примере подразумевается, что экземпляр класса MyFile может находится в двух состояниях: открытом и закрытом. Читать данные (т.е. вызывать метод read) можно только в том случае, если объект находится в открытом состоянии. Аналогично, закрывать MyFile (close) можно только если он открыт, а открывать (open), только если он закрыт. Метод read оставляет объект открытым, open -- открывает закрытый, а close -- закрывает открытый. Недостаток такого подхода в том, что по коду бывает сложно отследить в каком состоянии находится объект и можно случайно сделать ошибку (вызвать read, когда объект закрыт; либо несколько раза подряд в разных местах вызвать open или close).

Вариант №2
Интерфейс

class MyFileFactory {
    MyFile open(string filename);
}
class MyFile {
    Data read();
    void close();
}

Использование

MyFileFactory myFileFactory;
// . . .
MyFile myFile = myFileFactory.open("filename.txt");

myFile.read();

myFile.close();
myFile = null; // myFile is unusable now

В данном примере мы ввели фабрику, которая возвращает экземпляр MyFile в уже открытом состоянии. По сути, если у нас есть на руках экземпляр MyFile, то нам не нужно беспокоиться о том, открыт ли он или нет; мы можем смело вызывать read. Если же экземпляра MyFile нет (а есть только MyFileFactory), то для того, чтобы прочитать данные, другого выхода нет, как только вызвать open у MyFileFactory.
К слову, в отличие от предыдущего примера MyFile не recyclable, т.е. после вызова close можно забыть об этом объекте вовсе (обнулить ссылки), и тем самым обезопасить себя от повторного вызова close или последующего read. Что касается метода open, то он всегда возвращает новый объект и повторный его вызов не является ошибкой и, следовательно, проблем не вызывает.