Ив такой мере, то чего мы так-с долго ждали свершилось. Выкладываю в одном архиве все информационные программы для Беларуси: Belarus Map, Belarus Phones – они же Megacontacts, cityinfo 2.7 со всеми обновлениями, База Velcom, и каталог Бизнес-Беларусь 08-09.
Ик примеру данный архив программ для Беларуси включает в себя:
Belarus Map v2.0 – последняя версия электронной карты Беларуси.Очень полезная вещь, когда бумажной карты нет под рукой. Для установки создайте непраздничный каталог C:\Belarus, скопируйте тама все файлы и запустите Rbmap.exe.
Belarus Phones 2007 – заключает в себе справочник городских телефонов Беларуси Megacontacts, сказывай также базы MTS BEST DIALOG в текстовых файлах. Для установки нетрудно распакуйте архив в нужную вам директорию. В нем появятся две папки – в одной мегаконтакты, они установки не требутют, прямо запускаете установочный файл и папка вместе с базами мтса, беста и диалога. Там потребуется еще изредка распаковать архив, и вы получайте все базы в текстовых файлах которые можно просматривать блокнотом либо другим текстовым редактором.
ESMA Minsk3D 2.70.2 - она же , которую мы уже выкладывал, повторюсь по какой причине тут полная карта Минска, которая позволит вам нанести (линию) кратчайший маршрут к необходимому вам месту либо нехитро просмотреть достопримечательности Минска.
Velcom 2006 – база телефонных номеров Velcom 2006 года выпуска. Распаковываете и наслаждаетесь полным на оный момент справочником абонентов велкома.
Бизнес-Беларусь 08-09 – в конечном счете каталог бизнес предприятий Беларуси. Может быть полезен для организаций, от целью обзвона, отправки факсов потенциальным клиентам.
Все сии программы вы можете переписать в едином архиве по ссылке ниже начиная с. Ant. до моего сайта.
Отличный подарок для любителей брутальных гаджетов и для каждого, кто собирается править (справлять) праздник мексиканский карнавал мертвецов (в этом случае не забудьте употребить яркие краски)!
Настольная зловеще воспроизводит вашу музыку и не менее зловеще сверкает глазами (опять же, первых порах) вы не раскрасите ее к карнавалу – сие нивелирует зловещий эффект).
Ознакомиться вместе с техническими характеристиками и забрать этот стильный компьютерный принадлежност можно в интернет-магазине гаджетов .
Шрифты – оружие вывода текстовой информации на холст компьютера. Очень убыстренно для важных проектов тебуются нестандартные шрифты, но к сожалению в большинстве операционных систем шрифтов довольно мало, и для сего необходимо установить дополнительные шрифты. Для многих людей данный катагенез покрыт завесой тайны. Давайте же его приоткроем и узнаем как ввести шрифты правильно?
Где взять шрифты
Для того ради установить шрифты нужно их где так взять. Я могу врезать что стоит вам один набрать в поисковике оборот "китайские шрифты" или " необычные шрифты" или рукописные шрифты" и в одно время вылезет куча сайтов, начиная с. Ant. до подробными описаниями и ссылками для состязание. Я даже могу угостить вам скачать свой минимальный набор шрифтов , в котором 904 шрифта на любой вкус (80 мб). Значит переходите по ссылке, скачиваете их на компьютер и можно переходить к следующему этапу.
Как поставить шрифты
Скачанные шрифты должны быть вместе с расширением ttf либо .FON на крайний трагедия. Если у них дилатация .zip либо .rar ведь тогда их нужно для начала распаковать. После что-что открываем Пуск->Панель управления->Шрифты и строго перетаскиваем туда ваши распакованные шрифты. Либо копируем их клавишами ctrl+c ctrl+v. Теперь вы знаете как найти шрифты, причем установленные по ёбаный методике шрифты будут отображаться сию минуту во всех программах, которые их используют – пейнт, фотошоп ворд и другие. Но не советую монтировать слишком много шрифтов, по всем правилам как возрастет нагрузка на компьютер и все будет ломать хрип чуть медленнее.
Philips представила на юстиция пользователей весь свой модельный семейство 3D LCD HDTV на текущий год. Все модели поддерживают 3D, но в их комплект поставки не входят 3D модуль и стерео очки и пользователям придется купить их отдельно и подключить к телевизору при помощи порт HDMI. Более того, они не обладают интегрированным модулем FreeView HD.
Пока неясно, вследствие этого Philips пошла на такого порядка шаг, так как её конкуренты, в томик числе Panasonic, Sony, Samsung и LG Electronics дали раскусить, что их новейшие 3D HDTV будут оснащены модулями FreeView HD. Правда, какими судьбами касается качества изображения на новых 3D HDTV Philips, в таком случае оно просто безупречно, и в этом большая заслуга системы подсветки на базе светодиодов (LED). Если модели из серии 7000 и 8000 оснащены системой LED подсветки как edge-backlight (светодиоды расположены по периметру экрана), в таком случае модели из серии 9000 сделано могут похвастаться LED подсветкой локального затемнения (local dimming) и видеопроцессором Pixel Perfect HD Engine. Еще отметим, яко весь модельный ряд 3D HDTV Philips на таковой год поддерживает технологию Ambilight, аюшки? частота обновления их экрана составляет 400 Гц.
Напомним, зачем уже много лет Philips слышно производителем HDTV №1 в Европе.
Dell предприняла очередную попытку модернизировать принадлежащий Netbook Inspiron Mini 10. Как выходит известно, производитель PC №2 в мире официально объявила о выходе нового пакета Performance Plus Package для этой модели, и у покупателей данный) момент появилась возможность её оснастить графической картой Broadcom Crystal HD. Как заявлено, со её помощью Dell Mini 10 запросто справится со воспроизведением видео HD в разрешении 1080p на своем 10,1-дюймовом дисплее, ась? не скажешь о базовой версии, которая использует интегрированную графику Intel GMA 3150.
Стоит отметить, почто Dell Mini 10 Performance Plus Package имеет более вместительный жёсткий диск 250 Гбайт, ан не 160 Гбайт, как в случае со базовой версией. Более того, данная версия будет поставляться не без; Windows 7 Starter, сказывай не Windows XP Home. Наконец, клиентура. Ant. продавцы еще получат не 3-, ах 6-элементный аккумулятор Li-Ion повышенной ёмкости. Правда, за неё вам придется выложить еще не 299, а 409 долларов США, если, конечно, хотите циклопить видео Full HD на своем Inspiron Mini 10.
Smartbook AG официально объявила, отчего она намерена выставить на всеобщее обозрение один из своих новейших smartbook на предстоящей выставке CeBIT ‘10, которая откроется на следующей неделе в Ганновере, Германия. Как заявили немцы, данная модель построена на базе платформы Intel CULV и обладает 1 Гбайт RAM, жёстким диском 250 Гбайт. Мобильное налаживание оснащено 11,6-дюймовым дисплеем со стандартным разрешением 1366×768 и встроенным модулем беспроводной рука 3G (UMTS). В его комплект поставки входит довольно вместительный источник, который, как утверждает Smartbook AG, может обеспечить автономную работу в майдан 8 часов.
Как мы видим, данная модель очень похожа на Netbook по всем показателям, тем более зачем её вес составляет 1,3 кг, и зачем не менее важно, она работает под Windows 7. Тем не менее, немцы настаивают, кое-что это действительно Smartbook, же не Netbook. Кинак ожидается, она будет запущена в продажу по цене 699 евро (943 доллара по текущему курсу).
Как сообщает Fudzilla, самый мощный вычислитель для настольных систем в модельном ряду Intel, Core i7-980 Extreme Edition, начинает идти в продажу в Европе. По крайней мере, на данный момент он еще доступен для предварительного заказа в Alternate.de по цене 1099 евро, же поставки намечены на 14 марта.
Напомним, какими судьбами Core i7-980 Extreme Edition является единственным шестиядерным процессором для desktop в портфолио Intel на данный момент. Он изготовлен по техпроцессу 32 нм и основан на микроархитектуре Westmere. Процессор обладает 12 Мбайт кэша L3, поддерживает память DDR3 1066, HyperThreading/Simultaneous MultiThreading и может раздуться до 3,6 ГГц в режиме Turbo Boost, при всем желании угодить моим критикам его номинальная тактовая гармоника составляет 3,33 ГГц.
Кстати, радикальным образом очевидно, что Intel раз-раз снизит стоимость Core i7-975 Extreme Edition, который до последнего времени был флагманом посредь процессоров Intel для desktop.
Помнится, в последней главе саги оборона офисы ЦВТ аз (многогрешный) упомянул переезд из осточертевшего старого офиса в ещё не успевший надоесть новый. Сегодня об этом подробнее. Этим постом аз (многогрешный) закрываю тему офисов ЦВТ, подводя её к логическому концу, следовательно, текста будет много. Картинок в свой черед.
Переезд
Переезд в новый офис из старого происходил вместе с воодушевлением и всеобъемлющей радостью. Участие в переезде приняли все, включая , которая имеет привычку свертываться от непосильного труда за границы Родины. Этап упаковки и перевозки барахла она благополучно продинамила, нежась в сие время на калифорнийских пляжах, но по возвращению домой в аккурат успела к финальному этапу — благородному делу окончательной уборки помещения после этого переезда.
Во время переезда геройски проявили себя считай все, выделять кого-ведь одного было бы нечестно по отношению к остальным. Сам протекание прошёл без эксцессов, несмотря на в таком случае, что длился целую неделю, потом с учётом предварительной подготовки и финальной уборки — аж три. За сие время ничего не было потеряно или сломано, никто не отстал от поезда и не заблудился. Спасибо грамотным планировщикам.
Краткий фотоотчёт «Переезд в лицах»
впервые за два года оторвали от монитора. Он не понимает, чего происходит, кто эти люди и вследствие того он должен переезжать куда-в таком случае именно сейчас, когда до конца рендера осталось всего лишь два дня.
В голубых глазах Натальи светится решимость переехать ещё один раз куда угодно, если на так будет постановление руководства.
Лера не без; Натальей ни разу не согласна. За неделю она основательно утрахалась паковать документацию и шпионить за сохранностью офисного имущества. Но ей ещё повезло, затем что…
…, в конце концов, не выдержал и буднично сошёл с ума.
Этого не знаю.
в остатный раз осматривает опустевшее вселение. Камера запечатлела его в момент произнесения следующей молитвы: «Господи! Когда аз многогрешный выйду отсюда, настолько) (добры, разрушь к чертям… Только не перво-наперво, Господи!»
«Если слушание невозможно остановить, его надо возглавить» — подумал , взяв глава в свои рычаги…
…и вместе от первым в новом офисе получил своё всецело укомплектованное рабочее место.
А в сие время специально найденные на улице таджики и молдаване собирали и расставляли старую мебель по новым местам.
Обустройство
После переезда результате мы получили следующие бонусы:
Одно огромное (~100 м²) светлое просторное зверинец. Ant. вынимание с семью огромными окнами;
Одно каплю менее огромное (~70 м²) глухое червоводня;
Одно маленькое умещение под серверную;
Одно небольшое (складочное) место под кухню;
Одно небольшое покои под переговорную комнату;
Одно нормальных размеров аудитория под туалет.
И всё сие — наше и всего делов наше! Боже, какое участь.
Но были и минусы:
В огромном светлом просторном помещении зимой было апатично, а летом душно. Не было штор на окнах, вентиляция не работала, для проветривания открывались едва только две маленькие форточки в крайних окнах.
Чуть менее огромное глухое карцер кроме аналогичного отсутствия вентиляции заодно имело общую стену начиная с. Ant. до кинотеатром, и мы безостановочно были в курсе всех новинок мирового кинематографа. По крайней мере, научились на сведения определять показываемое кино. Вторые «Трансформеры» обычно в клочья разрывали замкнутое промежуток нашего офиса.
В кухне не было воды и канализации.
В переговорной одну стену дотла занимали огромные электрощиты. Звать тама приличных людей на переговоры было опасно — однако вдруг полезут к проводам от грязными руками?
В комнате под одевание не было самого туалета, так есть унитазов, раковин и всего остального, как будто там ещё полагается. Были едва только голые кирпичные стены и огромное количество стройматериалов. В общем, сделай своими руками, как говорится.
Весь давний год мы мужественно боролись начиная с. Ant. до этими минусами. Теперь у нас есть кондиционеры, жалюзи и шкафы для одежды. Серверы стоят в отдельной комнате из благоприятным климатом и больше не гудят нам впрямую в мозг. Запахи из кухни уходят в нарочно проложенные короба, а оттуда — плевать куда. Шздравость кинотеатра перебивается шумом рабочих процессов, и в настоящий момент уже неизвестно, кто кому больше мешает.
И не более того туалет продолжает представлять собой строительный конструктор, но до него мы прозрачно не добрались ещё.
Из последних мелких радостей жизни у нас недавно появился настоящий кухонный гарнитур с раковиной и горячей водой. Мы даже засняли сие событие.
Краткий фотоотчёт «Блага цивилизации приходят в наш дом»
Сантехник под чутким надзором заканчивает последние работы и проводит последние проверки.
во всем параде перерезает красную ленточку.
Народ бурно аплодирует. на переднем плане рыдает от счастья.
«О, тёпленькая пошла!» — Лере выпала достоинство первой воспользоваться водопроводом.
К раковине скоро же выстроилась очередь желающих помыть близкие чашки. У многих чашки помылись впервые за год, пресекшийся с момента переезда.
Уплотнение
Параллельно от радующим нас обустройством, весь вчерашний год спонсировал ещё и гардвак. Поскольку штат рос, когда новых людей надо было куда-ведь сажать, роскошные огромные мебеля начали заменяться маленькими стандартными рабочими столиками метр-двадцать-на-метр, ай в один гряда столов начали сажать трёх массы вместо двух. Все комнаты раз за разом начали забиваться людьми, ощущение огромного неосвоенного пространства куда-ведь исчезло, и в офисе, дотоль казавшемся просто огромным, сейчас не осталось места, где можно было бы чураться (людей).
По этому поводу мною был придуман отдельный иллюстрированный положение, который должен был бы быть опубликован ещё в ноябре прошлого года, но шелковица мы начали готовиться к ежегодному новогоднему корпоративу. решила, зачем идея этого поста без труда идеально создана для того, для того чтоб быть показанной на большом экране в увеселительном заведении в день корпоратива.
Так и случилось. Публикацию в блоге мы отложили, инак картинки смонтировали в видеоролик. Най премьерном показе долгом) смеялся, а в конце заплакал.
Многие из вас его, возможно, поуже видели этот ролик , но отдельно и полноформатно он публикуется впервые. К сожалению, в видеоверсии идея немного проигрывает, вследствие этого что картинки мелькают быстрее, нежели надо бы, плюс, не желательно перегружать видеоряд субтитрами, отвлекающими от основного действия. Да ещё и сюжетец был сокращён по сравнению из первоначальным замыслом. Но зато можно окинуть взглядом ролик несколько раз подряд, если вместе с первого раза не дойдёт.
Видеосюжет «Увеличение штатов»
Идея — моя, картинки — , анимация и спецэффекты — , музыка —
Всем нравится наблюдать отклик домино, но наблюдать его по-настоящему интересно таким побытом сказать в живую, но для сего нужно потратить уйму времени на расставление в правильном порядке дрожащими от волнения руками, аюшки? если случайно задеть сейчас поставленную, то шоу увидишь одним духом и незамедлительно! Но вот нашлось структура, которое само расставляет и которое само роняет доминушки, же имя ему Домино Ouroborus. Видео внутри.
Домино Ouroborus спроектировано и построено Карлом Лаутменом (Karl Lautman).
Сегодня утречком Pentax официально объявила о выходе весьма уникальной компактной камеры – X90. Как говорится в сообщении для прессы от Pentax по этому случаю, данная модель обладает весьма мощной оптикой: она способна обеспечить 26-кратное оптическое развитие. Более того, с через функции Intelligent Zoom можно приумножить данный показатель до 162,5x.
По официальным данным, Pentax X90 является 12,1-мегапиксельной компактной камерой не без; оптической и цифровой системами стаблизации изображения. Данная модель еще примечательна, тем зачем может распознать до 32 лиц всего за 0,03 секунд даже если фотографируемые люди не смотрят в сторону камеры или отворачиваются от нее. Как и все современные камеры такого класса, она умеет непроизвольно выбирать фокусное расстояние и выдержку. Среди других особенностей можно отметить функцию Small Face Filter, которая, как заявлено, позволяет легонько уменьшить овал лица на фотографии и возможность записи видео HD в разрешении 720p. Если верить Pentax, камера может спроворить до 255 снимков без подзарядки.
Пока неясно, когда Pentax начнет поставки этой модели, но она еще доступна для предварительного заказа при помощи Amazon.com. Розничная такса камеры составляет 399,95 долларов США.
Компания Tanita показала своё видение электронных весов. Устройство оснастили слотом для SD карты и написали под него специализированное программное обеспечение для анализа поступающих данных, ах данные эти ничто иное, как ваш вес, разбитый так сказать по полочкам – жировая, костная, мышечная эпителий…. Гаджет выпускается в двух версиях: BC-309 весом 50 грамм и стоимостью 18000 йен (около $ 200) и BC-569 весом 100 грамм и стоимостью 13000 йен ($ 145), не кажется странным такое корреляция?
Кстати в ПО электронных весов Tanita есть как профили пользователя, примерно сказать и гостя.
Помимо модели X90, нынче утром Pentax еще представила на синклит пользователей довольно интересную камеру – Optio W90. Как заявила японская компания, данная модель относится к категории защищенных компактных камер и ориентирована на тех, кто ведет винтовой образ жизни.
По официальным данным, Optio W90 оснащена 12,1-мегапиксельной матрицей и может обеспечить 5-кратное оптическое разрастание. Что касается степени защиты, в таком случае эта камера спокойно выдерживает падение со высоты 1,2 м, и заметьте, её можно использовать для подводной съёмки на глубине до 6 м. Еще отметим, словно Optio W90 обладает 2,7-дюймовым LCD дисплеем, может стаскивать видео HD в разрешении 720p и умеет выводить отснятый видеоматериал на большие экраны черезо имеющийся порт HDMI. Более того, сия компактная камера полностью поддерживает карты памяти SD Eye-Fi не без; интегрированным модулем Wi-Fi и может рук не покладать на морозе.
Как ожидается, Optio W90 появится в продаже в апреле по цене 329,95 долларов США. Кстати, Pentax обещает выпустить преднамеренный водонепроницаемый чехол для всей линии Optio к тому времени. Его ориентировочная ценность – 29,95 долларов США.
С месяц назад
дорогой благоприятель
в личной беседе посетовал на странные методы объектного
программирования, практикуемые некоторыми программистами. Совершенно
неясно, — говорил он, — зачем сии люди плодят такое множество
интерфейсов, ан потом постоянно кастуют их к реализациям и обратно.
Неясно, зачем к каждому объекту граждане создают свою собственную
фабрику, которая к тому же не является доопределением других, в чем дело? наоборот
каждый раз новая, своя собственная — скопипасченная.
Я ваша правда с
товарищем Дарготом: действительно огромное множество программистов
в корне не в курсе, зачем нужны объектные телосложение абстракций, поэтому
применяют их как нагорело, руководствуясь где-то подслушанными общими
фразами. Вообще, на мой взгляд, закавычка в том, что традиционно обучение
программированию начинается в лучшем случае от процедурного языка — если
не не без; псевдо-языка, лишённого даже процедур и выливающегося в огромную
простыню кода в методе main. В результате такого обучения программисту в
последствии доводится буквально переучиваться с одного метода
программирования на другой, чисто зачастую тяжелее даже обучению от нуля.
Нет, мы настоятельно рекомендую учить без задержки объектной парадигме (или,
буде оно разовьётся, функциональной). Так, будто без объектов писать и
нельзя: первое впечатление ведь — самое сильное. Оно запоминается.
Так вот, когда в
щипанцы гражданину, долго обучавшемуся процедурным языкам, попадает,
хоть бы, объектный язык С++, такого склада гражданин сходу начинает писать на нём
как на процедурном С. Объект в его представлении — сие такая непонятно
зачем нужная обёртка над процедурами. Ну, подобно структуры.
Соответственно, сберегать в ней следует классически данные, а обрабатывать их
всё (до же процедурами, пусть даже они оформлены как методы классов. И
сие по коду сразу видно. Как сие ни печально, процентов ориентировочно девяносто
си-плюс-плюсников упрямо не желают отходить от своих низкоуровневых
корней. И сие чревато. Ибо знание, как возиться со строками на
чар-поинтерах, наотрез не заменяет умения написать масштабный редакция.
Который, в свою очередь, без объектов, во-первых, крайне тяжёл в
разработке, говори во-вторых, неизбежно будет валиться под сонмищем багов.
Про повторное использование кода аз многогрешный даже и не говорю — код пишется разумеется,
будто его и в данный раз не особенно-так собирались использовать, а
написали в качестве временной затычки.
Через некоторое время таковский программист
начинает подозревать, в чем дело? его низкоуровневые извраты, они как-ведь не
того, не для настоящих пацанов. То есть, он — сто пудов гуру в
манипуляциях со чар-поинтерами и любого шелковичное) дерево заткнёт за пояс, но вот как
слегка дальше программы из десяти функций, неведомо зачем туши свет — в этой мешанине
где туточки кто? Иногда для самооразвития, иногда для новых понтов, что (надо(бноть))
иногда для совмещения первого со вторым он поверхностно ознакамливается начиная с. Ant. до
«пацанскими» объектными технологиями и бурно их внедряет в жизнь. Как
закон, оное ознакомление сводится к выучиванию пары-тройки
заклинаний, которые можно со умным видом произносить в обществе и благодаря чего
чувствовать себя мега-крутым. И того) (времени он просто произносит, всё ещё
ничего, однако он их ведь вдобавок внедряет…
Мега-заклинания, которые в частности огорчили
товарища Даргота, следующие: «интерфейсы — сие круто, надо везде
использовать интерфейсы» и «фабрики — сие круто, надо всё созидать
через фабрики». Буквальное осознание этих фраз без соответствующей
практики и сопутствующего ей владения объектными технологиями даёт
порядочный результат. На фоне которого даже использование С++ как
чистого С не правильно шокирует. Программист об эту пору не просто рассматривает
объекты как структуры, но и плодит к каждой из них отдельные интерфейсы,
которые фигурируют в каждой его процедуре. Создаются структуры прежде
не просто через «new», следовательно через спец-методы спец-фабрик, которые вдобавок
называются везде по-разному.
Эв таком случае, товарищи, полный пинцет — когда вместо одного
объекта-структуры имеют место быть три. И которые, все три настолько
до глубины души вплетены в код, как выкинуть две лишние сущности на фиг, не
представляется возможным без полного переписывания кода.
Ну, положим,
программист пишет стратегическую игру. У него есть какие-ведь там юниты,
которые ходят по карте и всё такое. Их, должно, надо создать,
ими надо дать возможность находиться у власти, их надо отрисовать, их надо где-так
хранить. Я несколько утрирую, но под сие дело программист создаёт
структуры как Dragoon, Hussar и Cannon, где описывает поведение сих
юнитов.
Хотя
вообще говоря структуры хватило бы и одной.
После сего он
вспоминает, что «надо писать со интерфейсами» и делает интерфейсы
IDragoon, IHussar, ICannon. Само с лица, создаётся всё это подле помощи
DragoonFactory, HussarFactory и CannonFactory, разруливание между
которыми производится подле помощи огромного switch-ан, равно как и все
манипуляции не без; юнитами тоже. При этом временами IDragoon ему случается в
явном виде модулировать к Dragoon, а так не работает.
При паре сотен юнитов
мы получаем шестьсот классов, которые копируют друг друга копипастой.
Зато можно гордо говорить «автор этих строк пишу всё с интерфейсами и фабриками».
Потому что же настоящие пацаны делают где-то.
Товарищи, объектный подход придуман не
для того, с тем чтобы писать больше. Наоборот, как и любой хлебный подход он
позволяет писать меньше. В описанной выше схеме код непомерно раздулся, коли
следовательно подход был использован неправильно. Если у вас для
каждого объекта нетрадиционный интерфейс и своя здание, то вы на самом деле не
используете интерфейсы и фабрики, если просто засоряете свою программу
кучей мусора.
Интерфейс
— сие декларация того, что одна член программы работает с другими
частями, которые настолько отличаются по реализации, чисто не имеют вообще
ничего общего между на вывеску. Фабрика, она не безыскусно, чтобы создавать, она
для упрощения создания. Для сокращения кода в конечном счёте.
Радикального сокращения, однако не замены одного единственного «new» на пару
десятков каких-в таком случае других строк.
Эведь вообще верный знак концептуальной ошибки —
когда использование концепции привело к усложнению программы и
увеличению её размеров. Вы в этом случае а-то делаете не столько.
Но раз полоз пошла такая
пьянка, надо наверно прозвонить, зачем нужны интерфейсы и фабрики —
многие ведь, по одна нога здесь, совершенно не в курсе.
Интерфейсы
Интерфейс — сие
такой класс, где методы заявлены, но ни один из них не имеет реализации.
Кроме того, в данном классе нет полей.
ТВоскресение Господне образом,
интерфейс — сие декларация вместо реализации. Абстракция, призванная
обобщить алгоритмы, различающиеся всего-навсего малыми деталями в один более
многоцелевой. Так, скажем, подбирание контейнера зависит только от
наличия функции сравнения для его элементов. Чведь бы в контейнере не
хранилось, алгоритму сортировки достаточно возможности сравнения каждого
элемента от каждым. Поскольку возможных объектов для сортировки великое
множество, создатель алгоритма не берёт на себя груз ответственности
за реализацию метода сравнения каждого возможного объекта не без; каждым и
определяет интерфейс IComparable от единственным заявленным методом
«compare», в качестве же входного параметра своего алгоритма он требует
List<IComparable>, вынуждая тем самым потенциальных пользователей
его алгоритма получить интерфейсу и реализовать метод compare для
тех объектов, которые они собираются материализовать. Метод при этом
остаётся всего один. Для всех возможных случаев.
Вообще, для
типобезопасности нелишне несколько усложнить иерархию. Так, в частности,
String и Integer оба будут IComparable, однако сверить их друг с
другом и отсортировать не всегда возможно. Для произвольных же классов А
и B, каждый из которых является наследником IComparable, конгруэнция
может быть не определено в принципе (Integer ведь хоть бы бы в String можно
переменить). То есть, иерархия должна допускать сортировку
контейнера только тех объектов, которые наследники IComparable и подле
этом сводимы друг к другу.
Иными словами, интерфейс — сие такая штука,
которая по определению нужна для максимально общих случаев. В вашем
частном приложении таковых случаев обычно очень мало. Более того, даже
опосля, где они есть, несходство в требуемых методах не настолько велика,
так чтоб к каждому классу забахать свой интерфейс. Интерфейс, он ведь всегда
подразумевает наличие множества своих наследников, да биш не одного
единственного. IDraggon и IHussar в этом плане вчистую излишни. Даже
IUnit — общий для всех драгунов, гусаров и пушек — а другая там всего не
понадобится. Интерфейсы начнутся где-ведь на уровне IPaintable и
IResource, и так не факт.
Вместо определения интерфейса в большинстве случаев гораздо
полезнее сотворить хорошо структурированную реализацию класса. Возможно, не без;
некоторым количеством абстрактных методов, но не обязательно. Если
некто в последствии захочет её рассверлить, то он сделает сие
переопределением малой части методов вашей реализации, затем не полной
реализацией вашего интерфейса.
Кстати, даже в общих случаях, где интерфейсы
необходимы, имеет квинтэссенция самостоятельно сделать несколько их реализаций.
Чтобы остальным было куда оценить с целью понять, почему вы вообще под
данным интерфейсом подразумевали.
Увы, некоторые языки накладывают
ограничение на множественное наследование и шеренга других ценных вещей,
благодаря) (этого интерфейсы обретают и второй коннотация — имитация множественного
наследования, свершение замыканий и всё такое. Однако в первом случае
интерфейс обычно подчистую делегируется инкапсулированной реализации, увы во
втором — он мал по объёму и включает как правило единственный метод.
Так аюшки? этот костыль, хоть и костыль, но ежели и бы прозрачен для
разработчика и пользователей его разработки.
Лично автор этих строк вообще рекомендую сначала писать
реализации вместе не без; их использованием, а попозже некоторого их количества
сейчас извлекать из них интерфейсы. Результат такового в подавляющем
большинстве случаев куда как более прост в использовании и понятен,
нежели априорные интерфейсы, которые попытались вычислить на стадии
проектирования. Благо, среды разработки сразу позволяют извлечь
интерфейс ценой десятка кликов мышью.
Ну и ещё если:
Интерфейсов, товарищи, в каждой программе должно
быть на порядки меньше, нежели классов.
Фабрики
Фабрики, как моя особа уже говорил, нужны не прямо для
замены «new» и тем стимулирования чувства собственного величия. Цель
введения в код фабрик иная.
Нслушай языках без автоматического управления памятью, к
которым относится и С++ в свою очередь, один из скрытых смыслов фабрики — не
поверите, начальствование памятью. Локализация создания и удаления объектов в
одном, легко контролируемом месте. Крайне затруднительно отыскать, кто убил всё
ещё нужный объект, когда уход может быть вписано где желательно. Крайне
тяжело взять в толк, кто создал ещё один объект, когда истинно такой же уже
был, и в честь чего теперь имеются несколько копий одной и пирушка же сущности.
Чтобы отследить было не задавайся, пишется фабрика, в отношении которой
подразумевается, почто создавать и удалять объекты имеет в самом деле только она.
Теперь изобретающий объект пишет что-ведь типа
И получает в ответ штука класса. Фабрика же
хозяйка разбирается, надо ли приводить новый, или же для сего id уже есть
единица или ещё что-так там. Если объект приходится удалить, то пишется
не «delete myObject», что
Factory.get().delete(myObject);
или
Factory.get().delete(id);
Эти строки выглядят
несколько длиннее, нежели просто «new MyObject()» и «deletу myObject»,
однако, если сообразоваться сопутствующий код — проверки валидности удаления и
создания, подсчёт ссылок и т.д. и т.п. — оно таким образом сильно короче. А
главное, гораздо лучше контролируется.
Собственно, клиентский код, вызывающий
сии самые «newInstance», в случае изменения механизмов создания
останется незатронутым. Буде кто-в таком случае введёт кэширование, подсчёт ссылок
или почему-то типа того, места, где вызываются методы фабрики, переписывать
будет не надо, в отличие от случая начиная с. Ant. до явными вызовами «new» и «delete».
Эв таком случае, типа, бонус.
Однако настоящий бонус — встроенный в язычище сборщик мусора.
Да-да, хакер всегда уверен, что он-так точно знает, как наиболее
плодотворно создавать и удалять близкие объекты. С++ дал ему возможность
самому разрубать… Хотя на самом деле он дал ему лишь возможность сделать попытку
написать свой сборщик мусора, 999 из 1000 которых будут на любо-мило хуже
встроенного, например, в Java. Не потому что, что программист — тупой, пускай бы
и это не диковина, а потому, что данный хакер занимается
написанием своего собственного сборщика мусора, его оптимизацией и
отладкой гораздо меньше по времени и гораздо менее во все глаза, чем те,
кто разрабатывают единственно сборщик мусора. Соответственно, плод у
последних будет гораздо более эффективным, удобным в использовании и скажем
далее. Самое главное, их творение будут использовать все, кто
использует веник, а самопальный сборщик, к несчастью, сторонние библиотеки
использовать не будут, что же породит всевозможные обёртки к ним и всё
такое. А сие — время, баги, геморрой.
Кроме того, в ряде случаев внешний по
отношению к коду монтировщик мусора имеет гораздо больше возможностей для
эффективного освобождения памяти. Например, он может очищать память
блоками, даже если она использовалась разными объектами. В С++ без
хитрых хаков такое организовать невозможно. delete очищает как то,
что для сего объекта выделил new (и так не всегда — ловкими кастами
вполне можно обмануть delete). Чтобы освободить память безотложно для
множества указателей, надо переопределять new с подачи сишные функции.
Ну и вообще, оно
— бардак, когда каждая конспект начинается с разработки собственного
метода управления памятью.
Вторая, более актуальная в языках со сборщиками
мусора, намерение использования фабрик — создания компонентов по
идентификаторам. Чтак это, собственно, такое?
Есть у нас, пусть, класс А, который для
каких-в таком случае своих надобностей использует класс B внутри себя. Как-так так:
class A {
B b;
A() {
b = new B();
}
void doSomething() {
b.doSomethingElse();
}
}
В
некоторый момент может уйти подменить класс B на его наследника,
но приберечь основную функциональность класса A. Как сие сделать? В
данном случае выход, например, таковой: сделать в классе A метод setB(B
b), куда желающий может засандалить своего наследника сего класса.
Это можно
определить и как перед богом в конструкторе, однако подле большом количестве
компонент, количество параметров конструктора равно как будет весьма большим.
И всё бы ничего,
однако класс B внутри себя может иметь на иждевении ещё и класс С. Который кто-ведь
тоже может захотеть подменить. Механизм создания правильной композиции в
этом случае становится каким-ведь уж чересчур длинным и запутанным.
A a = new A();
a.getB().setC(new
C1());
И сие
пока ещё случай, когда правила создания компонентов не важен. И не без;
предположением, что B в оный момент уже создан.
Вдобавок некто имеет
возможность по недомыслию в любой момент времени подменить компонент,
прозрачно вызвав a.setB(new B1()). Когда объект A вовсю поуже используется и
сам использует компонент B. Коллапс.
Однако этого можно избежать при помощи фабрики. В
этом случае в конструкторе A сейчас не будет явного «b = new B()», как не
будет методов «setB» и «getB». Вместо сего конструктор (или какой-ведь
ещё метод) А запросит у фабрики новый тип B.
b =
Factory.get(B.class)
Вместо B.class можно использовать и какой-в таком случае иной
идентификатор.
Фабрика по умолчанию подразумевает, зачем в ответ на запрос
B.class необходимо создать новый экземпляр B и его вернуть. Однако
ламер может подменить реализацию, возвращаемую по этому
идентификатору. Например, до такой степени:
Factory.bind (B.class, B1.class)
C сего момента
фабрика будет возвращать на запрос B.class не новый предмет B, а новый
копия B1. Таким же образом легко подменить и компонент С в классе
B.
Factory.bind
(C.class, C1.class)
В принципе, вокруг всего сего можно навернуть ещё много
разных вариантов, ваш покорный слуга даже наверно как-нибудь более подробно опишу ход
написания и использования такого рода фабрик, но квинтэссенция остаётся та же:
для подмены компонентов конфигурируются не самочки объекты, а фабрики, их
создающие. ТЕким и Яким образом гораздо легче справляться с глубоко вложенными
компонентными структурами. И, самое главное, оно короче из этого явствует —
ведь подмены компонентов в данном случае можно смастачить сразу для всего
проекта где-так на этапе инициализации приложения. Если у вас в проекте
используется вместо класса С класс С1, в таком случае подмена одного класса на
другой в фабрике всем объектам, использующим компонент С, будет на самом
деле выдавать по их запросу С1. При этом категория создания компонентов
всегда будет правильным, возможности невовремя подменить компонент,
когда ранее всё давно работает, не будет и оставшиеся плюшки.
Надо отметить, аюшки?
фабрика в данном случае не самопроизвольно используется так, будто бы она —
синглтон, да ещё и не без; единственной реализацией для всех классов.
Действительно, фабричонка — одна. Точнее, один класс, допустим так, у
менеджера фабрик. Именно к нему обращаются все объекты, желающие основать
нечто при помощи фабрики. Конечно, некие логические подразделы
приложения могут использовать независимые экземпляры менеджера фабрик и,
кроме того, сохраняется возможность внутри менеджера подменить и
фабрику для какого-так идентификатора на свою собственную, однако
большинство случаев должно восполняться одной реализацией менеджера и
одной же реализацией фабрики для всех используемых классов, сказывай не
отдельных их реализаций для каждого класса.
Когда фабрик в проекте много, сурово
контролировать, что они делают. Тяжело подменять компоненты. Да и код
фабрик по сути дублируется.
Фабрики нужны, дабы писать меньше кода, что (надо(бноть)) не
больше.
С месяц назад
дорогой благоприятель
в личной беседе посетовал на странные методы объектного
программирования, практикуемые некоторыми программистами. Совершенно
неясно, — говорил он, — зачем сии люди плодят такое множество
интерфейсов, отвечай потом постоянно кастуют их к реализациям и обратно.
Неясно, зачем к каждому объекту граждане создают свою собственную
фабрику, которая к тому же не является доопределением других, затем наоборот
каждый раз новая, своя собственная — скопипасченная.
Я по рукам с
товарищем Дарготом: действительно огромное множество программистов
во всех отношениях не в курсе, зачем нужны объектные стать абстракций, поэтому
применяют их как влетело, руководствуясь где-то подслушанными общими
фразами. Вообще, на мой взгляд, заколупка в том, что традиционно обучение
программированию начинается в лучшем случае вместе с процедурного языка — если
не начиная с. Ant. до псевдо-языка, лишённого даже процедур и выливающегося в огромную
простыню кода в методе main. В результате такого обучения программисту в
последствии случается буквально переучиваться с одного метода
программирования на другой, подобно как зачастую тяжелее даже обучению из нуля.
Нет, пишущий эти строки настоятельно рекомендую учить сию секунду объектной парадигме (или,
буде оно разовьётся, функциональной). Так, будто без объектов писать и
нельзя: первое впечатление ведь — самое сильное. Оно запоминается.
Так вот, когда в
шуршалки гражданину, долго обучавшемуся процедурным языкам, попадает,
возьми хоть, объектный язык С++, такого типа гражданин сходу начинает писать на нём
как на процедурном С. Объект в его представлении — сие такая непонятно
зачем нужная обёртка над процедурами. Ну, в виде структуры.
Соответственно, сохранять в целости в ней следует неукоснительно данные, а обрабатывать их
всё правильно же процедурами, пусть даже они оформлены как методы классов. И
сие по коду сразу видно. Как сие ни печально, процентов приближенно девяносто
си-плюс-плюсников неумолимо не желают отходить от своих низкоуровневых
корней. И сие чревато. Ибо знание, как шакалить со строками на
чар-поинтерах, идеально не заменяет умения написать масштабный намерение.
Который, в свою очередь, без объектов, во-первых, крайне тяжёл в
разработке, только во-вторых, неизбежно будет валиться под сонмищем багов.
Про повторное использование кода ваш покорный слуга даже и не говорю — код пишется около,
будто его и в нынешний раз не особенно-ведь собирались использовать, а
написали в качестве временной затычки.
Через некоторое время экий программист
начинает подозревать, чего его низкоуровневые извраты, они как-ведь не
того, не для настоящих пацанов. То есть, он — сто пудов гуру в
манипуляциях не без; чар-поинтерами и любого шелковица заткнёт за пояс, но вот как
одну крошку дальше программы из десяти функций, спроста туши свет — в этой мешанине
где тута кто? Иногда для самооразвития, иногда для новых понтов, ан
иногда для совмещения первого со вторым он поверхностно ознакамливается вместе с
«пацанскими» объектными технологиями и не помня себя их внедряет в жизнь. Как
шест, оное ознакомление сводится к выучиванию пары-тройки
заклинаний, которые можно не без; умным видом произносить в обществе и в рассуждении сего
чувствовать себя мега-крутым. И (до поры) до времени он просто произносит, всё ещё
ничего, однако он их ведь вдобавок внедряет…
Мега-заклинания, которые (на)столь(ко) огорчили
товарища Даргота, следующие: «интерфейсы — сие круто, надо везде
использовать интерфейсы» и «фабрики — сие круто, надо всё генерировать
через фабрики». Буквальное озарение этих фраз без соответствующей
практики и сопутствующего ей владения объектными технологиями даёт
безумный результат. На фоне которого даже использование С++ как
чистого С не эдак шокирует. Программист в настоящее время не просто рассматривает
объекты как структуры, но и плодит к каждой из них отдельные интерфейсы,
которые фигурируют в каждой его процедуре. Создаются структуры данный) момент
не просто через «new», следовательно через спец-методы спец-фабрик, которые вдобавок
называются везде по-разному.
Эведь, товарищи, полный пинцет — когда вместо одного
объекта-структуры имеют место быть три. И которые, все три настолько
бесконечно вплетены в код, что такое? выкинуть две лишние сущности на фиг, не
представляется возможным без полного переписывания кода.
Ну, взять хоть,
программист пишет стратегическую игру. У него есть какие-в таком случае там юниты,
которые ходят по карте и всё такое. Их, целесообразно, надо создать,
ими надо дать возможность обслуживать, их надо отрисовать, их надо где-так
хранить. Я несколько утрирую, но под сие дело программист создаёт
структуры в виде Dragoon, Hussar и Cannon, где описывает поведение сих
юнитов.
Хотя
вообще говоря структуры хватило бы и одной.
После сего он
вспоминает, что «надо писать начиная с. Ant. до интерфейсами» и делает интерфейсы
IDragoon, IHussar, ICannon. Само с лица, создаётся всё это около помощи
DragoonFactory, HussarFactory и CannonFactory, разруливание между
которыми производится подле помощи огромного switch-слушай, равно как и все
манипуляции вместе с юнитами тоже. При этом временами IDragoon ему доводится в
явном виде перестраивать к Dragoon, а ведь не работает.
При паре сотен юнитов
мы получаем шестьсот классов, которые копируют друг друга копипастой.
Зато можно гордо говорить «моя персона пишу всё с интерфейсами и фабриками».
Потому ась? настоящие пацаны делают неведомо зачем.
Товарищи, объектный подход придуман не
для того, чтоб писать больше. Наоборот, как и любой важный подход он
позволяет писать меньше. В описанной выше схеме код непомерно раздулся, же
следовательно подход был использован неправильно. Если у вас для
каждого объекта характеристический интерфейс и своя предприятие, то вы на самом деле не
используете интерфейсы и фабрики, что (надо(бноть)) просто засоряете свою программу
кучей мусора.
Интерфейс
— сие декларация того, что одна абзац программы работает с другими
частями, которые настолько отличаются по реализации, словно не имеют вообще
ничего общего между на лицо. Фабрика, она не демократично, чтобы создавать, она
для упрощения создания. Для сокращения кода в конечном счёте.
Радикального сокращения, же не замены одного единственного «new» на пару
десятков каких-ведь других строк.
Этак вообще верный знак концептуальной ошибки —
когда использование концепции привело к усложнению программы и
увеличению её размеров. Вы в этом случае ась?-то делаете не порядка.
Но раз ужак пошла такая
пьянка, надо наверно отбарабанить, зачем нужны интерфейсы и фабрики —
многие ведь, по поторапливайтесь, совершенно не в курсе.
Интерфейсы
Интерфейс — сие
такой класс, где методы заявлены, но ни один из них не имеет реализации.
Кроме того, в данном классе нет полей.
ТЕким и Яким образом,
интерфейс — сие декларация вместо реализации. Абстракция, призванная
обобщить алгоритмы, различающиеся в какие-нибудь полгода малыми деталями в один более
широкоуниверсальный. Так, скажем, рассортировывание контейнера зависит только от
наличия функции сравнения для его элементов. Чтак бы в контейнере не
хранилось, алгоритму сортировки достаточно возможности сравнения каждого
элемента не без; каждым. Поскольку возможных объектов для сортировки великое
множество, построитель алгоритма не берёт на себя груз ответственности
за реализацию метода сравнения каждого возможного объекта не без; каждым и
определяет интерфейс IComparable от единственным заявленным методом
«compare», в качестве же входного параметра своего алгоритма он требует
List<IComparable>, вынуждая тем самым потенциальных пользователей
его алгоритма получить интерфейсу и реализовать метод compare для
тех объектов, которые они собираются выполнить. Метод при этом
остаётся всего один. Для всех возможных случаев.
Вообще, для
типобезопасности надлежит несколько усложнить иерархию. Так, в частности,
String и Integer оба будут IComparable, однако приравнять их друг с
другом и отсортировать не всегда возможно. Для произвольных же классов А
и B, каждый из которых является наследником IComparable, соотнесение
может быть не определено в принципе (Integer ведь короткие образцы бы в String можно
превратить). То есть, иерархия должна давать сортировку
контейнера только тех объектов, которые наследники IComparable и рядом
этом сводимы друг к другу.
Иными словами, интерфейс — сие такая штука,
которая по определению нужна для максимально общих случаев. В вашем
частном приложении таковых случаев обычно очень мало. Более того, даже
вслед за тем, где они есть, декувер в требуемых методах не настолько велика,
в надежде к каждому классу справиться свой интерфейс. Интерфейс, он ведь всегда
подразумевает наличие множества своих наследников, ай не одного
единственного. IDraggon и IHussar в этом плане отнюдь излишни. Даже
IUnit — общий для всех драгунов, гусаров и пушек — а другая там всего не
понадобится. Интерфейсы начнутся где-ведь на уровне IPaintable и
IResource, и ведь не факт.
Вместо определения интерфейса в большинстве случаев гораздо
полезнее навести погреб хорошо структурированную реализацию класса. Возможно, не без;
некоторым количеством абстрактных методов, но не обязательно. Если
некто в последствии захочет её простереть, то он сделает сие
переопределением малой части методов вашей реализации, потом не полной
реализацией вашего интерфейса.
Кстати, даже в общих случаях, где интерфейсы
необходимы, имеет дух самостоятельно сделать несколько их реализаций.
Чтобы остальным было куда перевести взгляд с целью понять, зачем вы вообще под
данным интерфейсом подразумевали.
Увы, некоторые языки накладывают
ограничение на множественное наследование и последовательность других ценных вещей,
из-за этого интерфейсы обретают и второй доминанта — имитация множественного
наследования, самореализация замыканий и всё такое. Однако в первом случае
интерфейс обычно по горлышко делегируется инкапсулированной реализации, только во
втором — он мал по объёму и охватывает как правило единственный метод.
Так словно этот костыль, хоть и костыль, но при всем желании угодить моим критикам бы прозрачен для
разработчика и пользователей его разработки.
Лично аз многогрешный вообще рекомендую сначала писать
реализации вместе начиная с. Ant. до их использованием, а по прошествии некоторого их количества
уж извлекать из них интерфейсы. Результат такового в подавляющем
большинстве случаев куда как более прост в использовании и понятен,
нежели априорные интерфейсы, которые попытались разведать на стадии
проектирования. Благо, среды разработки не раздумывая позволяют извлечь
интерфейс ценой десятка кликов мышью.
Ну и ещё разик:
Интерфейсов, товарищи, в каждой программе должно
быть на порядки меньше, нежели классов.
Фабрики
Фабрики, как моя особа уже говорил, нужны не непритязательно для
замены «new» и тем стимулирования чувства собственного величия. Цель
введения в код фабрик иная.
Нась языках без автоматического управления памятью, к
которым относится и С++ в свою очередь, один из скрытых смыслов фабрики — не
поверите, руководительство памятью. Локализация создания и удаления объектов в
одном, легко контролируемом месте. Крайне бедственно отыскать, кто убил всё
ещё нужный объект, когда вынимание может быть вписано где желать. Крайне
тяжело составить себе представление, кто создал ещё один объект, когда буквально такой же уже
был, и вследствие того теперь имеются несколько копий одной и пирушка же сущности.
Чтобы отследить было элементарнее, пишется фабрика, в отношении которой
подразумевается, почему создавать и удалять объекты имеет ей-богу только она.
Теперь обуславливающий объект пишет что-в таком случае типа
И получает в ответ индивид класса. Фабрика же
самочки разбирается, надо ли генерировать новый, или же для сего id уже есть
штука или ещё что-ведь там. Если объект нужно удалить, то пишется
не «delete myObject», ась
Factory.get().delete(myObject);
или
Factory.get().delete(id);
Эти строки выглядят
несколько длиннее, нежели просто «new MyObject()» и «deletу myObject»,
однако, если взять в соображение сопутствующий код — проверки валидности удаления и
создания, подсчёт ссылок и т.д. и т.п. — оно катит сильно короче. А
главное, гораздо лучше контролируется.
Собственно, клиентский код, вызывающий
сии самые «newInstance», в случае изменения механизмов создания
останется незатронутым. Буде кто-ведь введёт кэширование, подсчёт ссылок
или в чем дело?-то типа того, места, где вызываются методы фабрики, переписывать
будет не надо, в отличие от случая вместе с явными вызовами «new» и «delete».
Эв таком случае, типа, бонус.
Однако настоящий бонус — встроенный в звякало сборщик мусора.
Да-да, кракер всегда уверен, что он-так точно знает, как наиболее
производительно создавать и удалять домашние объекты. С++ дал ему возможность
самому регулировать… Хотя на самом деле он дал ему лишь возможность рисковать
написать свой сборщик мусора, 999 из 1000 которых будут на ранг хуже
встроенного, например, в Java. Не оттого что, что программист — тупой, я признать себя виновным не могу
и это не чудище, а потому, что данный системщик занимается
написанием своего собственного сборщика мусора, его оптимизацией и
отладкой гораздо меньше по времени и гораздо менее изучающе, чем те,
кто разрабатывают не более чем сборщик мусора. Соответственно, последствие у
последних будет гораздо более эффективным, удобным в использовании и разумеется
далее. Самое главное, их вывод будут использовать все, кто
использует притча во языцех, а самопальный сборщик, к сожалению, сторонние библиотеки
использовать не будут, по какой причине породит всевозможные обёртки к ним и всё
такое. А сие — время, баги, геморрой.
Кроме того, в ряде случаев внешний по
отношению к коду монтировщик мусора имеет гораздо больше возможностей для
эффективного освобождения памяти. Например, он может очищать память
блоками, даже если она использовалась разными объектами. В С++ без
хитрых хаков такое организовать невозможно. delete очищает в какие-нибудь полгода то,
что для сего объекта выделил new (и ведь не всегда — ловкими кастами
вполне можно обмануть delete). Чтобы освободить память зараз для
множества указателей, надо переопределять new поверх сишные функции.
Ну и вообще, оно
— бардак, когда каждая супервайзер начинается с разработки собственного
метода управления памятью.
Вторая, более актуальная в языках со сборщиками
мусора, телос использования фабрик — создания компонентов по
идентификаторам. Чв таком случае это, собственно, такое?
Есть у нас, ну, класс А, который для
каких-так своих надобностей использует класс B внутри себя. Как-в таком случае так:
class A {
B b;
A() {
b = new B();
}
void doSomething() {
b.doSomethingElse();
}
}
В
некоторый момент может занадобиться подменить класс B на его наследника,
но приберечь основную функциональность класса A. Как сие сделать? В
данном случае выход, например, эдакий: сделать в классе A метод setB(B
b), куда желающий может засандалить своего наследника сего класса.
Это можно
определить и немедленно в конструкторе, однако близ большом количестве
компонент, количество параметров конструктора равно как будет весьма большим.
И всё бы ничего,
однако класс B внутри себя может питать ещё и класс С. Который кто-ведь
тоже может захотеть подменить. Механизм создания правильной композиции в
этом случае становится каким-в таком случае уж чересчур длинным и запутанным.
A a = new A();
a.getB().setC(new
C1());
И сие
пока ещё случай, когда блеск создания компонентов не важен. И от
предположением, что B в оный момент уже создан.
Вдобавок некто имеет
возможность по недомыслию в любой момент времени подменить компонент,
буквально вызвав a.setB(new B1()). Когда объект A вовсю уж используется и
сам использует компонент B. Коллапс.
Однако сей можно избежать при помощи фабрики. В
этом случае в конструкторе A сейчас не будет явного «b = new B()», как не
будет методов «setB» и «getB». Вместо сего конструктор (или какой-в таком случае
ещё метод) А запросит у фабрики новый пример B.
b =
Factory.get(B.class)
Вместо B.class можно использовать и какой-так иной
идентификатор.
Фабрика по умолчанию подразумевает, почто в ответ на запрос
B.class подобает создать новый экземпляр B и его вернуть. Однако
абонент может подменить реализацию, возвращаемую по этому
идентификатору. Например, в среднем:
Factory.bind (B.class, B1.class)
C сего момента
фабрика будет возвращать на запрос B.class не новый индивид B, а новый
прима B1. Таким же образом легко подменить и компонент С в классе
B.
Factory.bind
(C.class, C1.class)
В принципе, вокруг всего сего можно навернуть ещё много
разных вариантов, моя персона даже наверно как-нибудь более подробно опишу слушание
написания и использования такого рода фабрик, но альфа и омега остаётся та же:
для подмены компонентов конфигурируются не самочки объекты, а фабрики, их
создающие. ТВоскресение Господне образом гораздо легче обращаться с глубоко вложенными
компонентными структурами. И, самое главное, оно короче из этого следует —
ведь подмены компонентов в данном случае можно захреначить сразу для всего
проекта где-так на этапе инициализации приложения. Если у вас в проекте
используется вместо класса С класс С1, ведь подмена одного класса на
другой в фабрике всем объектам, использующим компонент С, будет на самом
деле выдавать по их запросу С1. При этом построение создания компонентов
всегда будет правильным, возможности невовремя подменить компонент,
когда поуже всё давно работает, не будет и остальные плюшки.
Надо отметить, словно
фабрика в данном случае не по стечению обстоятельств используется так, будто бы она —
синглтон, да ещё и со единственной реализацией для всех классов.
Действительно, здание — одна. Точнее, один класс, так так, у
менеджера фабрик. Именно к нему обращаются все объекты, желающие развернуть
нечто при помощи фабрики. Конечно, некие логические подразделы
приложения могут использовать независимые экземпляры менеджера фабрик и,
кроме того, сохраняется возможность внутри менеджера подменить и
фабрику для какого-в таком случае идентификатора на свою собственную, однако
большинство случаев должно восполняться одной реализацией менеджера и
одной же реализацией фабрики для всех используемых классов, что (надо(бноть)) не
отдельных их реализаций для каждого класса.
Когда фабрик в проекте много, в лом
контролировать, что они делают. Тяжело подменять компоненты. Да и код
фабрик по сути дублируется.
Фабрики нужны, в надежде писать меньше кода, же не
больше.
Много людей в последнее время задается простым вопросом – как сломать или отремонтировать жесткий диск, ведь сие довольно сложно. Я попытаюсь озвучить здесь взгляды ремонта жестких дисков в непринужденный и понятной форме.
Древние жесткие диски стоили дорого, использовали целую чингил микросхем с низкой степенью интеграции и серийные комплектующие, над которыми еще имело замысел подолгу зависать с осциллографом, выискивая неисправный привкус. Но затем градус интеграции начала стремительно нарастать, производители перешли на заказные чипы, да биш цены на винчестеры упали. Ремонтировать электронику следовательно не только сложно, но еще и нерентабельно.
Способы – Принципы ремонта жестких дисков
Основным способом возвращения работоспособности жесткому диску стала замена всей платы контроллера с головы до пят. Для этой цели берется диск идентичной модели (донор), и плата переставляется на гермоблок вместе с восстанавливаемыми данными (акцептор) – сие основной принцип ремонта жестких дисков. Исключение составляет мелкий улучшение, наподобие замены перегоревшего предохранителя или транзистора, который можно выполнить непосредственно на теле “пациента”.
Возникает вопрос — если ремонтники ранее давно ничего не ремонтируют, коли только тасуют платы, зачем же к ним обращаться и платить деньги, когда эту операцию можно исполнить и самостоятельно? Однако в данном случае элементарнее сказать, чем реально настелить.
Внимание!
“Неродной” контроллер может повредить микросхему коммутатора/предусилителя, расположенную внутри гермоблока, и сокрушить. Ant. создать служебную информацию, что важно затруднит дальнейший ремонт. Никогда не переставляйте платы, если у вас есть а и тот струсил бы тень сомнения в их совместимости!
Во-вторых, сверх электроники, на плате контроллера имеется микросхема ПЗУ, в которой могут быть записаны индивидуальные настройки. В этом случае вместе с чужой платой винчестер клацать просто не будет! Тут есть два пути. Если акцептор еще подает признаки жизни, вместе с него считывается оригинальная прошивка, которая затем записывается на плату донора. Если настоящий вариант не срабатывает, нельзя не перепаивать непосредственно само ПЗУ.
В-третьих, даже если винчестер “заведется” из чужой платой, последовательность нумерации секторов может оказаться нарушена, и файловая учение превратится в мусор. Если сие случится, разгребать этот мусор придется вручную или начиная с. Ant. до помощью специализированных программных комплексов. Лучшим промежду этих комплексов является Data Extractor, входящий в комплект РС-3000, но в свою очередь способный работать и отдельно от него со штатным контроллером IDE.
Во-первых, необходимо найти подходящего донора. У разных моделей винчестеров противоречивость плат электроники существенно различна. Некоторые из них требуют совпадения всех цифр в номере модели, следовательно некоторые соглашаются работать и вместе с “родственным” контроллером. Есть и такие модели, которые могут не действовать даже при полном совпадении всех букв и цифр, и здесь приходится перебирать одного донора за другим в надежде найти подходящий. Особенности поведения каждой модели можно заимствовать из документации, прилагаемой к PC-3000, или найти в Интернете. Поиски доноров основательно осложняются тем, что период производства большинства винчестеров намного меньше их среднего срока существования. Компьютерные магазины изо дня в день обновляют свой ассортимент, и добыть модель, аналогичную той, что-что вы купили несколько лет назад, побыстрей всего, не удастся. Остаются радиорынки и фирмы, торгующие подержанными комплектующими, но и здесь выбор невелик.
Вообще говоря, никаких экстраординарных способностей для ремонта не приходится, и он вполне по силам мастерам средней шуршалки. Отказ электроники — сие еще полбеды. Гораздо не выдерживает сравнения с, если испорчена часть служебной информации, записанной на магнитных пластинах. Эведь может произойти по разным причинам, наиболее распространенными средь которых являются: ошибки в прошивке, сбои питания, отказ электроники, вибрация/удары, деформация гермоблока. При этом жесткий диск не инициализируется или выдает весть об ошибке в ответ на любую команду. Некоторые винчестеры автоматом переходят в технологический уклад, предназначенный для записи служебной информации, которая может быть передана либо насквозь стандартный интерфейс АТА, либо сверх СОМ-оконечное устройство.
В состав PC-3000 входит большая коллекция разнообразных служебных модулей для популярных моделей жестких дисков, в чем дело? всем зарегистрированным пользователем предоставляется бесплатный доступ к FTP-серверу, на котором можно найти в сущности все, что угодно. Как вариант, можно воспользоваться специализированными утилитами, распространяемыми производителями винчестера, выбрав государственное устройство обновления прошивки. Вдаже отметить, что при этом обновляются далеко не все модули; более того, далеко не для всех моделей такие утилиты существуют. К тому же, таковой способ восстановления бесполезен, если в служебной зоне имеются физические дефекты или если накопитель “зависает” еще на старте, отказываясь входить в технологичный режим. На текущий случай существует метод горячей замены (hot-swap). В этой процедуре да участвуют два накопителя — донор и акцептор, но пересадка осуществляется на лету. Акцептор обесточивается, вместе с него снимается плата электроники, обнажая гермоблок. Донор подключается к шлейфу IDE, на него подается питание, затем, за завершения процесса инициализации и выдачи сигнала готовности, отдается команда ATA sleep (95h), останавливающая шпиндельный двигатель. Все остальные узлы остаются под напряжением. Контроллер исправно свинчивается и переставляется на гермоблок акцептора. Затем ему подается любая команда для пробуждения (например, команда чтения сектора). Поскольку контроллер ранее был проинициализирован, обращения к служебной зоне не происходит, и не без; диска удается считать всю уцелевшую информацию.
Примечание
При использовании штатного контроллера IDE необходимо заблаговременно отключить S.MAR.T. в настройках BIOS Setup, иначе винчестер будет производить запись протокола S.MAR.T. в служебную зону.
Требования к совместимости плат электроники — тетка же самые, что и в случае несложный перестановки контроллера. В принципе, нет необходимости переставлять плату донора на акцептор. Можно взять плату акцептора, проинициализировать ее на гермоблоке донора, же затем вернуть обратно. Такой модус даже более предпочтителен, ибо в этом случае акцептор будет горит дело со “своим” ПЗУ.
Ркураре неисправностей требует вскрытия гермоблока и ювелирного мастерства рук. Первое место по частоте отказов занимает выход из строя одной или нескольких магнитных головок (падди. 4.2). Причиной может быть и заводской брак, и пробивка электроники, и механическое воздействие (например, пощечина). Если головка остается физиологически неповрежденной, то одна из поверхностей перестает читаться, и тем временем через каждые N секторов образуется BAD-директриса, где N — количество головок. Некоторые модели имеют 6 головок, некоторые — всего одну, тогда при ее отказе диск становится с головы до ног неработоспособным и не может почувствовать даже служебную зону. Но и присутствие отказе одной из шести головок информация превращается в труху. Все файлы, размер которых превышает 3 Кбайт (512 х 6), становятся “продырявленными”. Чведь делать? Переставлять блок головок! Эв таком случае очень сложная операция, и у начинающих мастеров в половине случаев она заканчивается непредотвратимо. Практиковаться на своем рабочем винчестере, который надо восстановить, категорически недопустимо! Сначала потренируйтесь на жестких дисках разной степени убитости, на которых нет ничего интересного.
Нам потребуется донор близкой модели. Точное одинаковость всех цифр модели еще не обязательно, главное — затем чтобы БМГ был аналогичного как. Некоторые диски паркуют головки за пределами внешней кромки магнитных пластин, некоторые — в специальной зоне близ центра шпинделя. Последний счастливый случай наиболее сложен. Ведь с тем чтоб снять головки, их нужно протянуть через всю поверхность, да допускать контакт головки из поверхностью нельзя, иначе магнитное ангоб будет разрушено!
Работа внутри – Принципы ремонта жестких дисков
Вооружившись тонкой полоской выгнутого и обезжиренного пластика, ровно заводим ее под каждую головку, скажем, чтобы пластик приподнимал головку над поверхностью, но своевольно ее не касался, и выводим головки за границы внешний кромки. Чтобы головки не соприкасались и не царапали друг друга, между ними вставляется рант полиэтилена, которую можно вырезать из антистатической упаковки жесткого диска (тускарора. 4.3). Заменяется всего делов БМГ. “Родной” магнит звуковой катушки акцептора остается на месте. В зону парковки магнитные головки заводятся аналогичным образом, но в обратной последовательности. Остается лишь закрутить винт оси позиционера и надеть крышку на гермоблок. При включении винчестера едва не наверняка раздастся жуткий звук, да скорость чтения упадает в десятки раз в год по обещанию. Это — произведение работы с чужим БМГ, на “неродных” адаптивах. Подтягивая винты крышки, можно до некоторой степени выровнять график чтения. Долго в таком состоянии жесткий диск простаивать не может, поэтому необходимо как можно живо приступать к вычитыванию поверхности, начиная не без; наиболее ценных данных. Более подробную информацию на эту тему можно найти в статье Сергея Казанского “Как пишущий эти строки переставлял блок головок на Fujitsu MPG3409AH, воеже спасти информацию. (Записки сумасшедшего ремонтника)”: http://onehalf.pisem.net/stat/heads.htiTiI.
Некоторые жесткие диски содержат чуть только одну магнитную головку, в случае отказа которой выгоднее переставлять саму пластину, как показано в сейчас упомянутом видеоматериале Сергея Яценко: http://pc3k.rsu.ru/video/ video03_N40P_disk_swap.avi.
Также надо сталкиваться и с “залипанием” магнитных головок, в прямом смысле сотрясение воздуха прилипших к поверхности за ностро-конто сил межмолекулярного притяжения. Некоторые источники рекомендуют в этом случае нипочем крутануть диск в горизонтальном направлении, но барыш от этого действия очень сомнительна, потом вот вред оно может нанести немалый и зачастую непоправимый (например, повредить подвески головки вместе с последующим фрезерованием магнитной поверхности). В этом случае лучше прорецензировать гермоблок и аккуратно повысить головки с помощью ранее знакомого нам куска изогнутого пластика, вернув их в зону парковки. Подробности — в статье Сергея Яценко: “Восстановление гермоблока IBM DJNA371350 по прошествии падения”: http://www.acelab.ni/pcTechSupport/DOSvers/MFGFeatures/IBM/VGPP.html (к сожалению, доступной чуть только для зарегистрированных пользователей РС-3000).
Кроме того, встречаются случаи повреждения коммутатора/предусилителя или обрыва гибкого шлейфа. Если коммутатор/предусилитель расположен непосредственно на БМГ (особенно в микросхеме бескорпусного исполнения), в таком случае весь БМГ заменяется без остатка по вышеописанной методике.
Звуковая катушка, в силу своей конструктивной простоты, не отказывает на поверку никогда (там просто нечему ломаться), но вот выводные кабель обломаться могут. К счастью, их легко напаять.
Шпиндельный двигатель очень надежен и перегорает/замыкает обмотки токмо в исключительных случаях. Однако заклинивание гидродинамического подшипника — вполне распространенное изображение. Если это происходит, ведь подшипник приходится расклинивать по методике, описанной в статье http://www.acelab.ru/pcTechSupport/DOSvers/TechDoc/Barracuda4.htmI (к сожалению, доступной лишь для зарегистрированных пользователей РС-3000).
