Python Design - Revision history

NickPGSmith: 3 revisions imported

2024-05-08T04:53:41Z

3 revisions imported

← Older revision		Revision as of 04:53, 8 May 2024
(No difference)

NickPGSmith: /* Protocols */

2023-12-16T13:23:43Z

Protocols

← Older revision		Revision as of 13:23, 16 December 2023
Line 30:		Line 30:
	* Classes derived from Protcol define an interface with their attributes		* Classes derived from Protcol define an interface with their attributes
	* Duck typing means another type of object that has at least the same attributes as the interface can be passed to it		* Duck typing means another type of object that has at least the same attributes as the interface can be passed to it
			* Alternative to subclassing

NickPGSmith: /* Protocols */

2023-12-16T13:22:49Z

Protocols

← Older revision		Revision as of 13:22, 16 December 2023
Line 28:		Line 28:
	== Protocols ==		== Protocols ==

	?		* Classes derived from Protcol define an interface with their attributes
			* Duck typing means another type of object that has at least the same attributes as the interface can be passed to it

NickPGSmith: Created page with "== Functions == * Do one thing and do it well ** Should be at the same level of abstraction * Command-query separation: should either make some change or return data * Only request information it needs * Keep the number of paramters minimal ** An indication of how focused the function is * Don't create an use an object in the same place ** Use dependency injection * Don't use flag arguments ** can mean the funcrion should be two distinct functions to handle each case *..."

2023-12-16T12:37:49Z

Created page with "== Functions == * Do one thing and do it well ** Should be at the same level of abstraction * Command-query separation: should either make some change or return data * Only request information it needs * Keep the number of paramters minimal ** An indication of how focused the function is * Don't create an use an object in the same place ** Use dependency injection * Don't use flag arguments ** can mean the funcrion should be two distinct functions to handle each case *..."

New page

== Functions ==

* Do one thing and do it well
** Should be at the same level of abstraction
* Command-query separation: should either make some change or return data
* Only request information it needs
* Keep the number of paramters minimal
** An indication of how focused the function is
* Don't create an use an object in the same place
** Use dependency injection
* Don't use flag arguments
** can mean the funcrion should be two distinct functions to handle each case
* Functions are objects, so can be passed around

== Classes ==

* Keep classes small
** Typically either data focused (structure) or behaviour focussed (methods)
* Make classes east to use as possible
** eg properties instead of methods
** use @property, @cached_property or @lru_cache
** __repr__ for developers, __str__ for users
* Use Dependency Injection
** Don't create objects in the class, pass as arguments
* Make sure a class is really needed
** Classes are useful for multiple instances. If only one is needed, could be just a module function.

== Protocols ==

?