When I programmed in C++, I never felt comfortable with creating a GUI. What about being a little schizophrenic: stay with C++ for most programming purposes, and use Managed C++ (Windows Forms) for the GUI?
Well, I tried to explain my goals. For the needs of the project I can use anything available - Qt, Win32++, or even straight Win API - it'll all work out fine, as GUI that I need it very minor. But the goal is not just use some framework to create GUI, but learn it for good and then use in extensively on my next job(s), and not jumping on a new framework every (half)year. I'm already at the age when job should also bring fun, not just money. And Managed C++ is by no means "fun" - whoever designed it was really, really sick, and probably inspired by Brainf.ck language Basically, there is no beauty of C++ left in it, only "Managed" horror :(
Kosta Cherry wrote: And Managed C++ is by no means "fun"
Depends on your definition of fun. MC is obsolete btw, have you tried C++/CLI? I find C++/CLI very enjoyable with the added satisfaction that I can mix native c++ code like no other managed environment would let me do. For a good amount of time, I struggled to find a decent standardized c++ framework for web applications and even though there were some I didnt like any (just like you) and finally the idea of using C++/CLI to utilize the powerfull .NET framework stuck. Its fun for me because with just a few lines of code I get to expose my native c++ functionality as WCF webservices and from the same executable. It is marketable because you get to learn new .NET stuff as well as the intricacies of mixing with native. Mastering WPF, even though with C++/CLI, will be profitable because WPF is going to stay especially with Metro apps coming out in upcoming Windows8 and the possibilities they open up for Windows App Store are huge.
A downside however is that mono still does not support C++/CLI therefore its not portable yet.
I know this is a silly thing to ask, but here it is. I have been working in development for about ten years now, I am pretty much a Google programmer in that I use the internet to find out what I need to fix code problems. I do not have any formal schooling. I have done fine building business applications, but now I want to move into a more corporate formal environment. I don't have the time to go to school to learn OO programming from scratch, nor do I really want to, but looking over questions other people have had from this company in interviews, I would just be clueless. I like to consider myself a practical programmer, the truth is, though, that I am just untrained.
With that said, can anyone recommend a site where I can go to gather some of this information? I think I mostly need help with the data structures and algorithms, as they don't come into my daily work.
Since you've been in the industry for a while, I expect a couple of books on Data Structures + Algorithms and Design Patterns (in the language of your choice) should see you through. When I was a student, I used an earlier edition of Algorithms and Data Structures by Niklaus Wirth[^] (who I also met later - he's a great guy, very personable). For design patterns, it's hard to go wrong with the Gang of Four[^] book.
OO is not so much about algorithms, it is more about design. The "Gang of Four" patterns are a good point. I also like "Applying UML and Patterns" by Craig Larman: he brings patterns, UML, and agile strategies together and explains them with good examples.
Where in the code do I best put object creation (stateful objects) and where not? In what layers?
For example, I once put an object reference inside a Hibernate DAO class and I was told that this was incorrect because DAO classes are not supposed to have state. State should be inside the 'service layer'.
I have been told that I should not create new objects on recurring method calls such as UpdateCart(). Creation of objects is costly and should not be sitting in your code everywhere. It should be sitting in initialization type methods only. For example, if an e-commerce application needs a cart, put it in the session. If it needs some general main object, put it in the initialization code. Create it once there and let the rest of the application access its instance later. Do not create this instance upon every call.
I'm confused about this whole design principle. The strangest thing I heard is 'an app is not supposed to have state. State should be kept in the data layer where the database is'. Really? I'm quite new to these design concepts and I don't know where to look in order to get more educated on it. GoF? Design Patterns books? The goal is to create qualitative code (i.e. to be used in the business).
Where in the code do I best put object creation (stateful objects) and where not?
Creation of objects is costly
No, it's not! This is an incomplete statement, and a fallacy; you can create a huge amount of objects, and very quickly. Creating huge objects in a loop, that is inefficient. The statement should be "do not create costly objects in a tight loop".
and should not be sitting in your code everywhere.
Decompile the Button class using ILSpy or something similar. You'll see efficient code, without a centralized factory. Objects should NOT come from one location, one uses a factory ONLY if appropriate. The "new" keyword isn't there just for the looks of things.
The strangest thing I heard is 'an app is not supposed to have state.
Too much monkey business, I'd be walking out on this statement.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
Last Visit: 31-Dec-99 19:00 Last Update: 30-Mar-15 18:31