OOP Project Ideas
-
Hey all, I'm not sure if this is the right place for this kind of discussion but I’ll ask anyways. I’ve been working on embedded systems for a while, mainly in C. I’d like to do more with C++/.Net (or other OOP languages/frameworks etc..) but I don’t know where to start in terms of a non-embedded project. My question is; does anyone have an idea for a project or perhaps worked on something that was useful and more challenging than text book style projects (ie something more “real world” that I can use to gain OOP experience in my own time). Any thoughts would be appreciated.
-
Hey all, I'm not sure if this is the right place for this kind of discussion but I’ll ask anyways. I’ve been working on embedded systems for a while, mainly in C. I’d like to do more with C++/.Net (or other OOP languages/frameworks etc..) but I don’t know where to start in terms of a non-embedded project. My question is; does anyone have an idea for a project or perhaps worked on something that was useful and more challenging than text book style projects (ie something more “real world” that I can use to gain OOP experience in my own time). Any thoughts would be appreciated.
Basically, it doesn't matter what you code, you can always choose to approach it from an OOP perspective. So, then it's just the question of what you want to create. I often create (small) tools, math-gimmicks like prime-number searches, and 'technical test projects' (to test out a specific API/environment/library for the purpose of learning). Others are more inclined to program games, or simulations, for instance. I think a pitfall in this case with creating a program in C++ is that it's all too tempting to use what you know in C and do it like that (though you'll have to consider for yourself if that applies). As soon as you have something you want to create, start thinking about the involved objects and their lifetime. Start simple, for your first project, and limit the complexity and amount of classes. Most of OOP is about dividing functionality and responsibility among classes and determining their lifetime, and modelling the interactions between them. A good strategy is to make each class responsible for exactly one thing and to use a 'black box' principle: other code/classes should only concern themselves with what the class does for them, and not 'how' it does it. A rule of the thumb related to this is that if you start writing code in class1 like
class2->memberClass->someMethod()that something is wrong, because now class1 needs to know the rules of class2::memberClass, which violates that black box principle. Of course, this is only a guideline and not necessarily is wrong. Good luck -
Hey all, I'm not sure if this is the right place for this kind of discussion but I’ll ask anyways. I’ve been working on embedded systems for a while, mainly in C. I’d like to do more with C++/.Net (or other OOP languages/frameworks etc..) but I don’t know where to start in terms of a non-embedded project. My question is; does anyone have an idea for a project or perhaps worked on something that was useful and more challenging than text book style projects (ie something more “real world” that I can use to gain OOP experience in my own time). Any thoughts would be appreciated.
Pick up Visual Studio and play around writing MFC apps. It will give you a nice into to classes, OO, UI design, and you can knock up some interesting apps. I use MFC a lot writing test programs for my Windows drivers and is an excellent technology.
============================== Nothing to say.
-
Basically, it doesn't matter what you code, you can always choose to approach it from an OOP perspective. So, then it's just the question of what you want to create. I often create (small) tools, math-gimmicks like prime-number searches, and 'technical test projects' (to test out a specific API/environment/library for the purpose of learning). Others are more inclined to program games, or simulations, for instance. I think a pitfall in this case with creating a program in C++ is that it's all too tempting to use what you know in C and do it like that (though you'll have to consider for yourself if that applies). As soon as you have something you want to create, start thinking about the involved objects and their lifetime. Start simple, for your first project, and limit the complexity and amount of classes. Most of OOP is about dividing functionality and responsibility among classes and determining their lifetime, and modelling the interactions between them. A good strategy is to make each class responsible for exactly one thing and to use a 'black box' principle: other code/classes should only concern themselves with what the class does for them, and not 'how' it does it. A rule of the thumb related to this is that if you start writing code in class1 like
class2->memberClass->someMethod()that something is wrong, because now class1 needs to know the rules of class2::memberClass, which violates that black box principle. Of course, this is only a guideline and not necessarily is wrong. Good luckThat's helpful thanks.