mattysmith22

Strategy pattern

This is useful if one class needs to do something, but there are multiple ways of doing that thing - think sorting algorithms, searching algorithms or layout managers.

Each "strategy" of doing it must have a common access method, abstracted away by an interface. As long as it correctly implements that interface, it is a valid strategy. My example will be for search algorithms through an array, so my interface will look as follows:

strategy.Searcher

package strategy;

mattysmith22

Observer pattern

The observer pattern is a design pattern useful when you need one object to be able to notify other objects about something occuring.

It works by having an observer interface that all objects that want to be notified of the event must implement, and then the notifier stores a list of the objects it needs to optimise. It then goes through this list of observers, notifying them using the given observers.

For my example, I will use an automatic checkout machine - after a transaction has been completed you need to make the balance change and print a receipt. First, let's build the interface they need to model:

observer.SaleObserver

mattysmith22

Iterator pattern

The iterator pattern is a design pattern that is useful for when you want to loop through arrays or similar data structures. It provides a common access methodology for these items.

In essence you have to implement two interfaces. The first is the thing which you want to be able to iterate through - that must implement the Iterable interface. Secondly, you must have an iterator object which handles the moving through - you can have multiple iterators in use simultaneously, as the state of where you currently are is stored within the iterator object. The iterator object must implement - surprise surprise - the Iterator interface.

An implementation of the two interfaces can be seen below:

public interface Iterable<T> {

mattysmith22

Singleton pattern

The singleton pattern is useful when you only want one instance of an object. Examples of this include shared resources (database connections, hardware access etc.), configurations and logging. I used the latter for our example here.

In essence you should only try to get an instance of an object through the getInstance method. This method should only construct a new instance if none have been used, otherwise it should reuse the already created one.

Here is an implementation of the singleton pattern:

package singleton;

mattysmith22

import random

class Project:
    risks = []

    def add(self, risk):
        self.risks.append(risk)
    
    def run_simulation(self, num_runs=1000):
        result = ProjectResult()

mattysmith22

import System.Environment
import System.Exit
import System.FilePath.Posix
import System.Directory
import Data.Char

isComment :: String -> Bool
isComment xs = "--" == (take 2 $ dropWhile isSpace xs)

stripComment :: String -> String

mattysmith22

module Dfa (DFA, State, transition, runString, match, findEquivalent, nequivalent, automaton1, automaton2, minimise) where

import Data.List
import Text.Layout.Table

type State = Int
data DFA = DFA
    { states :: [State]
    , initial :: State
    , final :: [State]

mattysmith22

_trigger = createTrigger ["EmptyDetector",[0,0,0], true]; 
_trigger setTriggerStatements ["!(missionNamespace getVariable ['mmfw_endconditions_timelimit_enabled',false])|| {((missionNamespace getVariable ['mmfw_endconditions_timelimit',-1]) - 5) * 60 < CBA_missionTime }", "if (missionNamespace getVariable ['mmfw_endconditions_timelimit_enabled',false]) then { hint '5 minutes remaining'; }", ""]; 
_trigger setTriggerInterval 10;

mattysmith22

import pyvis

bonesRaw = ["velka vrtule","","blade1", "velka vrtule", "blade1_rise1","blade1", "velka vrtule", "blade1","blade1_rise2","blade1","blade1_rise3","blade1","blade1_rise4","blade1","blade1_rise5","blade1","blade2","velka vrtule","blade2_rise1","blade2","blade2_rise2","blade2","blade2_rise3","blade2","blade2_rise4","blade2","blade2_rise5","blade2","blade3","velka vrtule","blade3_rise1","blade3","blade3_rise2","blade3","blade3_rise3","blade3","blade3_rise4","blade3","blade3_rise5","blade3","blade4","velka vrtule","blade4_rise1","blade4","blade4_rise2","blade4","blade4_rise3","blade4","blade4_rise4","blade4","blade4_rise5","blade4","swashplate_up","","swup_arm1","swashplate_up","swup_arm2","velka vrtule","swup_arm3","swashplate_up","swup_arm4","velka vrtule","swashplate_dn","","mr_act","","skin_fcr","","longbow","skin_fcr","mala vrtule","","tr_blade1","mala vrtule","tr_blade2","mala vrtule","tr_blade3","mala vrtule","tr_blade4","mala vrtule","tr_swashplate","mala vrtule","otocvez","","otochlaven","oto

mattysmith22

The error value in addition of values in configs (my guess due to it being implemented with a float as the data type for computation) increases to a large enough value that the DIK codes cannot be accurately calculated.

Here is an MRE with 3 examples that should resolve to the same key combo, but instead resolve to 3 different ones.

Packed with binarize