Управление пакетами — различия между версиями

Версия 22:19, 23 сентября 2007

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

Принципы организации кода

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

Ключевое слово package

Любой файл программы на языке К++ начинается с указания ключевого слова package, следом за которым идет идентификатор имени пакета. Это имя будет использоваться другими пакетами для того чтобы использовать данный.

Имя должно быть осмысленным и соответствовать содержимому. Например имена MyPackage123, blablabla или 4wiukdfnc являются неудачными, потому что не несут ровным счетом никакой смысловой нагрузки. В таких именах легко запутаться, сам программист по прошествии некоторого времени не всегда сможет вспомнить, что же было внутри пакета.

А вот примеры хороших, подходящих идентификаторов: math, avt_inventory или MyClass. В последнем случае, программист решил каждый класс помещать в отдельный пакет. В некоторых случаях это может быть оправдано, особенно если создается целая библиотека с большим набором классов, каждый из которых является довольно обширным.

Спецификаторы доступа

Часто бывает, что для реализации некоторого функционала создаются промежуточные вспомагательные сущности, которые используются только в пределах пакета и не экспортируются из него. Такие классы и функции должны помечаться как частные. Это осуществляется указанием ключевого слова private непосредственно перед ключевым словом class или function соответственно. Напротив, классы и функции, предназначенные для экспортирования из пакета, должны объявляться публичными, что осуществляется с помощью спецификатора public:

<source lang=kpp> package MyPackage;

private function MyPrivateFunction() {

   //...

}

public function MyPublicFunction() {

   //...

}

private class MyPrivateClass {

   //...

}

public class MyPublicClass {

   //...

} </source>

По умолчанию, все содержимое пакета считается частным. Однако, существует возможность задать это правило для всего содержимого пакета. Это осуществляется, путем дописывания соответствующего спецификатора в конец директивы package: <source lang=kpp> package MyPackage public; </source>

Теперь, все классы и функции, которые явно не объявлены приватными, будут считаться публичными.

Импортирование библиотек, ключевое слово import

Для испортирования сторонних библиотек, либо других пакетов программы используется ключевое слово import, следом за которым указывается либо идентификатор пакета, который необходимо импортировать, либо URL ресурса, который надо подключить. Последний указывается в одиночных кавычках:

<source lang=kpp> import OtherPackage; import 'http://example.com/media/idl/package.gidl'; import 'diss:/lib/test.gidl'; </source>

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