Рафа, может всё же вернемся к программированию?
"у нас есть в схеме упр. стрелкой три основные части.
- пус
- ра
-кон
..........................
каждая за что-то отвечает.
как минимум уже есть 3 класса.
теперь надо каким-то образом описать эти кл. и сделать соотв. взаимодействие."
В ООП надо мыслить от Общего к Частному, а не наоборот.
Схема управления стрелкой - это частное, отдельные цепи, то же частное.
Что общее? Например, обмотка реле, контакт, соединение - все они должны быть Объектами со своими частными свойствами.
Для простоты: квадрат, прямоугольник, трапеция, круг - это всё графические объекты, что у них общего? Например, точка привязки, метод отображения должен быть у каждого. Поэтому делаем класс абстрактного графического объекта, который не может ничего, его даже в ПО вставить просто так нельзя, но в нем будет конструктор, поле координат привязки, поле идентификатора типа объекта (квадрат, прямоугольник, трапеция, круг), метод рисования. Далее делаем наследуемый класс квадрат от класса графический объект и в нем уже абстрактный метод рисования делаем реальным, т.е. описываем как надо данный объект рисовать. Вот этот класс можно уже будет вставить в ПО. Для отрисовки всей картины будет достаточно для всех графических объектов вызвать один и тот же метод рисования, а по таблице виртуальных ссылок вызовется нужный метод рисования для каждого конкретного графического объекта.
Ну, как-то так!

[quo

Эксперимент проводился на обычном вагоне метро в электродепо. Под приемные катушки был подложен переносной шлейф, которым мы обычно пользуемся.
http://morepic.ru/images3/img0036a1182_1039_124.jpg
Ток в шлейф задавался с помощью вот такого генератора, на индикаторе которого он контролируется.
http://morepic.ru/images3/img0038a2612_8105_8883.jpg
На подключенном нетбуке была запущена программа анализатора частот.
http://morepic.ru/images3/wp20150525..._3387_1371.jpg
В шлейф для каждой частоты задавались токи, а их уровни контролировались по шкале условных единиц, а напряжение на приемных катушках на параллельно подключенном к ним вольтметре. Погрешность всех приборов составляет не более 2,5-5%.
Была составлена таблица данных http://morepic.ru/images3/wp20150525..._5825_3960.jpg
где I - ток в шлейфе, U - напряжение на приемных катушках, К - значения условных единиц на компьютере.
Данных оказалось недостаточно и таблица была расширена.
Данные таблицы были внесены в Excel и по ним построены графики.
Приемные катушки на всех вагонах и входные сопротивления контуров приемников имеют почти одинаковые параметры, поэтому кривые на графиках должны подходить для любого вагона оборудованного системой АРС.

Я к примеру делал так. Пусть мозг будет "Прикладным процессом" в котором есть несколько рук - экземпляров класса "Задача", в абстрактном классе "Задача" есть метод "Работа". Мозг по очереди говорит руке - Работать, как работать описано в каждом классе конкретной Задачи, которая наследует абстрактный класс "Задача". Кроме того имеется Общий почтовый ящик - контейнер (коллекция или список). Каждая Задача во время работы создаёт Письмо (Сообщение) и бросает его в Почтовый ящик. Во время работы каждая Задача проверяет Почтовый ящик, уничтожает ранее посланные собственные Письма и выбирает письма, которые она должна обрабатывать, для этого выбора необходимо создать класс Фильтр.
Ну, как-то так!
Удачи вам, Рафа!

[quote=Пр

[quo

Давно назрела идея помощи дежурным электромеханикам в поиске неисправности (надоели их звонки среди ночи). Хотел создать что-то типа самообучающейся программы наподобие диалоговой "Диалы". Но это довольно тупая программа и обучаемости я в ней не вижу. Хочется создать программу такого типа, чтобы входные данные запоминались и выдавались при ответе на поставленный вопрос.
Например, механик пишет: - Отсутствует прием сигнальных частот.
Машина выдает: - "Проверь питание приемников".
Мех.: - "Питание в норме".
Маш.: - "Проверь чувствительность приемников"
и т.д.
Все случаи не предусмотришь, поэтому и требуется самообучение программы.

не проще ли алгоритм поиска неисправности сделать ?

Нет, не проще. Устройства очень сложные, да еще увязка с пневматикой, электрикой, дверями и прочей лабудой. У меня дома для оказания помощи под руками три (3)!!! комплекта разных схем одной и той же системы, но реализованной в трех модификациях: АРС-Д, АРС "Днепр" и "БАРС". Все они имеют разную структурную схему. Даже нумерация разъемов, у казалось бы одинаковых блоков, и та разная.
Это в СЦБ все типовое. А здесь нет даже двух абсолютно одинаковых вагонов. Монтажных схем нет. Монтаж укладывается по принципиалкам. Каждый монтажник прокладывает монтаж как ему нравится. Вот сейчас пыхчу - делаю монтажную схему заводского статива. Непонятно, как те же СЦБисты, которые разрабатывали напольные устройства могли разработать такую херню для вагона.

уже решили на чем писать будете ?

[quote=П

Для начала зачем вообще нужно наследование в С++? Что же оно даёт программисту, какие удобства?
Попробую пояснить на жизненном примере. Стул, стол, шкаф, тумбочка, диван - обобщенно можно назвать мебель. В ряде случаев нам не нужно конкретизировать какая именно мебель, например, мы говорим:-"Мебель расставлена в комнате не так!".
Другой пример. Каменщик, плотник, столяр - рабочие. Когда мы хотим выдать им команду, нам достаточно сказать:-"Рабочие работайте" и каждый займется своим делом.
Тоже происходит в ПО. Для того, чтобы не заморачиваться с выделением каждого типа объекта при вызове того или иного метода, делается наследование, метод Базового класса делают Виртуальным, а в наследуемом уточняют его. Достаточно часто в методе наследуемого класса сначала вызывают метод Базового класса (Base::work(); ), а затем дописывают индивидуальный код наследуемого класса.

[quote]

Какой то у вас сразу замес наследования с полиморфизмом произошел.
Если говорить только о наследовании, то можно проще:
Запускаем завод по производству машин. Есть, например, абстрактный класс(абстрактный - это значит что нельзя создать объект этого класса) МАШИНА. Мы берем и описываем подробно описываем что в нем есть поля: КОЛЕСА 4 ШТУКИ, ЦВЕТ, ТИП КУЗОВА и т.д.
Далее берем и создаем класс ЛЕГКОВОЙ АВТОМОБИЛЬ, который наследуется от класса МАШИНА и сразу же имеет поля КОЛЕСА и т.д. + дополняется своими полями, например КОЖАНЫЙ САЛОН, КОРОБКА АВТОМАТ и т.п.
Потом вдруг перепрофилировались и начали выпускать грузовые машины, тогда создает класса ГРУЗОВИК и наследуемся от класса МАШИНА + опять дополняем своими полями ТЕНТ, МОЩНЫЙ ДВИГАТЕЛЬ и т.п.
Т.е. мы в обоих случаях использовали старый код, не писав его заново, как это было бы в функциональном программировании, когда мы должны были бы описывать каждый объект с нуля, не используя "старые" созданные поля.
Если бы можно было создавать объект абстратного класса, то у нас бы просто с конвейера выпало 4 колеса, синий цвет, и какой-нибудь кузов...

Lamaks добавил 29.05.2015 в 15:14
Про инкапсуляцию:
Вы создали класса МАШИНА и вы даете пользователю только одну педаль - педаль газа, т.е. водитель через педаль регулирует скорость автомобиля, а не сам влезает под капот и копается в двигателе для увеличения скорости. Иными словами водитель не знает что происходит в двигателе, он знает что есть методы УВЕЛИЧИТЬ СКОРОСТЬ и УМЕНЬШИТЬ СКОРОСТЬ и все, а вся реализация от него скрыта. Так вот сокрытие реализации от пользователя и есть ИНКАПСУЛЯЦИЯ.
Про Полиморфизм:
В гараже стоит три машины СКОРАЯ, ПОЖАРНАЯ, МИЛИЦИЯ. Диспетчер говорит через громкоговоритель "Горит дом по улице Гороховая 137" и автоматически выезжает ПОЖАРНАЯ. Реализация этого, т.е. когда диспетчер говорит что случилось, а уже автоматически определяется кто едет на вызов и есть ПОЛИМОРФИЗМ.
ООП и строится на трех китах - инкапсуляция, наследование и полиморфизм.

[quoным ?