<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
	<title>Хабрахабр:  Метки / oop</title>
	<link>http://habrahabr.ru/rss/tag/oop/</link>
	<description><![CDATA[]]></description>
	<language>ru</language>
	<managingEditor>editor@habrahabr.ru</managingEditor>
	<generator>habrahabr.ru</generator>
	<pubDate>Sat, 11 Feb 2012 01:45:57 GMT</pubDate>
	<lastBuildDate></lastBuildDate>
	<image>
		<link>http://habrahabr.ru/</link>
		<url>http://habrahabr.ru/i/logo.gif</url>
		<title>Хабрахабр</title>
	</image>
	
		
		
		
		
		
			
		<item>		
			<title><![CDATA[PHP / [Опрос] На основе каких возможностей PHP и каким способом вы разрабатываете приложения?]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/php/137433/</guid>
			<link>http://habrahabr.ru/blogs/php/137433/</link>
			<description><![CDATA[]]></description>
			
			<pubDate>Wed, 01 Feb 2012 16:53:49 GMT</pubDate>
			<author>aur</author>
			<category>php</category><category>ооп</category><category>структурное программирование</category>
		</item>
		
		
		
	
			
		<item>		
			<title><![CDATA[Программирование / Паттерны ООП в метафорах]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/programming/136766/</guid>
			<link>http://habrahabr.ru/blogs/programming/136766/</link>			
			<description><![CDATA[<img src="http://habrastorage.org/storage2/e54/929/b5c/e54929b5c86dfd0285412c81922cfb59.jpg" align="right"/> Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно. <br/>
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/programming/136766/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sun, 22 Jan 2012 17:18:02 GMT</pubDate>
			<author>evgenyl</author>
			<category>паттерны</category><category>ооп</category><category>шаблоны проектирования</category>
		</item>
		
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[PHP / Protected, Private и переопределение]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/php/136560/</guid>
			<link>http://habrahabr.ru/blogs/php/136560/</link>			
			<description><![CDATA[<h5>Создаём свойства</h5><br/>
При создании свойства класса, может возникнуть вопрос, как его объявить: <i>private</i> или <i>protected</i>?<br/>
Отличаются эти варианты тем, что <i>protected</i> виден классам-наследникам, а <i>private</i> нет.<br/>
И это даёт нам возможность скрыть от наследников переменную, чтобы они не напортачили в ней.<br/>
То есть, в большинстве случаев мы должны стремиться к тому, чтобы все свойства были <i>private</i>.<br/>
<br/>
Классу-наследнику, вполне возможно, потребуется получать это свойство — для этого в родителе можно создать protected метод.<br/>
<pre><code class="php">class Example
{
	private $field;

	protected function getField()
	{
		return $this-&gt;field;
	}
}
</code></pre><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/php/136560/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Thu, 19 Jan 2012 00:09:00 GMT</pubDate>
			<author>EugeneOZ</author>
			<category>php</category><category>oop</category>
		</item>
		
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Проектирование и рефакторинг / Объектно-ориентированная разработка инсталлятора Gin]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/refactoring/135310/</guid>
			<link>http://habrahabr.ru/blogs/refactoring/135310/</link>			
			<description><![CDATA[<a href="http://habrahabr.ru/blogs/refactoring/134439/">Ссылка на первую часть</a><br/>
<a href="http://habrahabr.ru/blogs/refactoring/134512/">Ссылка на вторую часть</a><br/>
<a href="http://habrahabr.ru/blogs/refactoring/134439/">Ссылка на третью часть</a><br/>
<br/>
<h4>Ввод данных</h4><br/>
<br/>
Любой инсталлятор должен давать пользователю возможность вводить некоторые стартовый параметры, например, путь к папке, куда будет инсталлирована программа, строка подключения к базе данных, и т.д. Причем, хотелось бы, чтобы это были не просто текстовые поля, а поля, дающие возможность удобного вода данных. Если это путь установки программы, то помимо текстового поля должна быть кнопка «Browse…», если это строка подключения к БД, то пусть рядом будет кнопка для выбора или создания источника данных и т.д.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/refactoring/135310/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Mon, 26 Dec 2011 11:09:17 GMT</pubDate>
			<author>vgrinin</author>
			<category>ООП</category><category>проектирование</category><category>рефакторинг</category><category>разработка</category><category>инсталлятор</category>
		</item>
		
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Проектирование и рефакторинг / Объектно-ориентированная разработка инсталлятора Gin]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/refactoring/134876/</guid>
			<link>http://habrahabr.ru/blogs/refactoring/134876/</link>			
			<description><![CDATA[<a href="http://habrahabr.ru/blogs/refactoring/134439/">Ссылка на первую часть</a><br/>
<a href="http://habrahabr.ru/blogs/refactoring/134512/">Ссылка на вторую часть</a><br/>
<h4>Контентные и контейнерные команды</h4><br/>
Некоторые команды подразумевают работу с файлами, изначально хранимыми на компьютере разработчика пакета. Понятно, что эти файлы нужно вместе с пакетом (а желательно, прямо внутри пакета) доставить к потребителю пакета. Попробуем для начала представить себе как это будет работать. <br/>
У нас есть экземпляр класса PackageBuilder, которому при конструировании мы указываем аргумент PackageBody, содержащий в себе, помимо всего прочего, команду Command, которая представляет собой корневой узел дерева команд пакета. Метод SaveResult() экземпляра класса PackageBuilder должен рекурсивно обойти все дерево, и для тех команд, которые используют контентные файлы, расположенные на компьютере разработчика, включить в тело пакета содержимое всех этих файлов. В тело пакета он также должен включить xml-файл, в который будет сериализован сам PackageBody с полным описанием пакета и выполняемых им команд.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/refactoring/134876/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Mon, 19 Dec 2011 12:17:39 GMT</pubDate>
			<author>vgrinin</author>
			<category>ООП</category><category>проектирование</category><category>рефакторинг</category><category>разработка</category><category>инсталлятор</category><category>контейнер</category>
		</item>
		
		
		
		
		
		
		
		
	
		
			
		<item>		
			<title><![CDATA[JAVA / [Из песочницы] Вариант Singleton на Java]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/java/134637/</guid>
			<link>http://habrahabr.ru/blogs/java/134637/</link>			
			<description><![CDATA[Изучив предложенные в статьях <a href="http://habrahabr.ru/blogs/java/129494/">«Правильный Singleton в Java»</a> и <a href="http://habrahabr.ru/blogs/complete_code/27108/">«Реализация Singleton в JAVA»</a> варианты решений и «пораскинув мозгами», я предположил, что смогу представить еще два похожих друг на друга варианта создания Singleton'а, практически лишенных многих недостатков тех решений, которые были изложены ранее в упомянутых статьях. Но хочу начать с постановки задач, решение которых определит, добились ли мы желаемого результата.<br/>
<br/>
<i>Требования:<br/>
1. Потокобезопасность<br/>
2. Сериализуемость изменений ссылки на объект-Singleton<br/>
3. Управляемость создания объекта в блоке try-catch<br/>
4. Создание объекта-Singleton вне конструктора<br/>
5. Несериализуемое получение ссылки на объект-Singleton, обеспечивающее лучшую производительность.<br/>
6. «Ленивая» инициализация объекта-Singleton<br/>
</i><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/java/134637/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Wed, 14 Dec 2011 22:12:28 GMT</pubDate>
			<author>MayDay7812</author>
			<category>java</category><category>singleton</category><category>синглетон</category><category>oop</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Проектирование и рефакторинг / Объектно-ориентированная разработка инсталлятора Gin]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/refactoring/134512/</guid>
			<link>http://habrahabr.ru/blogs/refactoring/134512/</link>			
			<description><![CDATA[<a href="http://habrahabr.ru/blogs/refactoring/134439/">Ссылка на первую часть</a><br/>
<h4>Транзакции.</h4><br/>
Напомню, что я собирался реализовать механизм транзакций, позволяющий откатывать блоки операций при возникновении ошибки внутри блока, защищенного транзакцией. Сначала надо решить вопрос с ответственностью за сохранение состояния и за откат операции. Скажу сразу, что архитектура, которую я приведу ниже вырисовалась у меня не сразу, а только после нескольких попыток проектирования и реализации макета, пока у меня не получилось то, что получилось.<br/>
Для того, чтобы архитектура транзакций была легко наращиваемой, воспользуемся как и ранее наследованием. При этом возложим ответственность за сохранение состояние и откат к сохраненному состоянию на саму команду. Учтем при этом, что не все команды являются по сути транзакционными. Например, чтение из реестра не может быть частью транзакции, потому что оно ничего не изменяет в системе. А вот запись в реестр – это уже часть транзакции. И создание файла – это часть транзакции.<br/>
А поэтому объявим еще один абстрактный класс TransactionalCommand, унаследуем его от класса Command. <br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/refactoring/134512/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Wed, 14 Dec 2011 05:44:31 GMT</pubDate>
			<author>vgrinin</author>
			<category>ООП</category><category>проектирование</category><category>рефакторинг</category><category>разработка</category><category>инсталлятор</category><category>транзакции</category>
		</item>
		
		
		
		
		
		
		
		
	
		
			
		<item>		
			<title><![CDATA[Проектирование и рефакторинг / [Из песочницы] Объектно-ориентированная разработка инсталлятора Gin]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/refactoring/134439/</guid>
			<link>http://habrahabr.ru/blogs/refactoring/134439/</link>			
			<description><![CDATA[<h4>Введение</h4><br/>
У предлагаемого вашему вниманию цикла статей есть несколько основных целей:<br/>
<ol>
<li>Создать полезное программное обеспечение – инсталлятор программ и обновлений.</li>
<li>Показать преимущества объектно-ориентированного подхода к разработке ПО и научить создавать легко расширяемые программные архитектуры.</li>
</ol><br/>
В данном цикле статей я хочу поделиться историей создания программного обеспечения, позволяющего производить установку и обновление программных продуктов компании при помощи пакетов. Необходимость создания собственного инсталлятора(с отказом от использования готовых решений) вызвана специфичностью требований к инсталлятору. Я не буду углубляться в обоснование необходимости разработки, так как тема цикла статей другая.<br/>
Основными требованиями к разрабатываемой архитектуре будут:<br/>
<ol>
<li>Реализация механизма транзакций, причем транзакции могут включать в себя не только SQL-транзакции, но и файловые, а также транзакции, связанные с изменением любых других ресурсов ОС, таких как записи в реестре, изменения конфигурационных файлов и т.д.</li>
<li>Расширяемость операционной базы инсталлятора, то есть, добавление новых типов команд(операций), как с поддержкой транзакций, так и без нее.</li>
</ol><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/refactoring/134439/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Mon, 12 Dec 2011 10:12:30 GMT</pubDate>
			<author>vgrinin</author>
			<category>ООП</category><category>проектирование</category><category>рефакторинг</category><category>разработка</category><category>инсталлятор</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Разработка / Плотный код и его тестирование]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/development/133957/</guid>
			<link>http://habrahabr.ru/blogs/development/133957/</link>			
			<description><![CDATA[Данная статья написана по следам статьи <a href="http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html">Steve Yegge. A portrait of a n00b</a> (с подачи <a href="http://habrahabr.ru/blogs/development/127635/">хабраперевода</a>). Для меня основной посыл статьи прозвучал так — меньше комментариев, меньше классов, меньше методов, больше кода. Делайте код плотнее, не усердствуйте в моделировании. Мне сложно судить это видение мира, да и вообще вопрос комментариев как таковых больше умозрительный. Но вот что засело во мне стальной иглой, так это проблема тестирования такого плотного кода.<br/>
<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/development/133957/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sun, 04 Dec 2011 09:50:58 GMT</pubDate>
			<author>uj2</author>
			<category>unit-testing</category><category>ood</category><category>oop</category>
		</item>
		
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[JavaScript / ООП в JavaScript]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/javascript/132698/</guid>
			<link>http://habrahabr.ru/blogs/javascript/132698/</link>			
			<description><![CDATA[Хочу представить вам функцию-конструктор классов createClass.<br/>
Чем хорош этот конструктор:<br/>
1. Сам код выглядит более читабельным и понятным<br/>
2. Поддержка множественного наследования<br/>
3. Поддержка абстрактных методов<br/>
4. <b>Наследование статических методов и свойств класса</b><br/>
5. Умный метод instanceOf (проверяет по всей цепочке классов)<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/javascript/132698/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Tue, 15 Nov 2011 20:44:14 GMT</pubDate>
			<author>dbelka</author>
			<category>ооп</category><category>ооп js</category><category>js</category>
		</item>
		
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Интерфейсы / Объектно-ориентированный подход в интерфейсах]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/ui/131384/</guid>
			<link>http://habrahabr.ru/blogs/ui/131384/</link>			
			<description><![CDATA[Появление концепции объектно-ориентированного программирования кардинально изменило подход к разработке приложений, что позволило реализовывать гораздо более сложные проекты. Каждый программист понимает, что объектно-ориентированная философия позволяет не столько облегчить разработку, сколько облегчить понимание проекта, самой предметной области. Есть объект, и исходя из сущности этого объекта у него есть множество методов работы с ним. Казалось бы, что может быть проще и логичнее?<br/>
Тогда почему эту же методологию не применять при разработке интерфейсов? Рассмотрим пример списка контактов мобильного телефона.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/ui/131384/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Thu, 27 Oct 2011 23:12:56 GMT</pubDate>
			<author>sirQaziop</author>
			<category>интерфейсы юзабилити</category><category>ооп</category><category>мобильные устройства</category>
		</item>
		
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[Lisp / Обобщенные функции CLOS]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/lisp/131026/</guid>
			<link>http://habrahabr.ru/blogs/lisp/131026/</link>			
			<description><![CDATA[Любой разработчик, так или иначе столкнувшийся с объектно-ориентированным программированием, и попытавшийся в нем разобраться, обязательно слышал про <abbr title="Common Lisp Object System">CLOS</abbr>, объектную систему языка Common Lisp, одной из основополагающих фич которой являются так называемые «обобщенные функции», или, в народе, «мультиметоды».<br/>
<br/>
Хотя многие считают, что обобщенные функциии это просто аналог статической перегрузки функций, но только в динамике, это совершенно неверно.<br/>
Не совсем правильно будет даже сказать, что это расширение диспетчеризации по self/this, то есть «виртуальных функций», на несколько аргументов.<br/>
<br/>
Безусловно, множественная диспетчеризация является одной из основных фишек обобщенных функций, но сама их суть не только, и даже не столько, в этом.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/lisp/131026/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sun, 23 Oct 2011 16:20:33 GMT</pubDate>
			<author>love5an</author>
			<category>lisp</category><category>common lisp</category><category>CLOS</category><category>multiple dispatch</category><category>multimethods</category><category>generic functions</category><category>множественная диспетчеризация</category><category>мультиметоды</category><category>обобщенные функции</category><category>ООП</category>
		</item>
		
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[JavaScript / Серия 2. Как выполнять методы предков в модификации прототипного наследования]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/javascript/130713/</guid>
			<link>http://habrahabr.ru/blogs/javascript/130713/</link>			
			<description><![CDATA[<img align="right" src="http://s017.radikal.ru/i409/1110/3b/f899e3d4554c.png" alt="image"/>Оформим начатое в <a href="http://habrahabr.ru/blogs/javascript/130495/">habrahabr.ru/blogs/javascript/130495/</a> в удобный для использования метод <i>.inherit4</i> конструктора <i>Constr</i>, чтобы, фактически построить модель классов и наследования (она будет более мощной, чем классическая, но это побочный эффект). Если у Вас нет желания подключать Mootools с аналогичной моделью, будет достаточно этого метода на 2 КБ несжатого кода, чтобы нормально работать с прототипным наследованием и иметь пару дополнительных методов: доступ к методам предков <i>.ancestor('имя_метода', номер_поколения_предка</i>) и расширение хешей. Применение всех 3 методов позволяет исключить из лексикона слова <i>prototype</i> и <i>constructor</i>, продолжая работать с тем и другим, и делает код легко читаемым.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/javascript/130713/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Wed, 19 Oct 2011 03:10:47 GMT</pubDate>
			<author>spmbt</author>
			<category>javascript</category><category>ооп</category><category>ооп js</category><category>наследование</category><category>доступ к объектам</category>
		</item>
		
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[JavaScript / Как выполнять методы предков в реализации прототипного наследования]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/javascript/130495/</guid>
			<link>http://habrahabr.ru/blogs/javascript/130495/</link>			
			<description><![CDATA[При работе с наследованием иногда возникает желание иметь функцию доступа к методу предка (методу родительского класса) — в конструкторе (аналоге класса для Javascript) или в методе-потомке, потому что, бывает, что новый класс переопределяет его. Не просто какую-нибудь функцию (метод), а с совершенно понятной записью, чтобы название говорило само за себя, и имеющую доступ к указанному поколению предков (не «пра-пра-пра-», а «пра- 3 раза»).<br/>
<br/>
Возьмём за основу метод прототипного наследования, который максимально эффективен тем, что производит минимум действий при описании цепочек наследуемых классов и при этом максимально поддерживает базовые операции и свойства наследования: <i>instanceof, constructor</i>. Для доступа к предку он создаёт свойство <i>.superclass</i>.<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/javascript/130495/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sun, 16 Oct 2011 04:52:39 GMT</pubDate>
			<author>spmbt</author>
			<category>javascript</category><category>ооп</category><category>ооп js</category><category>наследование</category><category>доступ к объектам</category>
		</item>
		
		
		
		
		
		
		
		
	
		
		
		
		
		
			
		<item>		
			<title><![CDATA[C++ / [Опрос] На какие из вопросов вы можете с уверенностью ответить?]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/cpp/129544/</guid>
			<link>http://habrahabr.ru/blogs/cpp/129544/</link>
			<description><![CDATA[]]></description>
			
			<pubDate>Sat, 01 Oct 2011 21:20:43 GMT</pubDate>
			<author>k06a</author>
			<category>программирование</category><category>ООП</category><category>паттерн</category><category>SOLID</category><category>деструктор</category>
		</item>
		
		
		
	
			
		<item>		
			<title><![CDATA[Программирование / ООП — Организация Освобождения Палестины]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/programming/129534/</guid>
			<link>http://habrahabr.ru/blogs/programming/129534/</link>			
			<description><![CDATA[Эта статья является изложением в письменном виде моего личного восприятия программирования и Объектно-ориентированного программирования в частности. Здесь собраны и душевные негодования, и переживания за программистов всего мира. Всё, конечно же, подкреплено исходным кодом.<br/>
<br/>
<img src="http://habrastorage.org/storage1/dff4424c/35f98f60/d79538d1/0b12d3b5.png" align="center"/><br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/programming/129534/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sat, 01 Oct 2011 20:39:00 GMT</pubDate>
			<author>k06a</author>
			<category>программирование</category><category>ООП</category><category>интерфейс</category><category>SOLID</category>
		</item>
		
		
		
		
		
		
		
		
	
		
		
		
		
		
			
		<item>		
			<title><![CDATA[Разработка / [Опрос] Используете ли вы REPL?]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/development/128818/</guid>
			<link>http://habrahabr.ru/blogs/development/128818/</link>
			<description><![CDATA[]]></description>
			
			<pubDate>Tue, 20 Sep 2011 15:59:09 GMT</pubDate>
			<author>iley</author>
			<category>repl</category><category>ооп</category><category>фп</category>
		</item>
		
		
		
	
		
			
		<item>		
			<title><![CDATA[PHP / [Из песочницы] И снова MVC]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/php/127798/</guid>
			<link>http://habrahabr.ru/blogs/php/127798/</link>			
			<description><![CDATA[Привет Хаброобществу.<br/>
<br/>
Однажды мне на глаза попалась статья с хабра <a href="http://habrahabr.ru/blogs/php/31270/">ссылка</a>. Попробовав ту систему, пришел к выводу, что у нее много недостатков, да и перевод оригинальной статьи присутствовал не полностью. Да, статья старючая, но в то же время хотелось написать свой небольшой фреймворк для создания простых и средних по сложности сайтов. Так как тащить с собой 2-3 мегабайта какого-либо серьезного фреймворка для создания сайта-визитки считаю кощунством (хоть и не всегда).<br/>
<br/>
Вообщем, решил исправить бросающиеся в глаза недостатки и полученным результатом поделиться с хаброжителями.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/php/127798/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Mon, 05 Sep 2011 17:03:04 GMT</pubDate>
			<author>cooperua</author>
			<category>php</category><category>mvc framework</category><category>oop</category>
		</item>
		
		
		
		
		
		
		
	
		
			
		<item>		
			<title><![CDATA[C++ / [Из песочницы] Про абстракции и метод рефакторинга «Extract method»]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/cpp/126227/</guid>
			<link>http://habrahabr.ru/blogs/cpp/126227/</link>			
			<description><![CDATA[Абстракции чрезвычайно важны в программировании и это все знают. Они помогают нам отделить существенные детали чего бы то ни было от несущественных. В идеале они должны выделять только самое главное, эссенцию, без всяких посторонних примесей, минимум характеристик объекта или процесса, но идеал встречается не так уж и часто.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/cpp/126227/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Sun, 14 Aug 2011 16:02:59 GMT</pubDate>
			<author>Katmai</author>
			<category>ООП</category><category>абстракция</category><category>c++</category><category>рефакторинг</category><category>выделение метода</category><category>читаемость кода</category>
		</item>
		
		
		
		
		
		
		
	
			
		<item>		
			<title><![CDATA[JavaScript / Замыкания и объекты JavaScript. Переизобретаем интерпретатор]]></title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/javascript/125306/</guid>
			<link>http://habrahabr.ru/blogs/javascript/125306/</link>			
			<description><![CDATA[<img src="http://habrastorage.org/storage1/1c475b4f/d44a68c9/69554021/04a57dbc.jpg" align="left"/>Обычно концепции или парадигмы программирования объясняют либо описательно — «разжёвывая» новые идеи простыми словами, либо метафорически — уподобляя их хорошо знакомым аудитории предметам и понятиям. Но ни первый, ни второй способ не дает такого точного и полного представления о предмете, как взгляд с точки зрения низкоуровневой реализации. <br/>
<br/>
Когда в изучении языка доходишь до нетривиальных вещей, бывает полезно сместить уровень абстракции, чтобы понять, как на самом деле всё устроено. Ведь, по большому счету, любые понятия и конструкции языков сколь угодно высоко уровня сводятся к старому доброму машинному коду. Писать в объектно-ориентированном или функциональном стиле можно и на чистом C, и даже на ассемблере. Грубо говоря, любой высокоуровневый язык — это зафиксированный на уровне компилятора или интерпретатора набор синтаксических карамелек и шоколадок. Повышение уровня абстракции позволяет писать более сложные программы с меньшими усилиями, но вот понять в начале пути, что конкретно имеется в виду под наследованием или замыканием, как это всё работает и почему, гораздо легче, разобравшись, каким образом всё это реализовано.<br/>
<br/>
JavaScript, как никакой другой язык, нуждается в именно таком объяснении. Функциональная природа, скрытая за Си-подобным синтаксисом, и непривычная прототипная модель наследования поначалу сильно сбивают с толку. Давайте мысленно понизим уровень JavaScript до простого процедурного, наподобие Си. Отталкиваясь от этого «недоязыка», переизобретем функциональное и объектно-ориентированное программирование.<br/>
<div class="habracut"> <a class="habracut" href="http://habrahabr.ru/blogs/javascript/125306/#habracut">Читать дальше &rarr;</a> </div>]]></description>
			
			<pubDate>Tue, 02 Aug 2011 12:46:04 GMT</pubDate>
			<author>ilya42</author>
			<category>JavaScript</category><category>замыкания</category><category>ООП</category><category>ФП</category><category>наследование</category><category>интерпретатор</category>
		</item>
		
		
		
		
		
		
		
		
	
	
	
	
	
	
	
	

	
</channel>
</rss>

