У меня есть конкретная программа по компрессии и декомпрессии картинок формата tif. Изначально, данная программа была ”сделана в лоб”, то есть содержит не оптимальный код, некоторые части переделывались по несколько раз, некоторые писались “на ходу”. Всё было сделано методом проб и ошибок без определённого тех задания. На данный момент я решил освоить паттерны проектирования и привести весь код в человеческий вид. Прошу Вашей помощи, так как только начал осваивать паттерны, и их практическая реализация для меня ещё остаётся загадкой. Давайте вместе сделаем это от начала до конца, и это будет примером для других, как делать рефакторинг, хотелось бы сделать живую и горячо обсуждаемую ветку. 

Вот список методов, которые содержатся в моей программе: 



Сразу возникают вопросы:
- как сделать программу более универсальной, чтобы проще было обрабатывать разные форматы tif?                                                                                                                                                                                      
-  можно ли заложить некий интерфейс, чтобы в будущем можно было обрабатывать не только tif? 
-  на данный момент один пиксель равен 256 бит, а если в дальнейшем необходимо будет увеличить глубину как это реализовать?                                                                                                               
- есть ли смысл что-то скинуть в библиотеку?                                                                                                      
- на какие паттерны проектирования стоит обратить внимания, и какие здесь наиболее применимы? 

Можно с начало поинтересоваться о мотивации - зачем было изобретать велосипед и зачем его дальше улучшать (будет ли эта библиотека где нибудь использоваться)?

А по теме, прочитай Рефакторинг с использованием шаблонов. Так же можешь пройтись по коду ReSharper и StyleCop

Это сообщение отредактировал(а) Kaerus - 17.1.2011, 13:28

Да, в дальнейшем эта программа будет использоваться. Мотивация простая - попробовать на конкретном примере, что такое паттерн проектирование, книги я читал, но теория одно, а практика другое. Пока не реализуешь что-то конкретное своими руками не почувствуешь, что к чему. 

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

Если честно, то не знаю с какой стороны подойти, с чего начать и как разделить на слои тоже не понимаю. Какой функционал должен быть знаю так как прога уже работает, но код там ужасный! 

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

Да начать можно с паттерна MVC, на вики http://ru.wikipedia.org/wiki/Model-View-Controller есть ссылки на русские статьи по теме

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

Так, попробуем разделить все методы на логические составляющие: 

Загрузка формы: 


Методы, отвечающие за меню, находящемся на форме:



Видимо всё вышеперечисленное можно отнести к отображению? Именно эти методы отвечают за взаимодействие с пользователем. 



Эти 4 метода куда лучше запихнуть, может в библиотеку?

Далее идут методы непосредственной обработки файла, то есть его компресиии-декомпрессии, видимо, это и является бизнес логикой 



Далее начинается непосредственная обработка картинки, вначале мы ищем где конкретно в tif-контейнере зашиты данные о картинке и данные картинки, они могут быть либо вначале, либо в конце, соответственно: 



Далее идёт обработка tif файла в зависимости от того где в нём хранятся данные в самом начале контейнера или в конце



И, в конечном итоге, все необходимые и подготовленные данные передаются непосредственно в библиотеку сжатия:
  



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



и в конечном итоге в библиотеку декодирования 



Добавлено через 2 минуты и 23 секунды

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

СПАСИБО ВСЕМ КТО ПОМОГАЕТ!  

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

для начала тебе нужно понять что чтение/сохранение файла это один уровень. обработка каких то данных это второй уровень. отображение это третий уровень.

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

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




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

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



почему абстрактные? вполне конкретные классы форм, контролов и пр.


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

А можно какой-нибудь маленький, но наглядный пример? Фактически когда я "вписываю код" обработки события тем самым я стыкую отображение с безнеслогикой! По крайней мере, я себе так это представляю! 
 


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

 


Да в библиотеке постоянно что-то меняется, вносятся коррективы, новые свежие мысли и поэтому она отделена! 

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

2 Экскалупатор

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

это все       

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

Почитав литературу и полазив по сайтам, я составил вот такой классификатор:

Запрос на вывод интерфейса программы по умолчанию: пользователь  → контроллер → представление
Отображение интерфейса программы: представление → пользователь 
Ввод данных: пользователь  → контроллер
Проверка данных: контроллер
Передача данных на вычисление: контроллер → модель
Возврат результатов вычисления: модель → контроллер
Отображение результатов: контроллер → представление  
 

Вот такие вопросы появились при разборке паттерна MVC для моей задачи:

Нужно ли создавать отдельные классы для Модели, Представления и Контроллера? 

Если с компонентом Модель всё более или менее понятно, то процесс разделение Контроллера и Представления не ясен?  Кто что об этом думает?

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