# An OOP question

This topic is 3309 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey guys I've got a question. I've worked in C++ for a while and I'm still not sure about some OOP concepts. When using OOP, should my main function have as little code as possible and should all of the program's functionality be encapsulated in classes?

##### Share on other sites
A good thing to keep in mind while programming is that OOP is a tool, not a way of life. Use objects where objects will best help you solve a problem, and use functions where functions will solve the problem.

You can do it either way. Putting everything in classes will help with organization, but might add more complexity than is needed.

##### Share on other sites
In general, placing code into an object is a result of refactoring. If you have a function that depends on a certain set of data, keep it a function. If you have two functions that depend on the same set of data, turn that set of data into an object and make those two functions members of the object. As always, keep a balance of "you ain't gonna need it" and "once, twice, refactor".

##### Share on other sites
Thanks. Ever since I found out how to use OOP I've been confused as to how much of the structured programming I should do away with.

BTW, what do you mean by "Once, twice, refactor"?

##### Share on other sites
Quote:
 Original post by Sazabi02BTW, what do you mean by "Once, twice, refactor"?

Wait until you know something needs to be changed in order to avoid things getting messy, but no longer (and hold yourself to a fairly strict standard of cleanliness). As your experience increases and your skill as a programmer improves, you will develop a better sense of what is "dirty".

##### Share on other sites
class HW{    void do() { std::cout << "Hello world." << std::endl; }};int main() { HW hw; hw.do(); }

This is a little overkill. You end up doing a lot of work and get no results. But, here's a time when objects would make life easier:
void f(){    // Call g with some globals. (bad style)    g(player_xPos, player_yPos, player_health, player_status);}

I actually have seen code like this. Actually, it was worse.

You really will have to just learn when to use it with your experience, as noted, but I think there's a little more to it. It has to make sense to you. If you don't understand OOP, then even if you implement it, it will be shallow.

So, I wish you luck on your journey of understanding.

##### Share on other sites
"Once, Twice, Refactor" is now a generic phrase guiding you to focus on writing the necessary code the first and second time you try to tackle a problem, but on the third time of visiting code for a problem, try to more correctly / completely reorganize the code to align the code and design.

Other thoughts along these lines:

Write for the moment first, write for the expected second, write for the future third.

Correctness First, Completeness Second, Reusability Third.

Make it work, Make it work right, Make it pretty.

My quote: "Write for the first time first, write for the next time next" - which is telling programmers on my team NOT to try and tackle the future problems the first time you get the code working, because you don't have the wisdom to have any good guidance about what parts of it are useful to reuse and what its natural / useful design really is. But the second time you solve a problem (you know, that time when you are tempted to copy-paste code from a previous project) ... solve it in a reusable way that would work for the first time, the second time (current), and the next time (third) ...

But always remember to temper these thoughts with "you ain't gonna need it" ... cause somewhere between 50% and 95% of the stuff we think we'll need or want, we actually don't. So don't waste too much time on what you don't need now, thinking you will need it later or just that you "should" do it.

Also be aware I have EXTREMELY high standards of code cleanliness - especially the rule that a function is named for what it REALLY does, so something like a function named "CalculateToHit()" that return a value but also has a side effect of applying that hit, would require - at a minimum - renaming to something that describes BOTH it's parts, or better yet, cut into multiple functions ...

##### Share on other sites
Oh ok! So I should only use OOP whenever it's needed not every time I get the opportunity to. I thought that's what C++ and OOP was all about. Turning everything into objects and doing away with all procedural methods. XD

##### Share on other sites
Quote:
 Original post by Sazabi02I thought that's what C++ and OOP was all about.

C++ is about making use of C++'s language features to solve a problem. C++ is NOT just an OOP language.

##### Share on other sites
I second "once, twice, refactor".

I suggest to be careful when refactoring. Identify what is the interface and what are the features. Many people believe they are the same thing. It's not true at all.

A feature set identifies what a class can do.
An interface identifies how you are going to use that class.

It is important not to confuse them while refactoring.

The problem is code using that class is INTERFACING to it, so people believe the worst problem lies in the INTERFACE. This is partially true, as in general a class needs an heavy refactoring when its FEATURES (or responsibility) fail to match the design requirements. A good approach IMHO is to focus on FEATURES. Once you'll have real code using that class, you can understand which INTERFACES you really need to easily let the class do the work it's supposed to do.

People often believe it's easier to change a feature set than an interface. This is Counter-intuitively false. At a first glance since other classes INTERFACE with your class, if you change the interface you need to change other code aswell, while changing a feature only requires to modify your class. It's true, but don't forget an INTERFACE is a way to expose a FEATURE. Thus the conclusion is if the feature set is going to change, the interface will likely have to change aswell.

Your worst enemy is a wrong/incomplete/bloated feature set. Decide what you need your class to do, implement the features and expose them.
Only after using that class you'll be able to exactly identify which interfaces you need to make the use of that class as easy as drinking fresh water.