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

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

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

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

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

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

Обзор C/C++ компиляторов EMX и Watcom

Watcom C/C++

Watcom - звезда прошлого. Основные черты - многоплатформенность и качество кода. В лучшие времена генерировал код дя DOS real mode, DOS protected mode (DOS/4G, DOS/4GW, Phar Lap), Win16, Win32, Win32s, QNX, OS/2 (16- и 32-bit), Netware NLM. Причем, работая под любой системой, можно было генерировать код для всех остальных (к примеру, программу под Win32 можно было скомпилировать и слинковать из-под OS/2 и т.д.). Watcom стал весьма популярен во времена DOS-игр, работающих в защищенном режиме (DOOM и прочие).

К моменту появления версии 11.0 (1997 г.) фирма, разрабатывавшая Watcom, б1а куплена Sybase Inc., и это, к сожалению, возвестило о кончине компилятора. Дальнейшая разработка была практически заморожена, а в 1999 г. Sybase Inc. объявила о прекращении продаж и установила крайний срок, после которого будет прекращена и техническая поддержка для тех, кто еще успел купить компилятор (это было в середине 2000 г.). Дальнейшая судьба продукта пока неизвестна.

Последняя версия - 11.0B. C++ компилятор в ней не поддерживает namespaces и не содержит STL. Впрочем,

существуют многие реализации STL, поддерживающие Watcom C++ (к примеру, STLPort).

Под любую поддерживаемую систему есть набор стандартных утилит: компиляторы, линкер, отладчик(и), make, lib, strip и другие. В системах с GUI (OS/2, Windows) есть также IDE (хотя и не очень удобная).

Кодогенерация заст1ла на уровне 1997 г., и теперь даже MS Visual C++ обгоняет Watcom (естественно, сравнения проводились под Windows, но некоторое представление это дать может).

При работе с Watcom C++ под OS/2 нужно знать следующее:

В версиях 11.0* в линкере есть досадная ошибка, и вызовы 16-разрядных функций OS/2 (Vio*, Kbd*, Mou* и др.) будут давать трапы. Для борьбы с этим предназначена утилита LXFix, которая запускается после линкера и исправляет fixups.

В комплект входит весьма древний OS/2 Toolkit (от OS/2 2.x). Поэтому крайне рекомендуется установить Toolkit из последних (4.0, 4.5).

Кроме разработки родных OS/2-программ, Watcom C/C++ можно рекомендовать для компиляции кода, слабо привязанного к ОС. Наличие в стандартной библиотеке функций вроде dos setdrive(), поддерживаемых под всеми системами (ну, ии как минимум под OS/2, Win32 и DOS) позволяет писать в этом смысле платформонезависимо (для пользовательского интерфейса в данном случае можно использовать Turbo Vision).

И напоследок стоит еще раз напомнить про то, что компилятор более не развивается и не поддерживается. Имеющиеся проблемы никуда не денутся и не будут теперь решены.

EMX (GNU C/C++)

EMX - представительство Unix в OS/2 и одно из представительств Unix в DOS. Это целый комплект из компиляторов, сопутствующих утилит и библиотек поддержки. В первую очередь предназначен для портирования программ из среды Unix в OS/2, для чего эмулирует множество функций в