It is not oft that programming styles are much discussed, perhaps for the typical judgements that aspirants of logic and rationality have of their more ambiguous counterparts. However, due to the very natures of the mind, whose ambiguous processes contrive the substance of thought, less concrete remedies can have definite if not significant effects upon general efficiency. Code readability aside, I seek to provide an alternative, procedural, functional style to the quagmire that can become of object orientated paradigms.
While the abstraction to objects can be beneficial, its reliance upon mutable state soon renders several problems: that of code reusability and code complexity. Methods that mutate their class objects do not produce exact results upon the second iteration, the effects of which forces classes and methods to be executed in order. And speak not of inheritance, whose attempts at code reusability further compounds complexity; programmers who have the idiosyncrasy of organizing their classes by hierarchy must first brave the relationships of mutable states, only, upon later revision, realize that their god classes no longer generalize onto new instances, thus forcing a reordering of the entire class hierarchy, or must contrive to break their organization by adding clinger classes.
The python programming language is exempt from much of the scorn for object orientated programming languages due to its flexibility; whilst Java classes are integral to the language, python offers programming in the procedural style. Perhaps key to this style is the construction of semantically ‘pure functions’, likened to their namesake in mathematics, with reproducible x y mapping. Although I would be ill-advised to use lambda calculus in python, replicatible functional definitions can still mirror the functional paradigm ideal. One can replicate functional characteristics with the transformation of data through a ‘pure function’ pipeline, in sequential form as found in the procedural style, classes can form this pipeline in total encapsulation, quite unlike the quasi obfuscations of inheritance. While encapsulation, to conclude, is an attempt of a fix for mutable state, not a feature. Use classes in instances where mutable state may simplify or aid in program readability, or as an organizer of sorts, distinct from the object abstraction.
The trouble with objects is ironically, their ambiguity in abstraction. While typical references to abstraction in academia refers to reduction, simplification, or generalization, this form of abstraction rallies higher order data to the physical in a mode of thought that is neither a reduction, a simplification or a generalization. To paraphrase, programmers must necessitate a philosophical streak as they ponder upon the nature of objects. Programmers who have little trouble modeling those that are closer to the physical must contend with producing a generalizable model which transfers already highly abstracted data to a form which one ordinarily may associate with matter.
The object orientated paradigm suffers under some disillusionments as one ponders upon the true utility of classes, which leads to some undesirable conclusions, namely, the efficiency of the abstraction, the questionable method of encapsulation and the contrivance that is inheritance. However, one can greatly remedy the unfortunate ratio of complexity, in accordance with Occam's razor, when one treats objects not as a school of thought, but as another tool altering program structure.
An example of a god class and child class. Note that state is mutable between god class objects and implementations of the child class:
class Nope:
confusion = 100
mania = 50
resolution = 10
cringe = 100
adversity = 70
depression = 60
anger = 80
some_choice_words = ['why', 'am', 'I', 'doing', 'this']
some_other_words = ['tu', 'est', 'une', 'petite', 'turd']
insults = [['The sight of thy body irritates my eyes.'],
['thou tottering boil-brained strumpet!'],
['thou very declinations is of utmost futility.'],
['Thou art a very ragged wart.']]
def cry(self):
if self.resolution < 10 or self.depression > 50:
print([i for i in self.some_choice_words])
self.resolution += 20
self.depression -= 10
def rage(self):
if self.anger > 30:
print([i for i in self.insults])
class Happiness(Nope):
def happy(self):
super(Happiness, self).cry()
print(self.depression)
>> h = Happiness()
>> h.happy()
… ['why', 'am', 'I', 'doing', 'this']
… 50
Comments