# Homebrew Channel - Object Patterns

This should be a part of our code refactoring and code cleanup.

## What's an object pattern?
An object pattern (or a design pattern) is simply a way of organizing your code. Code tends towards complexity over time (if you don't believe it, just see what you have done with your code in the past).

I am currently taking a Software Engineering course, and design patterns are very interesting and allow for code to follow the SOLID principle: Single Responsibility, Open/Closed Principle, Liskov Substitution, Interface Segregation, and Dependency Inversion. Now, since we are in C, and given what we are doing, unit tests are sort of unnecessary, we don't need dependency inversion, and we don't have classes in C. Regardless of whichever principle you follow, design patterns help create clean code.

Here is refactoring guru: https://refactoring.guru
It has a page specifically about design patterns (https://refactoring.guru/design-patterns). Here is a catalog of 22 (https://refactoring.guru/design-patterns/catalog).

Here is an article someone made about design patterns for C: https://dev.to/khozaei/design-patterns-for-c-32an

## What did fail0verflow do?
We won't know what their goal was when developing - probably to make something available ASAP. They most definitely use the [Facade pattern](https://refactoring.guru/design-patterns/facade), which basically is giving classes an interface to work with.

Widgets and views definitely work this way, no question about it. (if you guys find more that fit, lmk)

## What can we do?
**Sound support (bgm and effects) likely could benefit from a Singleton**, like [USB Loader GX does](https://github.com/wiidev/usbloadergx/blob/enhanced/source/SoundOperations/SoundHandler.cpp). A Singleton basically ensures we only have one instance of an object at one time that other methods access. I guess the main view variable is a singleton if you think about it.

**Theme, browser, anything that only should have one instance of it** also should have a Singleton. Take this example:

if (!strcasecmp(filename, theme_fn_xml)) {
				got_xml = true;
			} else if (!theme_is_valid_fn(filename)) {
				gprintf("not a valid theme filename\n");
				goto error;
			}

This is in `manage.c`. `theme_fn_xml` means absolutely nothing to me. What is "fn"? What xml? What we can do is have an inline public function that holds this stuff.

const char* theme_fn_xml;

inline const char* theme_get_fn_xml()
{
    return theme_fn_xml;
}

(hopefully this compiles)

By the way, this is always defined as
`const char *theme_fn_xml = "theme.xml";`
as far as I know. So this should go in config, but I think the general idea is clear.

**State Pattern** may be good for handling general app transition flows between dialogs.

**THIS IS NOT AN OBJECT PATTERN, IT IS A DESIGN PATTERN**: We can use a [Service locator](https://en.wikipedia.org/wiki/Service_locator_pattern) for when we move the loaders (gecko, tcp, whatever)

**Widgets** - factory pattern?

If you have any more ideas, let me know. Let's try to organize what we are thinking about, vote on it, and make it happen.