MOAL.software_engineering.problem_solving.design_patterns.unix package

Submodules

MOAL.software_engineering.problem_solving.design_patterns.unix.modularity module

class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppAuthentication[source]
authenticate(*args, **kwargs)
new_user(*args, **kwargs)
reset(*args, **kwargs)
update_password(*args, **kwargs)
class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppModel[source]
create(*args, **kwargs)
delete(*args, **kwargs)
read(*args, **kwargs)
update(*args, **kwargs)
class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppRenderer[source]
get_static(*args, **kwargs)
parse_template(*args, **kwargs)
render(*args, **kwargs)
render_to_json(*args, **kwargs)
class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppRouter[source]
get_params(*args, **kwargs)
get_post(*args, **kwargs)
parse_route(*args, **kwargs)
route(*args, **kwargs)
class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppView[source]

Handles the application request/response cycle

request(*args, **kwargs)[source]
respond(*args, **kwargs)[source]
stream(*args, **kwargs)[source]
class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.BigBloatedAppClass[source]
authenticate(*args, **kwargs)
create_model(*args, **kwargs)
delete_model(*args, **kwargs)
get_params(*args, **kwargs)
get_static(*args, **kwargs)
new_user(*args, **kwargs)
parse_route(*args, **kwargs)
parse_template(*args, **kwargs)
read_model(*args, **kwargs)
render(*args, **kwargs)
render_to_json(*args, **kwargs)
request(*args, **kwargs)
respond(*args, **kwargs)
route(*args, **kwargs)
update_model(*args, **kwargs)
upload(*args, **kwargs)
class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.FtpView[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppView

class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.HttpView[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppView

class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.JsonView[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppView

class MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.TemplateRenderer[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.unix.modularity.AppRenderer

MOAL.software_engineering.problem_solving.design_patterns.unix.representation module

MOAL.software_engineering.problem_solving.design_patterns.unix.representation.DEBUG = False

Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.

Source: http://www.catb.org/esr/writings/taoup/html/ch01s06.html

“Data is more tractable than program logic. It follows that where you see a choice between complexity in data structures and complexity in code, choose the former. More: in evolving a design, you should actively seek ways to shift complexity from code to data.”

Also see: http://www.catb.org/esr/writings/taoup/html/generationchapter.html

MOAL.software_engineering.problem_solving.design_patterns.unix.representation.example_1_bad_method(arg)[source]

This is convoluted and hard to read. It is also potentially less performant, since the logic branching must be generated and evaluated.

MOAL.software_engineering.problem_solving.design_patterns.unix.representation.example_1_good_method(arg)[source]

This employees pure data, and is fast as it assumes a lookup, which is always O(N). The failed assumption is caught and handled, and new lookups can be quickly added, without adding much to the complexity.

MOAL.software_engineering.problem_solving.design_patterns.unix.representation.example_2_bad_method(arg1, arg2)[source]

Continuing down this path of complicated conditional branching, things get hairy very fast. Think about cognitive processing time when reading this code – it’s easy to make a mistake here.

MOAL.software_engineering.problem_solving.design_patterns.unix.representation.example_2_good_method(arg1, arg2)[source]

Mapping inputs to this nested dictionary is easy and intuitive, compared to the more cognitively challenging task of parsing multiple levels of conditional branching statements. It is obvious almost immediately to look at the arguments and map them to the data and see what the result is.

This is exemplified in the below quote from catb.org:

“In Chapter 1 we observed that human beings are better at visualizing data than they are at reasoning about control flow.”

More advanced examples of this concept are discussed within the context of clojure s-expressions on the amazing “macronomicon” video by Michael Fogus: https://www.youtube.com/watch?v=0JXhJyTo5V8 this is not surprising to me because lisp-style languages are typically homoiconic, or nearly so, and so the code-as-data paradigm is commonplace for them.

MOAL.software_engineering.problem_solving.design_patterns.unix.robustness module

class MOAL.software_engineering.problem_solving.design_patterns.unix.robustness.BasicCalculator[source]

All methods here have type checking in place so that bad inputs are automatically handled without throwing an error. This allows the behavior to be piped, etc, without any fatal error in behavior.

add(nums)[source]
div(nums)[source]
mult(nums)[source]
sub(num, subtrahend)[source]
class MOAL.software_engineering.problem_solving.design_patterns.unix.robustness.BasicCalculatorAlternate[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.unix.robustness.BasicCalculator

Another way to achieve this is to use kwargs with expected defaults, but this uses required args as kwargs, which are typically optional, and therefore not recommended.

add(nums=[])[source]
div(nums=[])[source]
mult(nums=[])[source]
sub(num=1, subtrahend=0)[source]