Журнал PC Magazine/Russian Edition 01/2009
Журнал PC Magazine/Russian Edition 01/2009 читать книгу онлайн
Главный материал январского номера журнала, обзор «Ноутбуки: "от мала до велика "», представляет собой результаты сводного тестирования шести моделей бизнес-ноутбуков и четырех нетбуков, проведенного в лаборатории PC Magazine/RE. Материал адресован широкому кругу пользователей.
«Прошедший 2008 г., безусловно, стал годом нетбуков. Эти сверхкомпактные, не перегруженные функциональностью и доступные по цене компьютеры завоевали сердца и кошельки потребителей по всему миру - начиная с самого первого ASUS Eee PC, сыгравшего роль буревестника новой мобильной революции.»
Также в номере:
«Внутри Windows 7 Pre-Beta»
Вы, наверное, удивитесь, но анекдот, суть которого заключена во фразе: «Во-первых, это несъедобно, а во-вторых, почему так мало?», появился намного раньше, чем самая первая операционная система от Microsoft. Тем не менее именно этими словами можно описать реакцию на каждую из вновь появляющихся ОС этой фирмы. Вот краткий отчет об экскурсии в мир, который будет открыт для широкой публики через полгода...
«Безопасность в Windows 7»
Злые языки утверждают, что никто так много не говорит и столь мало не делает для безопасности пользователей, как Microsoft. По крайней мере, так было до сих пор. Все мы хотим быть защищенными, но так, чтобы самим для этого ничего не делать. Насколько хорошо этот факт осознали разработчики новой версии Windows и удалось ли им осуществить задуманное?...
«Шаблоны проектирования: практические примеры»
Первых проектировщиков ПО можно было назвать вольными творцами, художниками от программирования, создававшими все с нуля, однако современное проектирование - это, в основном, использование готовых решений, шаблонов проектирования, так называемых «паттернов» ...
Внимание! Книга может содержать контент только для совершеннолетних. Для несовершеннолетних чтение данного контента СТРОГО ЗАПРЕЩЕНО! Если в книге присутствует наличие пропаганды ЛГБТ и другого, запрещенного контента - просьба написать на почту [email protected] для удаления материала
«Структурные паттерны». В этой группе собраны паттерны, которые позволяют менять структуру взаимодействия классов. «Адаптер» (Adapter) позволяет адаптировать интерфейс класса к конкретной ситуации, средствами шаблона «Мост» (Bridge) можно отделить интерфейс класса и его реализацию, «Компоновщик» (Composite) объединяет объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам единообразно обращаться к отдельным объектам и группам объектов. Паттерн «Оформитель» (Decorator, также известен как Wrapper, «Оболочка») позволяет динамически добавлять новое поведение к объекту, «Фасад» (Facade) – скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы. Шаблон «Приспособленец» (Flyweight) используется для облегчения работы с большим числом мелких объектов, а «Заместитель» (Proxy) – контролировать доступ к объекту, перехватывая все вызовы к нему.
В группе «Паттерны поведения» собраны шаблоны, ответственные за реализацию поведения объектов. «Цепочка ответов» (Chain of Response) позволяет пропустить запрос через цепочку объектов, «Команда» (Command) инкапсулирует команду в объект, «Интерпретатор» (Interpreter) позволяет создать общее декларативное решение для часто изменяющихся условий задачи. В шаблоне «Итератор» (Iterator) организуется последовательный доступ к коллекции, «Посредник» (Mediator) определяет упрощенный механизм взаимодействия классов, «Напоминание» (Memento) задает принципы, позволяющие записывать и восстанавливать внутреннее состояние объекта. Средствами шаблона «Наблюдатель» (Observer) можно оповещать об изменениях множества объектов, «Состояние» (State) – менять поведение объекта при изменении его состояния. «Стратегия» (Strategy) инкапсулирует алгоритм внутри класса.
Паттерн «Шаблонный метод» (Template Method) выделяет конкретные шаги в алгоритме и опирается на подклассы для их реализации. Средствами паттерна «Посетитель» (Visitor) в класс добавляются новые операции без его изменения.
В этой статье мы рассмотрим паттерны из первой группы – «Порождающие паттерны».
«Фабричный метод»
Паттерн Factory Method позволяет реализовать идею «виртуального конструктора», то есть создания объектов без явного указания их типа. Обычно он применяется, когда базовый класс делегирует потомкам право принятия решений о типе создаваемого объекта. Предположим, что нам надо написать программу для сохранения документа на диск, причем в разных форматах: XML, txt, doc и даже бинарном. Создадим базовый класс, где будет код открытия файла и фабричный метод для создания конкретного объекта, который будет сохранять данные в этот файл.
class DocumentWriter
{
public: virtual void writeDoc(const Document& doc, FILE& file) = 0;
};
class SaveDocument
{
protected:
virtual DocumentFileWriter* createDocumentWriter() const = 0;
public:
void save(const char* fileName)
{
FILE file = openFile(fileName);
// Фабричный метод
DocumentFileWriter* writer = createDocumentWriter();
writer->writeDoc();
closeFile(file);
}
};
Обратите внимание, что теперь не надо менять базовые классы для добавления любого нового формата выходного файла. Нужно только создать два простых дополнительных класса, например для вывода в XML (см. листинг 1).
Листинг 1
class DocumentWriterXml: public DocumentWriter
{
public:
virtual void writeDoc(const Document& doc, FILE& file)
{
// код для сохранения документа в формате XML в файл file
}
};
class SaveDocumentXml: public SaveDocument
{
protected:
virtual DocumentFileWriter* createDocumentWriter() const {return new DocumentWriterXml();}
};
Главный недостаток этого шаблона – необходимость создания двух дополнительных классов при добавлении новой функции.
«Абстрактная фабрика»
Шаблон Abstract Factory предоставляет интерфейс для создания семейств связанных или зависимых объектов, позволяя не указывать их конкретные классы. Обычно он применяется, когда нужно создавать составные объекты из конкретных частей (объектов). Классический пример – автомобиль. Если есть классы для разных частей автомобиля, то конкретный автомобиль будет состоять из множества таких частей, причем в каждой марке автомобиля будут конкретные части-детали. Для окончательной сборки автомобиля можно использовать «Абстрактную фабрику», классы-потомки которой будут создавать конкретные автомобили.
class AbstractCarFactory
{
public:
virtual Car* createCar() = 0;
virtual Engine* createEngine() = 0;
virtual Wheel* createWheel() = 0;
...
};
Нам также понадобятся иерархии классов для каждой из частей автомобиля (см. листинг 2).
Листинг 2
class Engine
{
public:
virtual void setSpeedLimit(int kmph);
virtual void addOil(float amount);
...
};
class Wheel
{
float mRadius;
public:
Wheel(float radius): mRadius(radius) {};
virtual float getRadius() const {return mRadius;}
...
};
class Car
{
public:
virtual const char* getName() const = 0;
virtual void setEngine(Engine* engine);
virtual void setWheels(Wheel* FR, Wheel* FL, Wheel* BR, Wheel* BL);
virtual void setFrontWheels(Wheel* FR, Wheel* FL);
virtual void setBackWheels(Wheel* BR, Wheel* BL);
...
};
Процедура сборки итогового объекта приводится в листинге 3.
Листинг 3
Car* createCar(AbstractCarFactory* carFactory)
{
Car* car = carFactory->createCar();
Engine* engine = carFactory->createEngine();
car->setEngine(engine);
car->setWheels(carFactory->createWheel(), carFactory->createWheel(), сarFactory->createWheel(), carFactory->createWheel());
// дальше может идти сколько угодно сложный код для «сборки» готового автомобиля из частей
return car;
}
Для добавления конкретных моделей автомобилей нужно просто создать новый класс, породив его от AbstractCarFactory. Задача этого класса – создать конкретные детали автомобиля. Понадобится также создать классы этих конкретных деталей, если их еще нет.
class BMW5CarFactory: public AbstractCarFactory
{
рublic:
virtual Car* createCar() {return new CarBMW5();}
virtual Engine* createEngine() {return new EngineBMW5();}
virtual Wheel* createWheel() {return new WheelNokian(16);}
...
};
class CarBMW5: public Car
{
public:
virtual const char* getName() const {return «BMW5»;}
...
};
Главный недостаток этого паттерна состоит в том, что со временем становится труднее вносить изменения в структуру классов. Например, если у нас уже имеется 100 конкретных моделей автомобилей, а мы решили добавить в AbstractCarFactory новую функцию, создающую фары, то нам придется изменить все 100 классов-потомков, создающих конкретные модели.
