![]() |
Интро Сейчас актуально писать мелкий говнософт для разных социальных сетей. Обычно начинающие быдлокодеры пишут подобное с помощью процедурного подхода и если проект более-менее сложный начинают захлебываться в глобальных переменных и значениях процедур и функций. Я хочу продемонстрировать ООП подход и его приимущества. В статье будет ценен не код программы (скорее он то только для устрашения), а способ мышления при использовании ООП подхода. Этап 1 ТЗ: Написать дампер сообщений социальной сети ВКонтакте с возможностью дампить переписку как по SID так и по логину/паролю. Оговорюсь заранее, что при написании софта, я встретил много подводных камней, которые значительно усиливали запутанность программы. Я не стал вдаваться в безупречную реализацию, тк, пишу для демонстрации объектно ориентированного метода, но все-же я пометил комментариями участки кода, требующие доработки. Что нам понадобится? 1) Язык поддерживающий ООП (Я пишу на Дэльфи) 2) Сниффер сетевого трафика (работать будем в основном с http поэтому httpAnalyzer вполне устроит). Этап 2 По ООП есть куча разной литературы. Я попробую максимально доступно объяснить всю суть на конкретном примере. Итак, исходя из ТЗ мне нужно создать класс объекта, который смог бы проделывать определенные операции на сайте. Для начала происнифаем сайт и разберемся в алгоритмах запросов. Об этом я вообще писать не буду. По окончании у нас будет алгоритм примерно такой: 1 - Авторизуемся 2 - парсим корешей 3 - парсим месаги Создаем новый класс объекта . Коротко немного теории : каждый класс что-то знает и что-то умеет делать. То что класс знает называется полями класса (если угодно переменные), а то что он умеет - называется методами класса (если угодно процедуры и функции)... В самомо начале проэктируется внешний вид класса (что знает умеет), а потом реализация (как он умеет). Чтож, давайте попробуем определиться, что необходимо знать и уметь нашему классу... Знать: авторизационные данные (логин пароль), SID пользователя, количество друзей пользователя, список ID друзей, и он должен взаимодействовать с сетью по протоколу http, поэтому будет разумно запихнуть в него объект типа TidHTTP. Можно продолжать, но в учебных целях притормозим Уметь: Авторизоваться, Парсить ID друзей, Парсить сообщения. Также, каждый объект класса будет инициализирован под средством метода конструктора Create () . В нем удобно создавать объекту все условия для комфортной работы (создавать файлы/ соединяться с БД/ задавать настройки по умолчанию других объектов.) Код:
//---------------Class for work with Vk.com--------- Этап 3 Вот собственно и все! Осталось всего ничего описать реализацию каждой функции . Здесь в подробности я вдаваться не буду, просто выложу свой быдлокод .... Там в основном парсинг и танци с бубном вокруг запросов к ВК. Код:
//------------function parse messages with a script--------------------------Этап 4 На 4 этапе необходимо создать объект нашего класса. Для этого его нужно инициализировать методом Create (). Также описывается поведение объекта и взаимодействие с другими компонентами программы. Дабы немного поизвращаться я не стал делать GUI. Программа получает необходимые данные ввиде параметров командной строки, а результаты пишет в файлы. Код:
VarЦитата:
Цитата:
Оутро Моя программа является еще сырым приложением и используется в качестве наглядности, но если есть необходимость и руки = тру, то и интерфейс можно прикрутить и потоки и функции поправить... Подобным образом создаются проекты побольше со сложной структурой. Мир ООП очень богат и при разумном использовании очень помогает упростить жизнь разработчику как професионального уровня так и мелкому фрилансеру. Надеюсь кому-то пригодиться. Спасибо за внимание. BlackIce. Привожу код всего приложения: Код:
program VK_Dumper; |
Цитата:
Цитата:
Цитата:
|
Цитата:
а так ТС молодец,и идея прикольна |
Кстати, давно искал такой софт )) чтоб дампить переписку из акков, и в офф-лайне спокойно читать/разобрать.
Можете дать рабочую прогу? |
Поправте меня, но на статью и близко не тянет. Что бы представить модель ООП не хватит написать только один класс-обертку. Суть ООП всё таки это взаимодействие между различными обьектами, а не работа с одним единственным классом-обьектом.
Как пример обьекта - годится, но не как представление модели ООП. |
2 Kaimi, DX вы же делфи не знаете?
На статью мало тянет, согласен. Можно было показать примеры наследования и взаимодействия с классами. Но так как сам только практикую, то и писал для себеподобных. Вс-еже, даже такой подход упрощает разработку и разбивает создание на 2 этапа: проэктирование класса, где кодер на абстрактном уровне разрабатывает структуру будущей программы и реализацию. За критику благодарю, буду стараться больше работать в данной сфере и писать более годные статьи. Линк на файл : http://www.sendspace.com/file/dykm4i |
В статье хорошо продемонстрирован антипаттерн "God object". Слишком много функционала возложено на один объект. Не обязательно знать делфи, чтобы не заметить такой ошибки.
Главная задача ООП - закрывать для изменения существующий и отлаженный код, и предоставить возможность добавлять к нему новую функциональность. За счет этого обеспечивается повторное использование. В данном случае нет смысла в классе TVKDump; с тем же успехом можно было бы сделать все это модулем (delphi unit), а поля - просто переменными этого модуля. Получение страницы с веб-сервера vk.com - в принципе задача для отдельного класса. Ведь можно грузить страницы как напрямую, так и через прокси или цепочки прокси. Если все это запихнуть в один класс, никакой выгоды от ООП не будет, т.к. такой код сложнее выдрать для использования где-либо еще. Страница может загружаться не полностью, а частями (для уменьшения трафика) + списки друзей и прочее могут быть реализованы на сайте постранично (следовательно для каждой страницы требуется отдельный запрос). Аутентификацию тоже следует вынести в отдельный класс, зависящий от соединения с vk (а не просто от сферического TidHTTP, поскольку это внешняя зависимость). Предположим, что вконтакте спалил наш "многопоточный сканер" и решил показать каптчу, на абсолютно произвольном запросе. Теперь придется в код класса внедрять еще и каптчу. Это значит, что надо интегрировать все это дело с antigate и как альтернативу предоставить возможность вбивать их вручную. А если делаем многопоточность, там может возникнуть задача равномерно размыть запросы по всем проксям, с учетом числа запросов и переданного трафика. Тогда потребуется вести учет по трафику и числу запросов каждой прокси - еще один класс, который будет решать, через какой прокси должен быть отправлен запрос в этот раз. Плюс обход всяких сбоев при работе с прокси, необходимость повторения запроса в случае падения коннекта - вообщем, еще много различных проблем можно найти. Особого проектирования в этой статье не усматривается. Обычный код, который пишут на скорую руку. Все, что здесь есть ООПшного - только использование дельфийских классов и компонентов путем композиции. P.S. Для программы уровня "написал и забыл" данный код хорошо годится, главное, чтобы работало. А поддерживать такое не пожелаю никому |
Цитата:
ТС, прочитай про атрибуты видимости методов, переменных, про свойства. Так как ты написал пишут только начинающие быдлокодеры. Ко всему этому ты еще создаешь объекты в конструкторе, но нигде их не освобождаешь. Зачем писать статью с такими ошибками? Чтобы сделать свой членский взнос в литературу для быдлокодеров? |
| Время: 11:08 |