138 reputation
5
bio website ebonyfortress.com/blog
location Nottingham, United Kingdom
age 37
visits member for 3 years, 6 months
seen Oct 30 at 9:58

Independent game programmer, designer, and musician. Previously a professional game developer, web developer, and GIS developer. Experience in C++, SQL, Python, networking, concurrency, distributed systems, scripting, and various game and web technologies.


Sep
1
awarded  Critic
Nov
23
comment std::shared_ptr as a last resort?
In a game project I worked on we found that the performance difference was very significant, to the point where we needed 2 different types of ref-counted pointer, one which was threadsafe, one which was not.
Jul
10
comment Are separate business objects needed when persistent data can be stored in a usable format?
Well... it's not really stored in the presentation format, since nothing is showing the JSON directly. It's more of a data exchange format. The client software is responsible for presentation, and as such different clients could display the data differently.
Jul
10
asked Are separate business objects needed when persistent data can be stored in a usable format?
Mar
1
awarded  Scholar
Mar
1
accepted Splitting 1 large object into 2 tightly-coupled ones - good, bad?
Feb
29
comment Splitting 1 large object into 2 tightly-coupled ones - good, bad?
Yet making it public implies that any caller can use the functionality, but that is not the intent.
Feb
29
comment Splitting 1 large object into 2 tightly-coupled ones - good, bad?
The structure of my system is such that there will only ever be a 1-to-1 relationship between the BusinessLogic and the AppInterface, as the interface is designed specifically to give access to a subset of this logic. So I agree with your suggestion on general grounds, but I don't think it applies to my case.
Feb
29
comment Splitting 1 large object into 2 tightly-coupled ones - good, bad?
BusinessLogic makes a single call into AppInterface to initiate the RPC processing but that is a simple and well-defined interface (a bit like the visitor pattern saying "call this with me as the argument"). Your second point is pretty much what I was thinking - the complex logic should probably be moved into BusinessLogic and AppInterface should just call that instead.
Feb
29
comment Splitting 1 large object into 2 tightly-coupled ones - good, bad?
BusinessLogic is very big, constantly changing in line with business needs, and is ultimately the decider of what goes into AppInterface, not the reverse. Abstracting out an interface would probably be too much work given that it will be constantly evolving and that only AppInterface (and any tests) will ever depend on it.
Feb
29
comment Splitting 1 large object into 2 tightly-coupled ones - good, bad?
For the most part AppInterface only relies on BusinessLogic functions - but occasionally there is no public function for what it needs to do, nor will any other object ever require there to be such a public function. So for now I have AppInterface access the private functions and objects to do what it needs to do, as if they were 'friend' functions in C++. Is that worse than exposing new public functions that no other object should use? I don't know.
Feb
29
awarded  Student
Feb
29
asked Splitting 1 large object into 2 tightly-coupled ones - good, bad?
Jun
9
awarded  Autobiographer
Jun
9
awarded  Supporter