Никогда ранее с файловой системой работать не приходилось, но настал момент "первого раза" и хотя я делаюи не на php, но очень надеюсь, что именно здесь мне помогут, так как мне кажется, что для Вас, это повседневная-рутинная работа. Есть в общем директория с файлами, которую я рекурсивно прохожу и есть файл, в который я записываю собранную информацию. Пока все сводится к минимуму - 1) Класс для работы с файлом в который я записываю. 2) Класс для работы с файлами, которые я парсю. 3) Класс-коллекция, который содержит информацию о файлах с которых я собираю информацию, чтобы лишний раз их не гонять. То есть, там информация о последнем времени изменения, путь до файла, и т.д. 4) Класс, который все это дело как-то склеивает. Он получает путь до файла, проверяет, есть ли он в коллекции, если есть, то проверяем время изменения, или же добавляет его в коллекцию и все в этом духе. Но дошло до того, что в первом классе, потребовался доступ к объектам с описанием из коллекции, а это уже не очень хорошо. Да и чувство такое, что раз один класс может иметь не один сценарий развития ( может не быть в коллекции, может быть но не измениться, может быть и измениться, но не содержать нужную информацию и это только начало ) то это уже тянет на "состояния". Вот я и подумал, что разумнее всего спросить у Вас решение. Но я не прошу показать код, а прошу назвать паттерны, которые решают эту проблему. Спасибо!
Как-то я прочел и ничерта не понял Как правило делается один читатель, один писатель, один "мозгователь".
Да не совсем правило... Мне кажется, что мозгователь должен получать ссылку на "описывающий объект" и куда-то его передавать. И вот на это что-то у читателя будет ссылка и в зависимости от состояний, он будет менять через некий интерфейс этот "описывающий объект". Это вот так правильно, но как именно я пока не знаю. Не получается картинку в голове сложить. И мозгователь у Вас получается "делает все", а это противоречит правилу "единой обязанности". Пока сижу читаю, но так можно и несколько дней читать. Хотелось бы получить ответ и преступить к реализации
Чего ты боишься? Что через три года надо будет что-то добавить и придётся смотреть исходы? Делай как удобнее. Когда наберется критическая масса кривости, можно рефакторить.
Добавь диспетчера Настолько туманно описано, что и посоветовать особо нечего. Пошагово рассказывай. 1) у тебя есть коллекция информации о файлах, которые ты периодически читаешь. 2) ты их периодически открываешь и читаешь. 3) если что-то изменилось, в строке, то ее нужно где-то обновить. Я правильно понял?
Мне жаль, что у меня не получилось объяснить более доходчиво, но я этого и не собирался. Я думал, что у занимающихся серверной частью программистов, от рождения в мозг вкраплен паттерн, который веками оттачивался для работы с чтением и записью. Но видно Вы тоже обычные люди и меня это расстраивает У меня не просто два класса для чтения и записи, у меня их очень много и будет ещё больше, что и подтолкнуло меня на создание этой темы. А по поводу "как удобнее", так я уже дискомфорт испытываю. Чувство костыльности мне не нравится.
вам не пора таблеточки пить? мне кажется пора в отпуск как минимум. люди ему не нравятся, паттерны чтения требуются... жесть.
А, чего мне нравится, такой подход к делу, надо опыт перенимать видимо: Я не скажу чего делаю, но скажите мне, чего я делаю не так?
Люди!!! Я люблю Вас!!! Вот если бы меня спросили подсказать паттерн для однотипных последовательных действий, то я бы посоветовал команду. Если бы меня спросили, что нужно знать для создания сложных приложений, я бы посоветовал MVC Если бы меня попросили рассказать, из чего состоит mvc, я бы сказал, что в минимуме, это обсервер и стратегия, компоновщик. А вот если бы меня спросили то чего я не знаю, то я бы просто промолчал, но не стал бы советовать таблетки А по существу, рассказывать-писать очень много, так как классов уже более десяти и они просто огромны. Просто показать их... Зачем? Вы хотите в трех тысячах строк кода на не php разбираться?) Поэтому Спасибо! Я думал что этот вопрос для Вас будет, как для меня о mvc. Но видимо придется самому много-много читать... И у Вас слово "дискомфорт" с людьми ассоциируется? Ахахахахаха.
Получил указатель на файл, залочил на чтение, прочел. Получил указатель на файл, залочил на запись, записал. Если после получения не удается залочить, жди. При чтении передавай параметр, отвечающий за то, в каком виде надо вернуть результат. При записи передавай параметр, отвечающий за то, как должна производиться запись. Какие тебе паттерны нужны? От Капитана Очевидность?
Видимо даже больше, чем ты думаешь. для большого проекта наверное десять это очень мало, а огромные это очень плохо. Но если у тебя для чтения файлов уже три класса задействовано, то хз.
Не всегда! Иногда по другому не получается. У меня не проект, а микро-поделка Чего хз? Класс чтения, это получается модель. Ей для полноценной работы нужны еще несколько классов. Что в этом особенного?
ты в микроподелке трёма классами файлы сканишь? =) хер знает что у тебя вообще хорошо/плохо и мало/много при таком подходе. хз хорошо ли это =)) особенного ничего к сожалению. астронавты нынче распространены изрядно. Фабрику фабрик не забудь.
у когото в голове - каша)) ты до сих пор даже не можешь нормально, словами, объяснить свою задачу. но ждешь какихто конкретных советов. и не дождешься. ибо непонимая в чем у тебя конкретно проблема - посоветовать тебе нечего.
Да, да, эти модные в определенных кругах слова: обсервер, стратегия, компоновщик, Delegation Event Model, посетитель, посредник, цепочка обязанностей, ню-ню, только прежде чем ими бросаться, нужно четко понимать СВОЮ задачу и для чего существуют шаблоны проектированя, а не выдумывать - чего бы умного мне тут пришпандорить. Рефакторишь, потом код после таких дельцов и вспоминаешь их родню до 5 колена, в адовых поисках, в какой именно фабрике они подоткнули костыль, чтобы ихние примененные красивые паттерны делали то, что запланировано. Почему-то забывают про простое и уже практически народное правило: "Пиши код так, будто его будет читать маньяк-садист, который знает, где ты живёшь." Прежде чем применять паттерны нужно четко понимать задачу, нужно ее в голове или лучше на бумаге разложить пошагово, и там же блоками группировать, что и в какой класс совать, только после этого глядя на всю эту катавасию уже задумываться о шаблонах. А в конкретном случае я ощущаю стандартную стихийную разработку, без какого либо проектирования к которой на скорую руку прикручивают академические вещи... Этакий зерноуборочный комбайн с реактивным двигателем для вертикального взлета. Грамотно спроектированная архитектура приложения появляется постепенно, когда уже есть релизная версия и чаще всего даже далеко не первая. З.Ы. шаблоны проектирования это не серебрянная пуля, это просто инструмент.
А что Вас смущает? Я же вроде уже поблагодарил всех за помощь и советы и сказал, что дальше сам...?) Вот когда я читаю слова "каша в голове", фабрика фабрик", "инструмент", "серебряная пуля", то меня тошнит от этих шаблонных слов! Своего опыта нет что ль, чтобы найти красивое сравнение? А еckb нет опыта, то зачем как сороки повторят услышанное? Вы хоть их определение понимаете? Почему Вам не нравиться фабрика фабрик, а массивы массивов Вы используете? Или массив ассоциативных массивов. Что вот тут смешного? Еще "массив ассоциативных массивов" не забудьте использовать! Ахахаха, какой я остроумный. Разрешаю повторять! И я не умничаю, я так же, как и многие не фига толком не понимаю, но у меня нет привычки умничать при этом не упоминаю статью с хабра о фабрике фабрик. И хочу сказать спасибо за диспетчера, я про него забыл, а как мысленно вписал его, так сразу всё сраслось!
классический случай самозаовна. да, оно привычное. а тебе значит часто говорят, что у тебя каша гречневая вместо мозгов? не пора бы прислушаться? жесть.
Я же написал, что это выражение любят повторять те, кому ответить нечего, а ведать сказать что-то хочется. Понятно теперь? Понятно?