если я хочу обеспечить максимальную переносимость, то я воспользуюсь ORM или в крайнем случае напишу одну фабрику и ровно один интерфейс, который нужно будет реализовывать
там используются шаблоны везде где только можно, но не только там где нужно.
Шаблоны не панацея и использовать их тоже следует с умом.
насчет расширяемости… Ну вот этот топик отлично показал сколько нужно танцев с бубном, что бы добавить один чекбокс. Возможно кто-то это назовет «хорошей расширяемостью» :)
знаете, я был у истоков ядра магенты и вот что могу сказать… УПАСИ ГОСПОДИ
архитектура не проектировалась не документировалась и разрабатывалась большим числом приходящих и уходящих разработчиков.
Так что вот как-то так.
Пы.Сы. Уже давно не видел магенту. В исходном варианте у нее все еще 120 таблиц в БД или уже стуло лучше? :)
открываем спецификацию и чатаем:
«поделки, которые не удовлетворяют хотя бы единственному правилу MUST или REQUIRED не являются сервером»
теперь отсалось выбрать любое неудовлетворенное правило. вот это нам подходит:
«The methods GET and HEAD MUST be supported by all general-purpose servers»
Да и давайте руководствоваться здравым смыслом: HTTP-сервер имеет правл на жизнь, если он удовлетворяет хотя бы основную потребность — получать доступ к удаленным ресурсам по URI
Ваш «http-сервер» это то же самое ечли бы я написал ftp-сервер, который всегда отдает один и тот же «файл». Толку никакого, но чем-то на ftp было бы похоже.
В любом случае, если Вам хочется называть ЭТО http-сервером — никто Вам этого не запретит
но продолжим — HTTP-сервер должен обращаться к ресурсам на серверной машине и в зависимости от доступности и типа ресурса возвращать заголовки, а не постоянно отдавать «зашитые» в сервер данные.
HTTP-сервер гараздо сложнее. Ваша абстракция очень далека от реальности :)
Ой, знаете, тогда уж стоит сказать что он не только HTTP запросы принимает, но и FTP и SMTP и все что угодно.
так давайте назовем Вашего демона FTP-сервером, почтовым сервером и «системой управления ядерным реактором» (с)
понимаете, http-сервер это чуть больше чем получить произвольные данные в сокет от клиента и передать ему произвольные данные. HTTP сервера соответствуют спецификациям, а Ваш даже не отдает заголовки ответа
проблема видимо в том, что Ваш «http-сервер» не принимает HTTP-запросов и не отдает HTTP-ответы. Именно поэтому он не HTTP-сервер, а просто демон, который висит в памяти и слушает указаный порт…
да и рассказать о «соли каждого» — на это может уйти много часов :)
GoF, GRASP, доп.шаблоны от Кириевски и Фаулера, шаблоны рефакторинга… да мало ли чего еще
многие смогут ответить, но при этом их ожидания в ЗП превзойдут возможности компании :)
когда-то, когда ходил по собеседованиям, тоже пытались по многим технологиям сразу гонять, но денег за весь этот набор в одном человеке платить достойных не хотели…
обходиться — это одно, а удобство — это другое.
точно так же можно обойтись без ООП, без ОРМ и без фреймворков. А еще лучше писать сразу на асме и без документации.
строгая типизация — отличный способ улучшить взаимодействие в команде
помощь посредством title — плохо, так как текста много, а показывается тайтл мало — не успеваю прочитать
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Шаблоны не панацея и использовать их тоже следует с умом.
насчет расширяемости… Ну вот этот топик отлично показал сколько нужно танцев с бубном, что бы добавить один чекбокс. Возможно кто-то это назовет «хорошей расширяемостью» :)
архитектура не проектировалась не документировалась и разрабатывалась большим числом приходящих и уходящих разработчиков.
Так что вот как-то так.
Пы.Сы. Уже давно не видел магенту. В исходном варианте у нее все еще 120 таблиц в БД или уже стуло лучше? :)
открываем спецификацию и чатаем:
«поделки, которые не удовлетворяют хотя бы единственному правилу MUST или REQUIRED не являются сервером»
теперь отсалось выбрать любое неудовлетворенное правило. вот это нам подходит:
«The methods GET and HEAD MUST be supported by all general-purpose servers»
Да и давайте руководствоваться здравым смыслом: HTTP-сервер имеет правл на жизнь, если он удовлетворяет хотя бы основную потребность — получать доступ к удаленным ресурсам по URI
Ваш «http-сервер» это то же самое ечли бы я написал ftp-сервер, который всегда отдает один и тот же «файл». Толку никакого, но чем-то на ftp было бы похоже.
В любом случае, если Вам хочется называть ЭТО http-сервером — никто Вам этого не запретит
но продолжим — HTTP-сервер должен обращаться к ресурсам на серверной машине и в зависимости от доступности и типа ресурса возвращать заголовки, а не постоянно отдавать «зашитые» в сервер данные.
HTTP-сервер гараздо сложнее. Ваша абстракция очень далека от реальности :)
так давайте назовем Вашего демона FTP-сервером, почтовым сервером и «системой управления ядерным реактором» (с)
понимаете, http-сервер это чуть больше чем получить произвольные данные в сокет от клиента и передать ему произвольные данные. HTTP сервера соответствуют спецификациям, а Ваш даже не отдает заголовки ответа
GoF, GRASP, доп.шаблоны от Кириевски и Фаулера, шаблоны рефакторинга… да мало ли чего еще
когда-то, когда ходил по собеседованиям, тоже пытались по многим технологиям сразу гонять, но денег за весь этот набор в одном человеке платить достойных не хотели…
точно так же можно обойтись без ООП, без ОРМ и без фреймворков. А еще лучше писать сразу на асме и без документации.
строгая типизация — отличный способ улучшить взаимодействие в команде