Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 18 December 2012 - 11:15 PM

OO is a Tool that makes it easier to write and maintain complex systems

That's why it and ideas like SOLID and separation of concerns were invented Posted Image
These guidelines weren't invented to impress teachers (who, in my experience, aren't often good programmers); they were invented so that large projects could be easily managed and reasoned about.

I have a class called Config that reads configurations from a LUA file. Almost all other module uses it, so now my solution is to pass it a reference in the constructor, witch seems right now.

That's a decent solution, but if you wanted to break it up more, so that there isn't this single "Config" entity that forges links between your entire code-base, you can break it up too, e.g.
/* foo.h */ class FooConfig { /* just foo stuff */ };
/* bar.h */ class BarConfig { /* just bar stuff */ };
/* config.h */ class FooConfig; class BarConfig;
class GlobalConfig { public: const FooConfig& GetFooConfig(); const BarConfig& GetBarConfig(); };
//cpp
#include all 3
int main()
{
  GlobalConfig& cfg = ...;
  Foo foo( cfg.GetFooConfig() );
  Bar bar( cfg.GetBarConfig() );
}
Now foo/bar don't have to have any connection between them at all, and instead at the next layer up in the code-base, the global-config composes them together into a useful whole.

Another matter of global access is a Log file that I have.

The "log file" example is always one that sparks a lot of discussion when it comes to globals/singletons/param-passing, and how best to deal with it...
Personally, I like to treat it specifically as an exception to the rule, because I don't see it so much as part of your application, but instead it's a part of the environment in which you're building your application. Things that form a part of your coding environment are ok to break the rules, because they're you're foundations and walls that need to be everywhere, holding up your code.
e.g. the connection to your IDE's debugger, or malloc/new or the call-stack, or the currently executing thread, are all 'environmental' features, like a debugging log. Every single bit of your code needs to run inside the environment created by these features.

#2Hodgman

Posted 18 December 2012 - 11:13 PM

OO is a Tool that makes it easier to write and maintain complex systems

That's why it and ideas like SOLID and separation of concerns were invented Posted Image
These guidelines weren't invented to impress teachers (who, in my experience, aren't often good programmers); they were invented so that large projects could be easily managed and reasoned about.

I have a class called Config that reads configurations from a LUA file. Almost all other module uses it, so now my solution is to pass it a reference in the constructor, witch seems right now.

That's a decent solution, but if you wanted to break it up more, so that there isn't this single "Config" entity that forges links between your entire code-base, you can break it up too, e.g.
/* foo.h */ class FooConfig { /* just foo stuff */ };
/* bar.h */ class BarConfig { /* just bar stuff */ };
/* config.h */ class FooConfig; class BarConfig;
class GlobalConfig { public: FooConfig* GetFooConfig(); BarConfig* GetBarConfig(); };
Now foo/bar don't have to have any connection between them at all, and instead at the next layer up in the code-base, the global-config composes them together.

Another matter of global access is a Log file that I have.

The "log file" example is always one that sparks a lot of discussion when it comes to globals/singletons/param-passing, and how best to deal with it...
Personally, I like to treat it specifically as an exception to the rule, because I don't see it so much as part of your application, but instead it's a part of the environment in which you're building your application. Things that form a part of your coding environment are ok to break the rules, because they're you're foundations and walls that need to be everywhere, holding up your code.
e.g. the connection to your IDE's debugger, or malloc/new or the call-stack, or the currently executing thread, are all 'environmental' features, like a debugging log. Every single bit of your code needs to run inside the environment created by these features.

#1Hodgman

Posted 18 December 2012 - 11:12 PM

OO is a Tool that makes it easier to write and maintain complex systems

That's why it and ideas like SOLID and separation of concerns were invented Posted Image
These guidelines weren't invented to impress teachers (who, in my experience, aren't often good programmers); they were invented so that large projects could be easily managed and reasoned about.

I have a class called Config that reads configurations from a LUA file. Almost all other module uses it, so now my solution is to pass it a reference in the constructor, witch seems right now.

That's a decent solution, but if you wanted to break it up more, so that there isn't this single "Config" entity that forges links between your entire code-base, you can break it up too, e.g.
/* foo.h */ class FooConfig { /* just foo stuff */ };
/* bar.h */ class BarConfig { /* just bar stuff */ };
/* config.h */ class FooConfig; class BarConfig;
class GlobalConfig { public: FooConfig* GetFooConfig(); BarConfig* GetBarConfig(); };[/code]Now foo/bar don't have to have any connection between them at all, and instead at the next layer up in the code-base, the global-config composes them together.

Another matter of global access is a Log file that I have.

The "log file" example is always one that sparks a lot of discussion when it comes to globals/singletons/param-passing, and how best to deal with it...
Personally, I like to treat it specifically as an exception to the rule, because I don't see it so much as part of your application, but instead it's a part of the environment in which you're building your application. Things that form a part of your coding environment are ok to break the rules, because they're you're foundations and walls that need to be everywhere, holding up your code.
e.g. the connection to your IDE's debugger, or malloc/new or the call-stack, or the currently executing thread, are all 'environmental' features, like a debugging log. Every single bit of your code needs to run inside the environment created by these features.

PARTNERS