Site navigation

Software design question

General JUCE discussion
#1

Hi all. I’m having fun learning C++ using JUCE and hacking existing code. I’m having a bit of trouble organising my juce code in an elegant way. I have a class nested inside my networking class that is initialised within a page component in a tabbed component. Pointers to owners are passed down, so that when, for example, a callback in the nested class wants to change something in the tab page, I end up with code that looks something a bit like this . . .

… which works absolutely fine, but is a bit of an eyesore, is very confusing to maintain, and will cause problems sooner or later. Do I make the tab page globally accessible or something like that, or is there another neat solution? Sorry for the newbish questions and any suggestions or comments would be graciously received.

#2

Check out some books and sites on design patterns. Good design principles help in maintaining and organizing in the long run. I suggest the book Design Patterns Explained by Alan Shalloway and James R. Trott. It emphasises on Object-Oriented Design, and design patterns via this paradigm.

#3

Looks like it has some good reviews on amazon. Thanks for the suggestion :slight_smile:

#4

Looks like it has some good reviews on amazon. Thanks for the suggestion :)[/quote]

Just bought it. Found a bargain. In the meantime, can anyone suggest some potential solutions to my problem to get the brain cogs going. Thanks again.

#5

Stay D.R.Y: Whenever you find yourself repeating something, then it can probably be wrapped up into a method or class.

E.g. If you find yourself writing “owner.owner.owner” more than once, just wrap it up into a method, e.g.

Owner& getOwner() const { return owner.owner.owner; }

#6

Plus, if your classes are Components you could use the Component::findParentComponentOfClass function:
http://www.rawmaterialsoftware.com/juce/api/classComponent.html#a2fe04186c41dd8a78759a5e5c26de47e

So, for example, if you have a Component inside a Viewport and you need a pointer to the Viewport you could write:

Viewport* const viewport = findParentComponentOfClass ((Viewport*) nullptr);

#7

[quote]So, for example, if you have a Component inside a Viewport and you need a pointer to the Viewport you could write:

Code: Select all
Viewport* const viewport = findParentComponentOfClass ((Viewport*) nullptr);[/quote]

this old style explicit type-casting (Viewport*) i wouldn’t recommend, especially a newbie :wink:
Better is to store a reference, or a safepointer (if its not persistent) to the Viewport inside the component, when its created.

EDIT:
Ok, i see this is no explicit type-casting, forget my post

#8

Big globs of awesome. Thanks for the pearls of wisdom folks.

#9

Woah, the findParentComponentOfClass() method will come in handy for me. It’s a gem.

#10

Don’t over-use it! It’s usually better to keep a pointer to component that you need to use.

#11

Holy cow! I have never read a tech book from cover to cover so fast. I highly recommend it (especially for £4 on amazon). It really helps to make a lot of OO concepts “click”. I will definitely be implementing the decorator pattern in my next variation of the interprocess comms class and perhaps I will look at variations of the observer pattern to simplify the concept in my original post :wink: