1 Алгоритм проектирования иерархии классов в ООП Шаг 1 Следует взять и потрясти заказчика (или самого себя, если сам все придумал) чтобы получить побольше описания темы на русском языке (надо именно на русском!), которая будет реализована в будущей программной разработке. Этот текст должен содержать, насколько это возможно, максимально подробное описание: - основных процессов; - субъектов, которые участвуют в этих процессах; - объектов, с которыми производятся какие-либо действия. После этого следует просмотреть текст и выбросить из него все, что к делу не относится. Желательно избавиться от уточняющих слов, особенно наречий и причастий, сложных предложений с деепричастными и причастными оборотами. После необходимо дописать к тексту то, что не упомянуто, а по идее должно быть. После таких исправлений русскоязычного текста его следует перечитать и немножко погордиться, поскольку первый этап выполнен.

2 Алгоритм проектирования иерархии классов в ООП Фирма выполняет любые ремонтные работы Директору фирмы поступает заказ от клиента: сделать ремонт кафе «Олимп» и оформить его в древнегреческом стиле. Директор поручает дизайнеру разработать проект интерьера кафе «Олимп». Дизайнер разрабатывает несколько вариантов проекта. Клиент выбирает один из вариантов. Директор отправляет на место специалиста, который оценивает объем работ и количество расходуемых материалов (составляет смету). Директор заключает договор с клиентом по типовой форме. Помощник Директора делает заказ поставщикам на поставку материалов, принимает и проверяет их качество. После этого бухгалтер выделяет деньги на их оплату. Стройматериалы доставляются на место, и рабочие приступают к работе. За работой следят прораб, который распределяет обязанности, и дизайнер, который определяет какие работы нужно сделать. К определенному сроку рабочие заканчивают работу. Директор и специалист проверяют качество работы и сдают объект клиенту. Если у клиента есть замечания, которые оговорены в договоре, то директор обязуется все исправить. Директор поручает рабочим ликвидировать все изъяны. Кафе сдается клиенту, он оплачивает ремонт. Деньги поступают на счет фирмы и бухгалтер распределяет их на заработную плату рабочим и на другие нужды фирмы. Директор получает другой заказ и все повторяется.

3 Алгоритм проектирования иерархии классов в ООП В лесу родилась елочка, в лесу она росла. Зимой и летом стройная, зеленая была. Шаг 2 Отдельно выписываются слова, являющиеся: - существительными, - прилагательными, - глаголами, - союзами и другими частями речи. существительные:лес, елочка, зима, лето глаголы:родиться, расти, быть прилагательные:стройная, зеленая союзы:и Для упрощения местоимение "она" можно отнести к существительным, а предлог "в" - к союзам.

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

5 Алгоритм проектирования иерархии классов в ООП Прилагательное отображается на абстрактные базовые классы или в интерфейсы, поскольку прилагательное по своей сути есть признак, характеризующий нечто таким образом, что если прилагательное относится к этому нечту, то это нечто есть реализация этого прилагательного. Например, если есть прилагательное "объемный", то завести напрямую такой объект нельзя. Однако при этом "объемным" могут быть другие классы (существительные, имена нарицательные). "Объемным" может быть "ящик", "изображение", "понятие". Любое из приведенных существительных может быть использовано в качестве реализации прилагательного "объемный". Если некоторое действие оперирует понятием "объемность", то в качестве его аргумента могут быть использованы перечисленные существительные. Один объект может реализовать несколько интерфейсов одновременно. Например, объект Ящик может иметь признаки "объемный", "цветной", "прочный" одновременно.

6 Алгоритм проектирования иерархии классов в ООП Существительные, имена нарицательные, отображаются в классы, по которым реально могут быть заведены объекты. Основным отличием существительных есть понятие "существование". Если нечто является существительным, то это нечто может существовать или не существовать. В программировании прямым аналогом является вписывание в архитектуру классов однозначно выделенного класса, отвечающего именно за возможность заведения объекта. В Java таким главным классом является класс Object. Классы, которые могут иметь представителей (по которым можно создать объект), практически всегда есть наследники такого базового класса с добавлением собственного поведения и / или с множественным наследованием ранее объявленных интерфейсов – моделирующих имена прилагательные. Существительные, имена собственные, отображаются на объекты как экземпляры неких классов. Имя как в русском языке, так и в языке программирования играет одну и ту же роль - указать среди набора объектов один из них. Объекты именуются и указываются путем указания имени.

7 Алгоритм проектирования иерархии классов в ООП Глаголы отображаются на функции. Функции есть реализация алгоритма, последовательности неких действий. Это не данные и не определения. Функции отличаются от иных понятий тем, что они выполнимы и при выполнении воздействуют на что-то. Функция может что-то преобразовать, перевести объект из одного состояния в другое, либо передать информацию без изменений. Прилагательное характеризуется набором глаголов. Верно и обратное - набор глаголов определяет прилагательное, поскольку понятие определяется набором отношений, в котором оно участвует. Например, прилагательное "объемный" может характеризоваться набором глаголов "вмещать", "сравнить". Набор глаголов, входящих в описание прилагательного, есть те ниточки, за которые можно дергать объект, к которому это прилагательное относится. Глагол во многих случаях программистами не относится явно ни к какому прилагательному, и при описании класса программист просто наследует класс от Object и добавляет ему функции (методы для Java). На самом деле это так же есть определение прилагательного, но, если можно так сказать, явно не именованного. При этом программист мог бы существенно выиграть, если бы явно оформил добавляемые функции в виде интерфейса.

8 Алгоритм проектирования иерархии классов в ООП В лесу родилась елочка, в лесу она росла. Зимой и летом стройная, зеленая была. существительные:лес, елочка, зима, лето глаголы:родиться, расти, быть прилагательные:стройная, зеленая союзы:и Для упрощения местоимение «она» отождествим с существительным «елочка», а предлог «в» - вообще пока рассматривать не будем.

9 Алгоритм проектирования иерархии классов в ООП Наличие союзов вида "и", "или" явно свидетельствует о существовании предикативных условий или наборов данных. Если союз связывает аргументы некоего действия, то это формулировка предиката, если результата действия - то формулировка набора. В нашем примере получим: Интерфейсы: IСтройный, IЗеленый. Классы – наследники класса Object, которые можно завести: OЛес, OЕлочка, OЗима, OЛето. Функции (методы): mРодиться, mРасти, mБыть. Союз "и" однозначно указывает на наличие набора.

10 Алгоритм проектирования иерархии классов в ООП Шаг состоит в том, чтобы из набора полученных на третьем шаге отображений составить иерархию классов. Глаголы следует распределить по прилагательным, либо явно добавить к существительным. Существительные следует, если это необходимо, наследовать от прилагательных либо от других существительных. Имена собственные должны получить класс и быть оформлены в виде объектов (экземпляров созданных классов). Шаг 4

11 Алгоритм проектирования иерархии классов в ООП Прилагательные "стройная" и "зеленая" заменяем на прилагательные "фигурный" и "цветной", отводя им возможность быть уточненным - какая именно фигура и какой именно цвет. Таким образом получим интерфейсы: interface IФигурный { } и interface IЦветной { } Глаголы. Чтобы отнести глагол к прилагательному, следует внимательно прочитать исходный текст на русском и определить контекст действия глагола. Выяснить, какое прилагательное он характеризует. В нашем примере глагол "быть" относится к прилагательным "цветной" и "фигурный". Глаголы "родиться" и "расти" не относятся ни к одному из прилагательных, а выражают действия, которые может производить существительное "елочка". Уточняем описание интерфейсов: interface IФигурный { final String[ ] FIG = {стройная, корявая}; void mБыть(boolean u, OEлочка x); } interface IЦветной { final String[ ] COL = {зеленая, пегая}; void mБыть(OEлочка x, boolean u); } Необходимо предусмотреть наличие в в интерфейсах двух массивов константных строк: String[ ] FIG = {стройная, корявая}; String[ ] COL = {зеленая, пегая}; которые определяли возможные варианты фигуры и цвета «елочки». Различный порядок формальных параметров методов mБыть() сделан для того, чтобы за счет перегрузки не путать, какое свойство проверяется: фигурность или цветность.

12 Алгоритм проектирования иерархии классов в ООП Существительные. "лес " - обычный класс, наследуемый от Object. Допустим, что свойством класса «лес» является количество деревьев в нем. сlass OЛес {int num; ОЛес(int col) { num = col; } "зима", "лето " – является набором, соединенным союзом и. Если отнести эти существительные к разным классам, то получим набор разнотипных данных. Это некрасиво и лучше провести модификацию схемы классов. Проведем укрупнение классов "зима" и "лето" путем отнесения их к одному классу и различением их признаком "время года через соответствующий интерфейс. interface IВременаГода { final String [ ] VG = {зима, весна, лето, осень}; } class ОВремяГода implements IВременаГода { String name_vg; ОВремяГода(int i) { name_vg = VG[i]; } По исходному тексту, функция "быть" возвращает набор из существительных «зима» и «лето», но это пока оставим за кадром.

13 Алгоритм проектирования иерархии классов в ООП «Елочка» - класс-наследник от Object использует интерфейсы IФигурный и IЦветной,а также имеет метод mРодиться() – данный метод моделирует прибавление «елочки» к «лесу», сам факт появления «елочки» можно смоделировать работой конструктора класса ОЕлочка. Второй метод mРасти() для упрощения пока будем считать прибавлением возраста «елочке» по истечению года. public class OЕлочка implements IФигурный, IЦветной { String param[ ] = new String[2]; int vozrast; OЕлочка() { param[0] = ; param[1] = ; vozrast = 0; } public void mРодиться(ОЛес y) {y.num++; } public void mРасти (OЕлочка z) {z.vozrast++; } void mБыть(boolean u, OEлочка x){ if ( u) {x.param[0] = FIG[0]; } else {x.param[0] = FIG[1]; } } void mБыть(OEлочка x, boolean u){ if ( u) {x.param[1] = COL[0]; } else {x.param[1] = COL[1]; } } param[ ] – набор свойств «елочки» (фигурность и цветность), vozrast – возраст «елочки». Эти переменные класса в конструкторе нулевые. Реализация методов из интерфейсов, в зависимости от совокупности пока виртуальных внешних условий, выраженных логической переменной u (если все нормально – u = true, то «елочка» будет зеленая и стройная, иначе – u = false, кривая и пегая).

14 Алгоритм проектирования иерархии классов в ООП public class Stih { public static void main(String args[ ]){ Random rand = new Random(); ОЛес les = new ОЛес(100); // В лесу ОЕлочка ee = new ОЕлочка(); // Родилась boolean uslovia() { if (rand.nextDouble() < 0.8) {return true; } else {return false;} } mРодиться(les); // в лесу прибавилось одно дерево // моделируем календарный год и выбираем «зиму» и «лето» OВремяГода[ ] seas; ns = -1; for ( int j=0; j

15 Алгоритм проектирования иерархии классов в ООП import java.util.Random; interface IФигурный { final String[ ] FIG = {стройная,корявая}; void mБыть(boolean u, OEлочка x); } interface IЦветной { final String[ ] COL = {зеленая,пегая}; void mБыть(OEлочка x, boolean u); } сlass OЛес {int num; ОЛес(int col) { num = col; } interface IВременаГода { final String [ ] VG = {зима, весна,лето, осень}; } class ОВремяГода implements IВременаГода { String name_vg; ОВремяГода(int i) { name_vg = VG[i]; } public class OЕлочка implements IФигурный, IЦветной { String param[ ] = new String[2]; int vozrast; OЕлочка() { param[0] = ; param[1] = ; vozrast = 0; } public void mРодиться(ОЛес y) {y.num++; } public void mРасти (OЕлочка z) {z.vozrast++; } void mБыть(boolean u, OEлочка x){ if ( u) {x.param[0] = FIG[0]; } else {x.param[0] = FIG[1]; } } void mБыть(OEлочка x, boolean u){ if ( u) {x.param[1] = COL[0]; } else {x.param[1] = COL[1]; } } public class Stih { public static void main(String args[ ]){ Random rand = new Random(); ОЛес les = new ОЛес(100); ОЕлочка ee = new ОЕлочка(); boolean uslovia() { if (rand.nextDouble() < 0.8) {return true; } else {return false;} } mРодиться(les); OВремяГода[ ] seas; ns = -1; for ( int j=0; j

16 Алгоритм проектирования иерархии классов в ООП Фирма выполняет любые ремонтные работы Директору фирмы поступает заказ от клиента: сделать ремонт кафе «Олимп» и оформить его в древнегреческом стиле. Директор поручает дизайнеру разработать проект интерьера кафе «Олимп». Дизайнер разрабатывает несколько вариантов проекта. Клиент выбирает один из вариантов. Директор отправляет на место специалиста, который оценивает объем работ и количество расходуемых материалов (составляет смету). Директор заключает договор с клиентом по типовой форме. Помощник Директора делает заказ поставщикам на поставку материалов, принимает и проверяет их качество. После этого бухгалтер выделяет деньги на их оплату. Стройматериалы доставляются на место, и рабочие приступают к работе. За работой следят прораб, который распределяет обязанности, и дизайнер, который определяет какие работы нужно сделать. К определенному сроку рабочие заканчивают работу. Директор и специалист проверяют качество работы и сдают объект клиенту. Если у клиента есть замечания, которые оговорены в договоре, то директор обязуется все исправить. Директор поручает рабочим ликвидировать все изъяны. Кафе сдается клиенту, он оплачивает ремонт. Деньги поступают на счет фирмы и бухгалтер распределяет их на заработную плату рабочим и на другие нужды фирмы. Директор получает другой заказ и все повторяется.