Инкапсуляция класса. Велосипед.
Стал изобретать свой велосипед, чтоб как-то разбраться. Хочу спросить у опытных программистов, насколько кривой он вышел и в какую сторону исправлять.
Базовый класс - интерфейс
#include <iostream>
class BaseClass
{
public:
virtual void Set(int numb) = 0;
virtual int Get() = 0;
static BaseClass* MakeChild();
virtual ~BaseClass(){std::cout << "Base Object Deleted" << std::endl;}
};
#include <iostream>
#include "BaseClass.h"
// ChildClass может быть во включенном хедере
class ChildClass: public BaseClass
{
int v;
int Transform(int i){return i*2;}
public:
void Set(int numb){v = Transform(numb); }
int Get(){return v;}
~ChildClass(){ std::cout << "Child Object Deleted" << std::endl;}
};
// В исполнимом файле BaseClass эта функция необходима
BaseClass* BaseClass::MakeChild()
{
return new ChildClass;
}
Применение
#include <memory>
#include <iostream>
#include "BaseClass.h"
// тут не виден ChildClass
int main()
{
std::auto_ptr<BaseClass> p(BaseClass::MakeChild());
p->Set(5);
std::cout << p->Get() << std::endl;
// рисковый трюк, но можно сделать проверку
std::auto_ptr<BaseClass> *p2 = &p;
//p.reset(); // для испытания проверки
if(p2->get()) std::cout << (*p2)->Get() << std::endl;
return 0;
}
Заодно и auto_ptr помучал. Можно его так использовать или по варварски к нему я отнесся?
#ifndef KS_GETCLASS
#define KS_GETCLASS
#include <iostream>
class GetClass
{
public:
virtual int Get() = 0;
};
#endif
#include "GetClass.h"
class BaseClass: public GetClass
{
public:
virtual void Set(int numb) = 0;
static BaseClass* MakeChild();
virtual ~BaseClass(){std::cout << "Base Object Deleted" << std::endl;}
};
#include "GetClass.h"
// Тут даже BaseClass не виден
void test(GetClass *gc)
{
if(gc)
std::cout << gc->Get() << std::endl;
else
std::cout << 0 << std::endl;
}
#include "BaseClass.h"
// ChildClass может быть во включенном хедере
class ChildClass: public BaseClass
{
int v;
int Transform(int i){return i*2;}
public:
void Set(int numb){v = Transform(numb); }
int Get(){return v;}
~ChildClass(){ std::cout << "Child Object Deleted" << std::endl;}
};
// В исполнимом файле BaseClass эта функция необходима
BaseClass* BaseClass::MakeChild()
{
return new ChildClass;
}
#include <iostream>
#include "BaseClass.h"
#include "TestModuleGet.h"
// тут не виден ChildClass
int main()
{
std::auto_ptr<BaseClass> p(BaseClass::MakeChild());
p->Set(5);
std::cout << p->Get() << std::endl;
// рисковый трюк, но можно сделать проверку
std::auto_ptr<BaseClass> *p2 = &p;
//p.reset(); // для испытания проверки
if(p2->get()) std::cout << (*p2)->Get() << std::endl;
//p.reset(); // для испытания проверки
test(p2->get());
return 0;
}
Хотя основная идея уже в первой версии получилась. Тут почти ничего нового.
Вот например здесь разобрана очень простая задачка:
http://www.javenue.info/post/48, правда на Java, но это не имеет большого значения для проектирования.
Не обойтись и без паттернов (http://ooad.asf.ru/Patterns.aspx).
Если найдете интересную задачу, то (надеюсь) заинтересуете других участников форума.
Вот например здесь разобрана очень простая задачка:
http://www.javenue.info/post/48, правда на Java, но это не имеет большого значения для проектирования.
Не обойтись и без паттернов (http://ooad.asf.ru/Patterns.aspx).
Если найдете интересную задачу, то (надеюсь) заинтересуете других участников форума.
За ссылки спасибо. Особенно за первую (по второй у меня книга есть, до понимания которой я не дорос).
Я не абстрагирую абстрактную задачу. У меня есть реальный проект - программа, которая регистрирует данные от измерительного устройства (измеряет давление и температуру), выводит эти данные на экран, записывает в файл. Причем создано несколько версий для разного железа. В каждой версии я пытаюсь что-то оптимизировать - в данном случае я пытаюсь предотвратить ненужные перекомпиляции проекта при добавлении переменных и функций в крупные классы. Но для понимания как решить проблему я всегда строю подобные модели (за что уже один раз получил по шапке на этом форуме ))).
Умные люди давно мне советуют изучать паттерны. Однако пока я в книге банды четырех ничего не понял. Наверно, пока для меня их советы и есть "абстрагирование абстрактной задачи" - потому и не лезет в голову.
Я не студент (ВУЗ закончил сравнительно давно). Я никогда не работал на кафедрах в ВУЗах. Работаю на производстве. Но программированием занялся недавно.
Это же замечательно!
Тогда очень советую заглянуть в книжку:
Гради Буч. Объектно-ориентированный анализ и проектирование.
В главе 8 разобран пример проектирования системы сбора данных: метеорологическая станция - очень близко к вашей теме. Ключевые абстракции будут практически теми же.
Гради Буч. Объектно-ориентированный анализ и проектирование.
Спасибо. Надеюсь, что это будет ступень, на которую я смогу забраться.
Бесы одолевают? Судя по опечаткам - одолевают :)
Но, вроде бы, человек уважаемый. Буду думать, что я просто еще не дорос до понимания глубины мыслей Кота_. Вот дорасту - тогда сделаю ему его базу данных с испольованием STL и т.п... подождите годик-другой.
Почему равенство? Раскройте тайный смысл...
вы фразы целиком читаете? или только те буквы которые вам известны?
2Kogrom
нет. только тупиздни. к счастью.
Целиком и полностью, а вот вы, по-моему, не читаете их вовсе. Я использовал такие слова, как: пример, близко, практически. Поэтому мне не понятно ваше высказывание. Так что повторю вопрос:
Почему равенство? Раскройте тайный смысл...