Кто как решает алгоритмические трудности?

← →
Igorek (2002-05-03 00:42) [0]

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

С уважением Игорек

← →
drpass (2002-05-03 00:49) [1]

Программисты вообще-то потому и стали программистами, что умеют составлять алгоритмы. Если человек не может составить алгоритм, то либо он не владеет предметной областью, либо он не программист.

← →
SoftOne (2002-05-03 03:08) [2]

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

← →
Igorek (2002-05-03 11:44) [3]

Ну что ж скажу про себя. Я конечно не Мастер, но все же.
В сложных случаях мне очень помогает обсуждение проблемы с другом-программистом. Тогда и проблема четче вырисовывается и пути ее решения. Ну а если друга рядом нет, то тогда говорю сам с собой. :-)
Ну и кроме того если проходит какое-то время, то и задача как-то сама по себе решается в голове.

Но все же иногда приходится помучиться, пока решение придет...

← →
Mystic (2002-05-03 13:01) [4]

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

← →
Evgeny (2002-05-03 13:38) [5]

Удалено модератором

← →
iZEN (2002-05-03 17:35) [6]

http://algolist.manual.ru/

← →
wicked (2002-05-03 18:43) [7]

2 Mystic ©
прям мои слова.... ;)

← →
PaRL (2002-05-03 18:55) [8]

> Гуляешь по улицам, придумываешь идеи.

Только так и придумываю-с.

← →
Igorek (2002-05-03 18:56) [9]

2 iZEN
> http://algolist.manual.ru/
Спасибо, линк хороший, но немного не в тему

2 Evgeny
Что ж ты такого крамольного сказал? Скинь на мыло - я не обижусь ;-)

← →
Keymaster (2002-05-03 20:44) [10]

У меня несколько способов, в зависимости от глубины траблемы:

(по возрастанию):

1 - сидеть и непрерывно глазеть на кусок кода, который не
работает. Можно обсуждать проблему с собой самим.
2 - Берём ручку, бумагу и рисуем схему.
3 - Ходить по комнате кругами, обсуждая проблему с самим собой.
4 - "Звонок другу"
5 - Не трогать проблему дня 2 - 3. Обычно потом за полчаса
решается.

← →
lipskiy (2002-05-04 00:26) [11]

> 5 - Не трогать проблему дня 2 - 3. Обычно потом за полчаса
> решается.

Это верно, есть даже какие-то обоснования этому из области человеческой энергетики. Главное - забыть напрочь и не вспоминать, то есть так, как будто это вообще тебе не нужно.

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

Вот и вытекает "очень простой" вопрос - как строить программу изначально так, чтоб потом не было мучительно больно за непредусмотренные возможности расширения?

← →
Anatoly Podgoretsky (2002-05-04 09:41) [12]

Наиболее эффективный метод как у Mystic, ну если не помогает, то танцы с бубнами и изюиение пользователей. :-)

← →
Igorek (2002-05-04 10:11) [13]

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

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

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

← →
lipskiy (2002-05-04 16:28) [14]

2 Igorek
Спасибо, мне это было интересно, так как сам я вообще далек от совершенства. Правда вот встречный вопрос - класс хорош тогда, когда легко выделяется в структуру из общей задачи. А когда все функции слишком взаимоувязаны и взаимозависимы, то на классы разбить их очень трудно. У меня не получается.

← →
SPeller (2002-05-04 16:36) [15]

lipskiy © (04.05.02 16:28)

Делайте общие функции как ВинАПИ, универсальные. Ну и что, что много параметров, зато всё работает. И быстро. Ну а если и так не получается, то большую задачу разбивайте на несколько функций. Пусть она будет вызываться только один раз, зато придаст коду бОльшую наглядность и понятливость. Разбиение большого на мелкое, по-моему, это лучше всего.

← →
Igorek (2002-05-04 19:00) [16]

2 lipskiy
> когда все функции слишком взаимоувязаны и взаимозависимы, то на классы разбить их очень трудно<!i>
Трудно сказать, надо рассматривать частный случай
Но могу сказать, что иногда в классы стоит выводить ключевые понятия, которые так сразу не видны и далеко не очевидны (по сути абстрактные).
То есть над проектированием классов следует хорошо подумать - решения ведь судьбоносные... Критерий - хорошая (прежде всего в уме) обозримая структура, а также достаточно простое их взаимное использование.

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

С уважением Игорек.

← →
lipskiy (2002-05-05 23:48) [17]

2 Igorek
Да... Это верно. Вот умение правильно структурировать свой проект изначально и можно назвать профессионализмом в программерстве. Этого мне всегда недоставало.

> Если функции слишком взаимозависимы то иногда (но не всегда)
> это признак плохой организации (это субъективное мнение
> из опыта).

Угу :( И для меня это очевидно. Вижу, что плохо организовал, но хорошо - не выходит. Видать, не дано. Не мое. Но ведь хочется же уметь! Можно этому умению как-нибудь учиться? Или же это просто талант надо иметь? Может взять за правило метод низходящего программирования? Есть по этой теме что-нибудь почитать? Хотя, я где-то уже спрашивал, рекомендаций подобного рода вряд ли кто может дать...

← →
Igorek (2002-05-06 01:23) [18]

2lipskiy
> Видать, не дано. Не мое - Ерунда все это! :-))))

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

Ну и вообще на этапе проектирования спешить - преступно. Съекономишь день - потом потеряешь месяц...

С уважением
Игорек.

P.S. а вообще-то мы от темы отклонились... ;-)

← →
BAHO (2002-05-06 04:14) [19]

Говорят что если обьяснить свою проблему знакомому ламеру
то сам поймеш как ее решить :)

← →
Dok_3D (2002-05-06 06:44) [20]

2ВАНО

Да, бывает. Да и не только ламеру, вообще бывает, пока другому не объяснишь, сам не поймешь.

← →
Donal_Graeme (2002-05-06 10:41) [21]

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

← →
lipskiy (2002-05-06 11:39) [22]

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

:) Именно так я и делаю сейчас - переписываю довольно большой проект по новой, так как первый вариант писал вообще в лоб. Но и при переписывании опять начинаю понимать, что делаю хоть и получше, но снова не совсем "красиво" и гибко. Этак можно много раз переделывать :)

> Почитай Гради Буч "Обьектно-ориентированный анализ и проектирование".
> Только не спеша и фундаментально.

А в сети такого нет? Я еще не искал, но м.б. есть конкретная ссылка.
Спасибо.

> Говорят что если обьяснить свою проблему знакомому ламеру
> то сам поймеш как ее решить :)

Ну так проблемы то в чистом виде нет, как сделать, чтоб работало - это я знаю. А вот как сделать это наиболее грамотно - этого же и не спросишь даже :) Это надо просто видеть, наверное.

← →
SPeller (2002-05-06 12:23) [23]

2lipskiy © (06.05.02 11:39)

А вот как сделать это наиболее грамотно - этого же и не спросишь даже :) Это надо просто видеть, наверное.

А вы попробуйте присутствующим здесь описать проблему, может быть и подскажут дельные идеи.

← →
Ally (2002-05-06 12:42) [24]

http://www.nexus.odessa.ua/files/books/booch/

← →
lipskiy (2002-05-06 13:19) [25]

2 Ally Спасибо.
2 SPeller Не покатит. Это мне нужно будет изложить в подробностях весь смысл проекта и вести долгую дискуссию. Я лучше буду продолжать спрашивать частности и из них собирать целое.

Вот, например, два вопроса конкретных.

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

2. Почему при наследовании от TObject компилятор ругается на перекрытие методов конструктора и деструктора, говорит, что они статические? Если я их не буду перекрывать, то мне придется руками писать полное создание и уничтожение объекта?

Правда это не сюда, это надо было в "Общую". Ну да ладно уж.
Если здесь не выйдет - напишу туда :)

← →
Ally (2002-05-06 14:00) [26]

> lipskiy © (06.05.02 13:19)

1. Дело вкуса, но многое зависит от предполагаемой специфики работы класса. TObject - годен для создания какого-нибудь уникального класса "с нуля"( TObject is the ultimate ancestor for all VCL objects and components.). Прямой его наследник TPersistent - предок для всех объектов, которые имеют возможности присвоения(assignment) и работы с потоками(streaming) и т.д.

2. При объявлении конструктора в потомке класса TObject вместо override (перекрытие) надо писать virtual (виртуальный метод, который может быть переопределен в потомках создаваемого класса), а в реализации этого конструктора использовать конструкцию inherited Create() для того, чтобы вызвать унаследованный конструктор класса-предка.

ЗЫ. Поправьте меня, если где оговорился или не совсем ясно изложил.

С уважением, Ally

← →
lipskiy (2002-05-07 01:13) [27]

!!! Это очень интересно, блин, спасибо!
А в чем тогда разница между override и virtual? В данном случае непонятно - тот же inherited используется...

(Ну где еще, скажите, так просто и быстро донесут до чайника отфильтрованное "то", как не в конференции! Черт, кто бы лекцию прочитал вот так, без воды и по конкретной теме...)

← →
Malder (2002-05-07 01:21) [28]

как здорово. Игорек стал задавать вопросы, а потом стал на них отвечать для lipskiy =)))

← →
Evgeny (2002-05-07 08:20) [29]

>Igorek
Сам пытаюсь понять. Вроде постарался ответить на вопрос как его понимаю, при этом ни кого не задеть. Не понимаю...

← →
Alx2 (2002-05-07 08:32) [30]

>А в чем тогда разница между override и virtual?
>В данном случае непонятно - тот же inherited используется...

virtual или dynamic - первое объявление виртуального или динамического метода, которые потом можно будет перекрыть в потомках с помощью директивы override.

← →
Igorek (2002-05-07 10:09) [31]

2Malder
> Игорек стал задавать вопросы, а потом стал на них отвечать

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

Я смотрю тут уже два паралельных обсуждения пошло...

С уважением Игорек.

← →
lipskiy (2002-05-07 11:37) [32]

2 Alx2
Но ведь в самом описании класса TObject уже присутсвуют методы Create и Destroy, и в моем наследнике будет уже второе объявление, а не первое. Разве не так? Выходит, если я напишу virtual, то этот метод станет самостоятельным - не будет унаследован от TObject. Или я чего-то не догоняю опять...

← →
limon (2002-05-07 11:52) [33]

> lipskiy © (07.05.02 11:37)
Да нет же. Он будет унаследован от TObject, но первичный кон/де-структор будет перекрыт виртуальным, а для его вызова применяется inherit

← →
Ally (2002-05-07 11:54) [34]

Вот начало объявления класса TObject:

TObject = class constructor Create; ...

Как мы видим, конструктор является статическим и непереопределяемым методом (отсутствие директив в объявлении конструктора по умолчанию означает статичность метода) этого класса. В потомках этого класса не требуется его переопределять, так как переопределять здесь нечего. Вот реализация этого конструктора в классе TObject:

constructor TObject.Create; begin end;

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

С уважением, Ally

← →
kaif (2002-05-07 13:41) [35]

Я не могу этого объяснить научно, но я заметил, что изначально, сделав класс вместо набора функций, я имею потом всегда гораздо меньше проблем.
Мне кажется, ООП не столько адекватно отражает реальный мир, сколько очень точно отражает нашу способность мыслить. Поэтому в ООП чувствуешь себя комфортнее. Я, например, уже через неделю ничего не помню из того, что писал и смотрю на собственный код так, как если бы впервые его видел... Ужас! А когда рассматриваешь определение класса, даже написанное не тобой, настолько легко начинаешь представлять, что тут к чему - как будто сам писал...
Я всем рекомендую ООП, хотя и кажется, что это избыточно... Но время и нервы программиста дороже железа и любого снобизма...

← →
lipskiy (2002-05-07 15:33) [36]

Спасибо всем.
Вроде догнал.
Ну вот, я снова стал немного умнее :)

← →
Igorek (2002-05-15 11:30) [37]

Жаль, что обсуждение скатилось в сторону (lipskiy, между прочим по твоей вине).
Вдруг бы еще кто-нибудь поделился своей методикой "рожания" сложных алгоритмов.

Но на всяк случай спасибо всем, кто принял участие.

← →
il (2002-05-15 12:04) [38]

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

← →
Igorek (2002-05-15 12:32) [39]

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

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

Хорошо бы услышать мнение проф. психолога (или екстрасенса на худой конец) ;-)

← →
il (2002-05-15 12:49) [40]

И вообще - горазде приятнее писать грамотный и красивый код вместо стучания по клавишам и нажимания ctrl+Ins и shift+Ins (говорю безотносительно к кому-либо - сам так, бывает, делаю).
А уж о поисках ошибок я вообще не говорю. Только поначалу кажется , что сделать быстрее получится проще

Кто как решает алгоритмические трудности? Найти похожие ветки