Зачем нужны паттерны проектирования или «Что такое MVC?»

Самое главное во всех фреймворках это то, что все они диктуют правила создания приложения. Если ты никогда не использовал никакого фреймворка в своих приложениях, то либо они слишком малы и ты не сталкивался с проблемой нарастающего хаоса в коде, либо просто не пришло твоё время :) И в конце концов приложение созданное по правилам фреймворка однозначно обретёт правильную форму. А разве не этого все мы хотим? Новичок в программировании начав изучение какого-либо фреймворка автоматически начинает правильно мыслить, тем самым перенимая опыт предыдущих поколений и открывая себе более гладкую дорогу вперёд. В любом случае единственная возможность создания больших, расширяемых и модульных приложений это использование фреймворка.

Итак начнём…

MVC «Модель-представление-поведение» === «Модель-представление-контроллер».

А теперь закрой глаза и представь себе работу своего приложения. Представил?… так вот, попробуй условно разбить этот процесс на три абстрактые логические части:

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

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

Третья, но не менее важная часть, это те методы в которых реализовано само поведение модели. Так называемый «Контроллер». Вообщем это любые методы, которые вызываются к примеру событием проигрыша игры, допустим: function onLoseLevel(e:SomeEvent):void. В данном случае этот метод является поведением модели вашего приложения в случае проигрыша. Как только вы проиграли уровень вызывается конкретный метод, которые реализует поведение приложения в конкретном случае. Так вот, собери все методы, реализующие поведение в одну кучу
это и будет третья логическая часть концепции MVC, (Контроллер).

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

Реализация концепции MVC на примере приложения HellowWorld

HelloWorld.as:

package
{ 
	 import flash.display.Sprite;
	 import flash.events.Event;
	 import flash.text.TextField;
  
 	public class HelloWorld extends Sprite
	 {
	 	 private var viewComponent            :TextField;
		  
		  public static var model                   :Model;
		  public static var view                     :View;
		  public static var controller              :Controller;
		  
	 	 /**
		   * Constructor 
		   * 
		   */
		  public function HelloWorld()
		  {
		   	/*Add listener to catch an event to add to stage
			    * */

			   addEventListener(Event.ADDED_TO_STAGE, showTextHandler);
			   
			   /* Creation one view component as TextField
			    * */

			   viewComponent = new TextField();
			   addChild(viewComponent);
			   
			   /*Creation the Model
			    * */

			   model = new Model();
			   
			   /*Creation the View and giving viewComponent into constructor
			   * */

			   view  = new View(viewComponent);
			   
			   /*Creation the Controller
			    * */

			   controller  = new Controller();
		  }
		  
		  /*Set the command to handling on the event
		   * */

		 	 protected function showTextHandler(event:Event):void
		  {
		   	controller.showTextFieldCommand();
		  }
		  
	}
}



Model.as

package 
{
 	public class Model
	 {
	  
	 	 private var _textString  :String = "Hello World!";
		  
		  public function Model()
		  {
		  }


		  public function get textString():String
		  {
		   	return _textString;
		  }


		  public function set textString(value:String):void
		  {
		   	_textString = value;
		  }


	 }
}


View.as:

package 
{
 	import flash.text.TextField;


	 public class View
	 {
	 	 private var _view:Object;
		  
		  public function View(viewObj:Object)
		  {
		  	 view = viewObj;
		  }
		  
		  /*Method to change text field in the view component
		   * */ 
		  public function changeView(str:String):void
		  {
		 	  view.text = str;
		  }
		  
		  
		  public function set view(value:Object):void
		  {
		 	  _view = value; 
		  }
		  
		  public function get view():Object
		  {
		 	  return _view; 
		  }
	 }
}


Controller.as:

package 
{ 
	 public class Controller
	 {
	 
	 	 public function showTextFieldCommand():void
		  {
		 	  var str:String = HelloWorld.model.textString;
			   HelloWorld.view.changeView(str);
		  }
	 }
}


Ок. Разберём что же здесь происходит. Есть Главный класс приложения: HelloWorld.as который ответственный за всё. В нём мы создаём один единственный визуальный компонент типа TextField (текстовое поле), а также экземпляры Model.as, View.as и Controller.as. Теперь как это всё связать?

Для начала передадим визуальный компонент в управление нашему View путём передачи его в конструктор:
  view  = new View(viewComponent);


artemfedorov.com/?p=64
Теперь наша View знает о компоненте.
Далее, добавим метод во View с помощью которого она сможет влиять на компонент:

                public function changeView(str:String):void
               {
                      view.text = str;
               }


здесь всего лишь происходит присвоение текстовому полю компонента нового значения типа String.

Наша Model в этом примере содержит лишь знания о значении строковой переменной и на это бизнес логика ограничивается.

                private var _textString  :String = "Hello World!";


Controller содержит тоже лишь одну команду, которая получает значение из Model и сообщает View что нужно сделать:

                public function showTextFieldCommand():void
                {
                       var str:String = HelloWorld.model.textString;
                      HelloWorld.view.changeView(str);
                }


Далее заключительный штрих без которого ничего не будет работать это событие. Здесь для примера события я выбрал событие, которое возникает когда происходит добавление на stage и добавил слушатель:
addEventListener(Event.ADDED_TO_STAGE, showTextHandler);

К этому событию я привязал команду реализуя поведение моего приложения:

                protected function showTextHandler(event:Event):void
               {
                      controller.showTextFieldCommand();
               } 



www.artemfedorov.com
Вот и всё!
Поделиться публикацией

Комментарии 27

    +1
    эммм…
    а за чем это публиковать здесь?
      0
      я ещё не разобрался как и где публиковать и как он попал сюда?
        +5
        тогда срочно жми гаечный ключ рядом с заголовком, а потом жми кнопку в черновики
        и больше такое не публикуй :)
        0
        почему в черновики?
          +3
          Всуну своих пять копеек:
          Кроме того что это почти все знают, лучше исопльзовать псевдокод, для тех кто не владеет action script будет понятнее, ну и подсветка кода была бы не лишней.
            0
            переместил
              –5
              Вы заблуждаетесь по-поводу почти все знают. Скорее всего в вашем окружении.
                +4
                Ну ок, от почти все открещусь, добавьте хотя бы подсветку, она делается с помощью тега <source class=«php»> например тут код </source>
                0
                ок. спасибо.
                  +2
                  > И в конце концов приложение созданное по правилам фреймворка однозначно обретёт правильную форму.

                  Быдлокодер и с фреймворком все загадит, а хороший программист и без него будет держать код в порядке.
                    +2
                    > И в конце концов приложение созданное по правилам фреймворка однозначно обретёт правильную форму.

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

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

                    Это мне ИС в НИИ нужно на фрейворк переводить чтоб оно было хорошим?
                      +1
                      Прошу прощения за дубликат, сам не знаю как это получилось…
                        0
                        Что значит хорошим? Я ведь ясно написал для чего!
                          +1
                          Наезд был не на MVC, а на фреймоврки.

                          Я сейчас занимаюсь проектом, он расширяемый, модульный, кроссплатформенный. И, чудеса какие-то, не использует он фреймворков.
                          Следовательно ваше утверждение ошибочное, как и многие другие в этой статье.
                            0
                            … а можно подробнее про ошибочные утверждения в этой статье?
                              +4
                              1. Самое главное во всех фреймворках это то, что все они диктуют правила создания приложения.
                              2. Если ты никогда не использовал никакого фреймворка в своих приложениях, то либо они слишком малы и ты не сталкивался с проблемой нарастающего хаоса в коде, либо просто не пришло твоё время :)
                              3. И в конце концов приложение созданное по правилам фреймворка однозначно обретёт правильную форму.
                              4. Новичок в программировании начав изучение какого-либо фреймворка автоматически начинает правильно мыслить
                              5. В любом случае единственная возможность создания больших, расширяемых и модульных приложений это использование фреймворка.
                              6.… это и будет (Модель); С таким определением многие не согласны.
                              7. Для того, чтобы уменьшить связываемость кода; — не основное назначение MVC
                              8. Реализация паттерна MVC; MVC — не паттерн.

                              Код не читал.
                                0
                                так у вас скорее всего свой внутренний фреймворк
                                большой проект без фрейворка (в принципе, а не то что это какой-то известный) не потянуть, имхо
                                  +1
                                  Нет ничего, что подпадает под определние фреймворка. Кстати, а Linux на каком фреймворке написан?
                                    +1
                                    бог его знает на чём он написан :)
                                    но если верить вики (а в данном случае, не верить ей у меня оснований нет): Это каркас программной системы (или подсистемы). Может включать вспомогательные программы, библиотеки кода, язык сценариев и другое ПО, облегчающее разработку и объединение разных компонентов большого программного проекта. Обычно объединение происходит за счёт использования единого API.
                                    такими свойствами обладает любой более-менее большой проект
                                      +2
                                      Как по мне — не очень удачное определение, нужно уточнать что такое каркас программной системы…
                                      Ядро системы также подпадает под это определение(.
                                      Ядро != framework?
                                        0
                                        а почему так сразу и !=? в контексте очень может стать ==

                                        в общем, я думаю мы долго можем кидаться словами, но это будет уже неинтересно :)
                                  0
                                  перед этим всем нужно ставить ИМХО. Так как моё мнение и мнения других людей может отличаться. Перечень всех достоинств, недостатков касательно различных фреймворков и шаблонов проектирования можно перечислять часами, и все они будут верными. Что-то новичок найдёт для себя полезным и не допустит в будущем многих ошибок, а что-то и опытный разработчик. За последние 10 лет разработал множество узконаправленных фреймворков, поэтому в этой статье я хотел донести до начинающих некоторые аспекты программирования.
                                    0
                                    Это все было бы спорным вопросом/ИМХО, если бы вы не употребляли: Самое главное, однозначно, автоматически, в любом случае, единственная

                                    Просто, после прочтения статьи, у юнных программистов может сложится не очень правильное мнение и понимание, что очень-очень плохо…

                                    P. S. >За последние 10 лет разработал…
                                    Я не пытаюсь поставить под сомнение ваш опыт и интелект, я указываю на проблемки в статье с надеждой, что они будут исправленны. В свое время, меня заставили 2 дня мою первую статью переделывать.
                                      0
                                      всегда «ЗА» аргументированную критику.
                                        0
                                        … но тем не менее, главный смысл раскрыт в этой статье.
                          +3
                          И все же MVC — это парадигма программирования, а не шаблон проектирования. Вот при реализации MVC уже используются различные шаблоны проектирования.

                          Парадигма в отличии от шаблона не требует какой-то жесткой архитектуры, как хотите, так и делайте.
                            0
                            О недостатках фреймворков можно почитать, к примеру, здесь. На мой взгляд, автор топика черезчур категоричен.

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

                            Самое читаемое