Let’s get started with Assignment 3 colleagues

Kumar, Additional Resources page. It's a zip file with all the past exam papers in it.

@dubblelodub

Your coupling is unnecessarily tight.

Why do you want the BlackJack class to clean up the card layouts. If you look at the UML diagram, the QLabels belong to the Card class so that class should control their creation and deletion. The layouts are the property of the HandView class and thus cleanup is the responsibility of the HandView class.

The only GUI things the BlackJack class needs to take care of are the QActions, and the QMenu and QToolBar their attached to, and the two HandView classes. If you've made the BlackJack class the parent of all of those, you don't need to code for their deletion. That will be automatically taken care of by the internals of QObject.

@Kumar06

Tutorial 103.

@Spectre, unless a miracle happens, if you did all assignments, you should be able to pass this module.

@robanaurochs Well they said that was the suggested design.... I did things a little differently... I didn't use any QActions, just simple slots and signals, BlackJack inherits from QWindow and controls all UI functions. The QLabels are created from the Card class but since the ui object is part of BlackJack I insert the QLabels using the BlackJack class.

Also I didn't use the HandView class at all.. instead put the two layouts for Player and Dealer into the ui object, so, correct me if I'm wrong, but in my case, the BlackJack class is in fact responsible for cleaning up the Card QLabels. I'm not entirely sure if deleting the memory occupied by a Card object would delete it in the UI.. don't know much about QT GUI components/internals.

@dubbelodub

If you didn't inherit BlackJack from QMainWindow, did you use QPushButtons instead of a QMenu and a QToolBar? This is the only way I can think you might have used to get around without using QActions.

If your program works and performs all of the requirements, excellent, congratulations.

A word of warning though for more complex programs. You've briefly started learning about Design Patterns in this module and you'll learn a lot more about them in the 3rd level module as well. What they don't mention are the anti-patterns. By combining the HandView and the BlackJack classes, you're moving in the direction of the God Class anti-pattern. It's better in terms of design, debugging and modifying to keep your classes simple and focused on as few tasks as possible.

Unless you created functions, it's also quite possible that you duplicated a bit of code to get the Player and the Dealer layouts in place. This duplication will be avoided by delegating responsibilities to smaller classes.

#Rules of thumb:
1. If you're duplicating code, try and group those lines into a function and replace the duplication with calls to that function.
2. If you find you're duplicating functions in different classes, extract those functions into a new class (or multiple classes if they don't logically group together) and then create instances of the new class(es) instead.
----------------------------------------------
About deleting the QLabel in the Card object: if you have set the HandView (or in your case, the BlackJack class) as the parent of the QLabel, deleting the QLabel in the Card class should remove it from the UI.

The core of the Qt Framework is based largely on two design patterns: the Composite Pattern (implemented as the QObject parent/child hierarchy) and the Observer Pattern (implemented as the signals/slots mechanism).

When you make one QObject the child of another, internally, a parent variable in the child is set to the parent QObject, and the child QObject is added to a QList<> of children. If you delete the parent, it first iterates through it's list of children and deletes them. If you delete a child instead, it will remove itself from the parent QObject's list of children. This way, the Composite Pattern is maintained and double-deletion is avoided.

In the case of QWidgets, every child that is not set as invisible, is drawn within the boundaries of the parent QWidget. Just like with any other QObject, if you delete a child, it is removed from the list of children of the parent QWidget and this will trigger the parent to redraw itself on the screen. Since one of the children is no longer there, deleting a child will effectively remove it from the screen.

----------------------------------------------
If you look at the UML diagram for the exercise and compare it to the MVC pattern, the Card class is serving two roles. It is functioning as both a model class and a view class. I say this because a QLabel is a class used for displaying information to a user, not really for containing and/or manipulating data. It would be much cleaner to split these two roles up.

It would be better to replace the m_label data member with a QPixmap that holds the image data of the card and then let the HandView create/delete the QLabel instances as and when needed and setting the correct image by querying the Card instances (via the Hand class). This way, the HandView is the owner of all QLabels and managing them becomes so much simpler.

If you might be concerned that continuously creating and deleting QLabels will cause lots of copying of data from the QPixmap, don't be. Most of the non-QObject classes in the Qt framework use the concept of implicit sharing (look it up in the Qt Assistant). As long as you don't try and modify the image data, there will only ever be a single data instance for each card.

@robanaurochs

Wow, very interesting reading. Yes, you're totally right.. but to be honest I was quite pressed for time and
I can honestly say this was not my best work.. but it does work which is I think better than having it not working at all.

robanaurochs Wrote:
-------------------------------------------------------
> @dubbelodub

> In the case of QWidgets, every child that
> is not set as invisible, is drawn within the
> boundaries of the parent QWidget. Just like
> with any other QObject, if you delete a
> child, it is removed from the list of children of
> the parent QWidget and this will trigger
> the parent to redraw itself on the screen. Since
> one of the children is no longer there, deleting a
> child will effectively remove it from the screen.

Hmmm, I'm not sure if thats maybe a bug in the linux implementation of QT or something.. because I tried so straight up delete the QLabel and it sort of stayed in the layout, kind of like half there... I can't really explain it. I found the only way was to call "delete child->widget()" where child is a pointer to the QLabel.. straight up going for "delete child" didn't work..

I guess my UI object was also kind of functioning as a "God Object" and it could have been split up.


robanaurochs Wrote:
-------------------------------------------------------

> Unless you created functions, it's also quite possible that you duplicated a bit of code to get the
> Player and the Dealer layouts in place. This duplication will be avoided
> by delegating responsibilities to smaller classes.

Yup! Having to play with layouts upon each slot call definitely makes things overcomplicated.
"Spagetti Code" I think they call it.
That's something I really need to do properly from now on...

Thanks