Что-то хочется написать,а что не знаю )))

  Размышления по поводу программирования

И что бы такое рассказать? 

Давай рассмотрим структуры данных, везде и всюду про них говорят и говорят.

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

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

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

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

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

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

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

Если это программа для поиска строк то тут нам пригодятся массивы,теже списки и любой тип данных в зависимости от ситуации сколько будет строк обрабатываться 1 млн, 500 000 или вообще громадный объем в гигабайтах.

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

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

Что здесь можно посоветовать?

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

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

Пример очень простой взять хотя бы сравнение строк на не допустимые символы (будем фильтровать спец символ !"#$ ) когда я был не знаком со множествами (a: set of char) приходилось делать тупое сравнение в цикле со счетчиком если это не допустимый символ удалить,да можно было конечно использовать и встроенные фу-ии в списках TStingList и многое другое, но на данный момент я знал лишь массивы,записи и различные циклы,самое простое и самое примитивное, какое же было озарение и радость когда познал множества,

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

показала красоту решения и изящность кода эта операция проверки входит ли данный символ

в разрешенный или это спец символ,все просто и понятно.

Я бы мог еще привести примеры правильных и не правильных структур данных,но в целом думаю понятно из всех моих слов в чем задача программиста, ЧЕМ ЯСНЕЕ АЛГОРИТМ и понятнее на бумаге,тем проще и изящней код самой программы,и самое главное конечно что бы алгоритм помещался в голове пищущего программу,иначе не избежать путаницы и не разберихи,а еще ужаснее будет отладка и тестирование такой программы.

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

Идеальность стоит искать в модели программы в модели структуры данных.

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

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