MOAL.software_engineering.problem_solving.design_patterns.grasp package

Submodules

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion module

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.DEBUG = False

en.wikipedia.org/wiki/Cohesion_(computer_science) For these examples, ‘module’ is actually considered a class.

NOTE: some of these classes access properties or methods that do not exist. Making it fully compliant is irrelevant to the scope of this project. In some cases, the examples will work 100%, but some don’t.

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.FileOpener[source]

Grouping based on procedure: open -> check perms -> read | error

__init__()[source]
_can_read(user)[source]
_can_write(user)[source]
open(user, filename)[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.HandleUser[source]

Grouping based on operating on the same piece or type of data.

create(user_id, **data)[source]
delete(user_id)[source]
read(user_id, **data)[source]
update(user_id, **data)[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.InputsController[source]

Grouping based on logical category of functionality or type

handle_keyboard(character)[source]
handle_mouse(x, y)[source]
handle_other(**kwargs)[source]
register_input(name, **kwargs)[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.Lexer(wrapper_start, wrapper_end, token_start, token_end)[source]

Bases: object

Grouping based on specific functions that contribute to a single, well-defined goal.

__init__(wrapper_start, wrapper_end, token_start, token_end)[source]
_fmt(token, k, count)[source]
_fmt_wrapper()[source]
tokenize(string)[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.NaiveXMLLexer[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.Lexer

__init__()
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.ProcessUserData[source]

Grouping based on procedural and temporal: process -> _process -> handle -> error | success

add_error(msg)[source]
handle_file()[source]
process(**kwargs)[source]
process_data()[source]
success(msg)[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.SExpressionLexer[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.Lexer

__init__()
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.UnixPipe[source]

Grouping based on the notion that outputs to one function become the input to another, when combined in sequence. This is the crux of the UNIX philosophy.

__init__()[source]
grep(keyword)[source]
ls()[source]
save(filename)[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.Utilities[source]

BAD, BAD, BAD! Grouping based on circumstance or coincidence.

add_numbers(nums)[source]
format_thing(stuff)[source]
get_fullname(user)[source]
MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion._print(text, title, thing)[source]

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller module

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller.Controller(*args, **kwargs)[source]

Bases: object

en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Controller

__init__(*args, **kwargs)[source]
receive(eventname, **data)[source]
send(eventname, data)[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller.CustomerController(*args, **kwargs)[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller.Controller

MVC Style

_create_user(**kwargs)[source]
_delete_user(name)[source]
_edit_user(**kwargs)[source]
_read_user(**kwargs)[source]
send(event, **kwargs)[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller.DBConnectionError[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller.DBReadError[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller.InputController[source]
__init__()
_event(pos)
get_position()
push(button_name)

Another design principle here is indirection - the buttons should not be mapped to their internal states, as we might want to change button configurations for different users.

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller.InvalidEvent[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_controller.MockDBAdapter(*args, **kwargs)[source]
__init__(*args, **kwargs)
commit()
read(key)
rollback()
write(key, **kwargs)

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator module

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator.AbstractVehicle(name)[source]
__init__(name)[source]
__str__()[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator.Automobile(name)[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator.AbstractVehicle

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator.ClassFactory[source]
static make(name, instantiate=False)
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator.Plane(name)[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator.AbstractVehicle

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator.Train(name)[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_creator.AbstractVehicle

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_indirection module

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_indirection.Customer(name, details)[source]
__init__(name, details)
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_indirection.CustomerManager[source]

The customer manager acts as a layer of indirection to common operations that should not be cluttering up the actual customer object.

__delitem__(name)[source]
__init__()[source]
__setitem__(name, details)[source]
add(customer)[source]
add_balance(customer, amount)[source]
get_invoices()[source]
process_balances()[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_indirection.InvoiceManager[source]

The invoice manager is another potential source of indirection. The customer manager should not know much about invoices, except how to delegate them via indirection, to the invoice manager. Simply operations like adding and retrieving, should be all the users of this manager should know.

__init__()[source]
create(customer, amount)[source]
get_all()[source]

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_infohiding module

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_infohiding.Person(**kwargs)[source]
__init__(**kwargs)
_get_prop(prop)

Information for accessing properties directly is hidden under the private method.

get_full_name()

The public ‘interface’ to getting name values.

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism module

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.BlobOfMatter[source]

Bases: object

__str__()
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.BrainCell[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.UndifferentiatedCell

__str__()
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.NerveCell[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.UndifferentiatedCell

__str__()
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.SkinCell[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.UndifferentiatedCell

__str__()
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.UndifferentiatedCell[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.BlobOfMatter

Each child class implements a __str__ method (beyond the native python) version, so each name is the same, but there are many different versions.

__str__()[source]

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_protected_variation module

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_protected_variation.ConnectionMixin[source]

Abstracts the notion of a document across all database types. This ones’ is a weird experimentation.

__init__()[source]
get(pk)[source]
set_adapter(name)[source]
MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_protected_variation.DEBUG = False

Protected variation sounds a lot like indirection and information hiding, but it is tied to the idea of consolidating disparate objects/resources.

In this sense, it acts more like the general idea of abstraction, because A. it does not necessarily (though often may, tangentially) provide mechanisms for pluggable behavior, and B. it does not necessarily hide all access to information. What it does do, is group disparate systems into one single entity, to protect the variation and thus remove coupling to specific implementations.

In this sense, it feels a lot like an adapter, but it’s more like a multi-adapter in that sense, so it’s not quite the same.

My ultimate conclusion is that these other similar design patterns are effectively subclasses of this idea, which is the most abstract version.

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_protected_variation.Document[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_protected_variation.ConnectionMixin

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_protected_variation.MongoAdapter[source]
collections()
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_protected_variation.PostgresSQLAdapter[source]
commit()
conn()
cursor()
execute(sql)

MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_pure_fabrication module

class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_pure_fabrication.GridMonitorService(grid)[source]

This monitor service acts as an intermediary for handling db and object related functionality, and can be used to continually add more utilities that are related to the single entity, but that shouldn’t be stored directly on it.

It can be though of as a service-like layer of indirection:

entity <——> entity_service <——> data_store

__init__(grid)[source]
check_status()[source]
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_pure_fabrication.LightGrid[source]
__init__()
__setitem__(id, coords)
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_pure_fabrication.LightMonitor(coords)[source]

Bases: MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_pure_fabrication.Monitor

__init__(coords)
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_pure_fabrication.Monitor[source]
off()
on()
status()
class MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_pure_fabrication.MonitorDB[source]
__init__()
__setitem__(id, data)