Question

Need help with understanding these topics as soon as possible will give thumbs up

These topics are based on python and software engineering

Topics from Exercises in Programming Style:

– The input, output, and behavior of and code for the program calculating term frequency

– The way in which a programming style emerges from a system’s design constraints

– The benefits and drawbacks associated with using styles during software engineering

– How different programming styles support and/or limit various software testing methods

– The constraints and Python code associated with the following programming styles:

∗ Monolithic

∗ Cookbook

∗ Pipeline

∗ Kick Forward

'∗ Things

Answer 1

STYLES

The different styles are grouped together into nine categories. Here is a description of the categories and the styles:

Historical. The first program in this category has the constraints of very little memory, and no identifiers. There is only memory, addressable with numbers. The result is a program that in many ways looks like assembler. The second style has a data stack, and all operations are done over data on the stack

Basic Styles. There are three styles here that show how programming has developed. The first style is Monolithic, where the program is not sub-divided in functions. Instead, the logic is just in one long sequence of statements. In the next style, the logic is divided into functions, but all functions operate on shared global variables. In the third style, called Pipeline, the functions don’t communicate using global data. Instead, they receive input and produce output. The program then becomes a long chain of function calls. This section also contains Code Golf, where the emphasis is on short and compact programs (in this case using libraries to achieve the goal).

Function Composition. This section shows three different ways of connecting function calls together. The first uses recursion. The second uses a continuation-passing style, where each function is also given the next function that should be called. This resulting program is a bit hard to read because of this. The third illustrates the concept of a monad, and all function calls and resulting values are done through the monad, creating a calling pipeline.

Objects and Object Interactions. There are six styles here. The first four are variations on regular object orientation, going from a normal object oriented program and one with abstract classes, to examples of how object orientation can be implemented (for example, how you find the method to call, and how the methods of an object are stored). Then there is an example of where you register for a callback, and a version with infrastructure for publish and subscribe.

Reflection and Metaprogramming. The theme here is programs accessing and changing themselves as they execute. The first example of this style uses introspection (inspect.stack() in Python) to check the calling function name. The second uses exec/eval to build functions from strings containing Python code. The third example uses Python decorators to show how profiling of functions can be done, i.e. Aspect Oriented Programming (the author is one of the creators of AOP). The final program is an example of a plugin architecture, where functions from external files are brought in via a config file.

Adversity. Here, various error handling strategies are showcased. In the first example, when an error is encountered, an attempt is made to continue with a “reasonable” default value. The next throws an exception on every error, and the third also throws exceptions, but tries to handle the errors at a higher level. There is a good discussion on the pros and cons of these strategies, and how it is easier or harder to implement, depending on if the language supports exceptions.

Data-Centric. In this section, the data, rather than the program behavior, is in focus. The next style emulates a spreadsheet, where changed values trigger recalculation of dependent values. The final example works on data available as a stream (as opposed to getting the complete data at the beginning). In other words, the data is “pulled” by the sink, not pushed from the source. This is solved nicely with generators (using yield) in Python.

Concurrency. This parts starts with one of my favorite paradigms, actors. Different threads send and receive messages to solve the task, and there is no shared memory between them. The downside of this example is that it is quite hard to follow the program flow. The next three examples use data spaces and map reduce (in two variations) to partition the task and then collect the results

Interactivity. The final two examples allow for interactive usage. The first is an MVC (Model View Controller) version, although the view simply prints to the console (no GUI). The second is a REST solution, in the purest form, meaning that at each interaction, the next allowed actions are always presented to be selected from. Both these examples brought home the key points really well.

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.A monolithic application is self-contained, and independent from other computing applications.

In software engineering, a monolithic application describes a software application which is designed without modularity. Modularity is desirable, in general, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement.

Pipeline

Pipeline   style, would recognize it as Functional Programming.Larger problem is decomposed using functional abstraction. Functions take input, and produce output.No shared state between functions.The larger problem is solved by composing functions one after the other, in a pipeline.

Cookbook

Cookbook style, probably know it as Procedural Programming.No long jumps.Complexity of control flow tamed by dividing the large problem into smaller units using procedural abstraction.Procedures may share state in the form of global variables.The large problem is solved by applying the procedures, one after the other, that change, or add to, the shared state.

Things

Programming style reflects the personality of the programmer, the depth of his experience and specialized knowledge. It's more about the art of decomposition of programs (for example defensive programming style enforces certain modules like logging module) and special "paranoid" treatment of anything that has a return code. It as about about knowledge of unique for a given domain algorithms. Lexical or syntactic elements of style should be with automatically using beautifier. In other words 90% of knowledge which went into writing a particular program is implicit and as such elements of style used difficult to deduct from the code. That's why the best (and largely outdated) book about programming style uses examples to explain particular rule and how to apply it to the problems.

Kick Forward

this style as Continuation-Passing Style, or CPS for short.All the constraints from the Pipeline style.Each function takes an additional parameter, usually the last, which is another function.That function parameter is applied at the end of the current function.That function parameter is given, as input, what would be the output of the current function.The larger problem is solved as a pipeline of functions, but where the next function to be applied is given as parameter to the current function