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
-
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.
-
class
MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_cohesion.
InputsController
[source]¶ Grouping based on logical category of functionality or type
-
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.
-
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
-
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.
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
-
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
-
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.
-
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]¶
-
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)¶
-
static
-
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.
-
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.
MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_infohiding module¶
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]¶ -
-
__str__
()¶
-
-
class
MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.
NerveCell
[source]¶ -
-
__str__
()¶
-
-
class
MOAL.software_engineering.problem_solving.design_patterns.grasp.pattern_polymorphism.
SkinCell
[source]¶ -
-
__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.
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.
-
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]¶
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
-
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)¶
-