These are my notes on Erik Meijer, Functional Programming, C9 MSDN, 2008 technical interview.

Object Oriented Programming is State plus Behavior. Haskell and functional programming are pure languages. Programming languages are classified in useful, pure, and honest. Honesty is when type systems tells you exactly what is going on; types tell you what the system will do. Dynamic programming languages do not mention types and so they are honest, some of them make money. Haskell enables side effects but is honest about them, if you call drinkCaffe function, the cup will be empty after the end of the execution.

Dishonest: int f ();
returns int, but it can read a changing int.
In Haskell: IO <int> f (); declares side effect

In Java signatures specify which exceptions can be thrown, int f (…) throws … ; exceptions in some sense are side effects.

Haskell is pure and honest.

Functional programming
Functional programming is programming using mathematical functions. Popular explanation of functional programming is programming with no side effects, and the letter explanation is wrong.

The same arguments return the same result.

Honest:
int f (int x) {
return x+5;
}

Dishonest- returns different int every time
int f (int x) {
return x + Random();
}

Side effects: Lets remove side effects: Random, Exceptions, Threads, IO. So it is like muted. Up to the extreme it became useless. Early Haskell was the same.

Haskell does:
Argument -> (World -> Result, World)
Argument -> IO Result

I can not copy the world, someone can be observing it. The way you compute is by using IO (reader or write, ot both).

Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern, 2004 has proposed the concept of Dependency Injection. Despite the fact that Inversion of Control or more accurately termed Dependency Injection is explained in Object-Oriented paradigms (dependencies between classes), I believe that dependency injection can be as well used in non-OO (i.e. C) programs as in OO.

Inversion of Control (IoC) in procedures and functions in procedural programming languages can give big flexibility and re-usability of the code. Handling dependency injection in such a way to propose as few as possible code rewriting in result of updates in a reasonable price of code readability and powerful procedure and function white-box testing. Handling dependency injection will improve Single Responsibility Principle (SRP)-give each function/procedure (class in OOP) just one reason to change; and “Reason to change” == “responsibility”.

Handling dependency injection is proposed here by presenting each and every global variable and function/procedure call in the list of arguments of the concrete function/procedure.

Example (used The Function Pointer Tutorials):

// Pointer to global function. Using TYPEDEF is not a requirement.
typedef int (*ptXFunction) ();

int globalFunc () {
// code ;
}

void func (/* arguments */, ptXFunction globalFunc = &globalFunc) {
// code ;
// calling the global function int globalFunc () through its local function pointer globalFunc
}

Walid Taha, Resource Aware Programming, Google Tech Talks, January 22, 2007 is a remarkable video in YouTube an hour and 10 minutes in length about MetaOCaml, which let me touch a dream of a language I was dreaming for-flexible abstraction design in order to control all the resources (including computation space and time), and reactive functional programming including separation of stages of computation (multi-stage) which separation enables more efficient calculation on the base how a parameter of calculation is accessible. I have understood that programming in MetaOCaml is in mathematical form by using mostly recursive expressions, the letter expression gives more certainty of the code, after that the code is translated in C and everything now on is clear.

With an aim to promote knowledge on the above, I have made a transcript of the introduction of Taha (~10 min.). I was facing common problem domains in G. Garabedyan, Data Flow Processing, eventBased Algorithms and Data, 2008 and particularly in G. Garabedyan, eventBased Framework, 2009.

Thank you very much, Chris. It is a pleasure to be here today and the goal is to tell you all about the interesting research in programming language that we are doing at Brice and I will avoid getting into technical details and theorems, and formalisms and so on, and focus on using various examples and languages that we have built and intuitions and motivation from the kinds of problems that we would like to see our languages being used to solve.

So, to get started, I would like to say that one of the key things to building better programming languages is design abstractions that would help us build the programs that we want to write. Abstractions like arrays, functions, objects, modules and so on, all of these are examples of things that we have seen before in different application domains like Hi-Performance computing or Databases, for example, where they proven and successful. And there are a lot of standard examples of these abstractions that we know pretty well. In a lot of cases they do a very simple thing which is to make our programs shorter and more manageable. Often, they also make it easier to reuse, so when we have solved something a particular program before, it is easy to reuse the solution to solve the new problem that we have seen and if they are designed carefully they also help verify and reason about the correctness of our programs. And in particular reasoning is something that we are very interested in and when we are able to do that what we get in the end of the day is a guarantee about our program, often through the language that we have created or type system or curricle, get a guarantee about our program and the guarantee says a specific bad thing wouldn’t happen at run time. So you build this program and it looks like it is supposed to be doing a certain thing but also interested in knowing there are other bad things that it is not gonna do. Of course, ultimately, if we take verification all the way when we go the next step and would be sure that it is doing what we wanted to do. But a very practical thing is to have at least a guarantee about certain bad things not happening and here we are interested in classic things like buffer overflows, run time errors and so on. There is very interact interplay between design of abstractions and what we can do in terms of reasoning about our programs afterwords.

Alright, so the last slide is supposed to be a motivation for the design abstraction that we get in high-level programming languages. High-level programming languages to me are things like O’Caml, ML, Haskel and all these very high-level programming languages that we know about. Now if we go to the real world and look at programs that people are writing today we will find that they look like the controllers that run inside our car, all kinds of medical applications, and health services applications, robotics applications, they run very important control software that determines what function the rest of this metal does and the same thing for defense applications. So, what languages do people use to write these pieces of software, these are things like C and C++ for the most part and for very interested in performance there are big computational components of the system you might find that they are written in FORTRAN. 20 or 40 years ago these were high-level languages, today they are not what we will consider high-level languages based on the new innovations that we have seen over the last 20-30 years. So, why is it the case that for a lot of applications in software that has been written today we do not see the high level languages being used. My piece is here that basically the same time that we use this more advanced abstractions we also giving up control over firmly important low-level details. And in a lot of cases especially for embedded and real-time systems, a lot of times the benefits that we get from high-level abstractions but the programmer that is responsible for building the system at the end of the day it can not really give up the control of the low-level resources. Cause the programmer or system designer is the person that responsible for achieving this real time guarantees or various performance characteristics that the system must have. There are a lot of examples of abstractions that we could use to illustrate this point, the simplest one is may be automatic memory management. Automatic memory management allows us to thing of dynamic data structures at a higher level than the model that we allocate data explicitly and deallocated at the end of the day. And we get this huge advantage with dynamic memory management of safety because we have only allocate operations and know explicit the allocations and we do not have to worry about dangling pointers which are big safety problem and languages that do not have dynamic memory management. Get a very nice abstraction from dynamic memory management at the same time this means that we are relinquish control of when things get allocated or also when things get deallocated. In addition, because the system has to do more work for us and we do not necessarily know when this work will be done, we may be doing a critical computation that needs to be done quickly for this particular application and the garbage collector must run and suddenly we have no idea how long it is gonna take for this computation to finish. This is just one example of many instances where we care not only about the functionality of our input and output behavior of our program in terms of a standard input/output behavior, but we care also about the resources that are being consumed, the basic resources being time and space needed for the computations but all kinds of notions of resources that depend on the particular kind of problem that we are solving using the software artifact that we are trying to build. The question that we are interested in What abstractions can be used to allow people to build the programs that they want to build when on the same time get guarantees about resources of these for?

The goal of our research is basically to have be able to produce languages to produce our expressive as possible to the programmer so that we can still structure our problems as clearly as possible and reuse the solutions that we have before, the same time just side by side to this explicitness we want to have guarantees that are stronger as possible about the programs that we write. Essentially not let the mechanisms for let guarantees and better properties for our programs getting the way to be able to write programs and in a way that it is natural as possible. The way we are gonna do this, there are essentially 3 components to our approach. The first is called multi-stage programming and essentially this is the way to separate the design that is captured by our program from the actual implementation that comes out of the design at the end of the day. And one way to thing of this is that our designs are gonna generate the programs that we need at the end of the day. Another aspect especially important for real time and embedded systems is to incorporate a treatment of reactivity or a mechanism that allows us write programs naturally where this programs are gonna interact with the stream of inputs coming from the outside and producing a stream of outputs back to the environment. And finally, using advanced type system techniques and particular linear types and indexed types, to be able to express much finer property is that in a typical type system or a traditional type system would let us do.

So, that plan for the rest of the talk, we are gonna start with a sort of characteristic of a traditional computing called batch computing. All the inputs are available in one shot or computation for the program that we want to build. And the output comes only after we have all the inputs that are needed. So we are gonna go extend this module in one dimension and here what we have is some of the inputs arriving early and we actually use that as soon as they arrive to use some computation and produce and new specialized computation. The specialized computation can then receive the rest of the input and produce the output more efficiently. And we can even later see how this separation is also useful for getting stronger guarantees about the final phase of the computation. So the other almost orthogonal dimension is reactivity and we will talk briefly about what this means and what programs written for this model computation would look like. And the work that was done to make sure that we have stronger guarantees about a reactive programming model and in some sense we are gonna be combining these two approaches at the end of the day that is essentially the automate goal of research that we are doing.

Resources:

1. (PDF) Presentation of Walid Taha on Resource-Aware Programming (RAP)

2. (HTML) Course description of Resource Aware Programming at Computer Science, Rice University

60 Design Heuristics
Object-oriented Design Heuristics
By Arthur J. Riel

Classes and Objects: All data should be hidden within its class (Only private attributes; and Not even protected!).  Protected methods are allowed. Users of a class must be dependent on its public interface, but a class should not be dependent on its users (Somebody calls my method, and I’m dependent on the other’s behaviour or state). Minimize the number of messages in the protocol of a class (Example: SetMinimumValue(int aValue); SetMaximimumValue(int aValue);, But SetLimits(int minValue, int maxValue)). Implement a minimal public interface which all classes understand (E.g. operations such as copy (deep versus shallow), equality testing, pretty printing, parsing from a ASCII description, etc). Do not put implementation details into the public interface of a class (such as common-code private functions, in Example: Class CBill generates a reference number when the object is created, but not any other time). Do not clutter the public interface of a class with things that users of that class are not able to use or are not interested
in using (Mixture of public and private methods that must be called in a certain order; Methods with parameters, values of which are not available to other classes). Classes should only exhibit nil or export coupling with other classes ( i.e. a class should only use operations in the public interface of another class or have nothing to do with that class; No friends or at least avoid them as much as possible). A class should capture one and only one key abstraction (One simple thing, major responsibility). Keep related data and behavior in one place (Classes methods modify data that belongs to that class). Spin off non-related information into another class (i.e. non-communicating behavior). Be sure the abstraction that you model are classes and not simply the roles objects play (Objects may switch roles runtime; State may indicate role).

Topologies of Object-Oriented Applications: Distribute system intelligence horizontally as uniformly as possible (I.e. the top level classes in a design should share the work uniformly).Do not create god classes/objects in your system (Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem; Does this name indicate a class that really contains too much responsibilities?). Beware of classes that have many accessor methods defined in their public interface (Many of them imply that related data and behavior are not being kept in one place; Accessor methods access other objects or too much data that is encapsulated in this class). Beware of classes which have too much  non-communicating behavior (methods which operate on a proper subset of the data members of a class; God classes often exhibit lots of noncommunicating behavior). Applications which consist of an object oriented model interacting with a user interface (the model should never be dependent on the interface; The interface should be dependent on the model). Model the real world whenever possible (This heuristic is often violated for reasons of system, intelligence distribution, avoidance of god classes, and the keeping of related data and behavior in one place). Eliminate irrelevant classes from your design and Eliminate classes that are outside the system. Do not turn an operation into a class (Be suspicious of any class whose name is a verb or derived from a verb; Especially those which have only one piece of meaningful behavior (i.e. do not count sets, gets, and prints); Ask if that piece of meaningful behavior needs to be migrated to some existing or undiscovered class). Agent classes are often placed in the analysis model of an application (During design time, many agents are found to be irrelevant and should be removed).

The Relationships Between Classes and Objects: Minimize the number of classes with which another class collaborates (The less connections the better; E.g. Facade design pattern). Minimize the number of message sends between a class and its collaborator (By defining fewer methods, for example). Minimize the amount of collaboration between a class and its collaborator (I.e. the number of different messages sent). Minimize fanout in a class (I.e. the product of the number of messages defined by the class and the messages they send). If a class contains objects of another class (then the containing class should be sending messages to the contained objects, i.e. the containment relationship should always imply a uses relationship). Most of the methods defined on a class should be using most of the data members most of the time. Classes should not contain more objects than a developer can fit in his or her short term memory (A favorite value for this number is six). Distribute system intelligence vertically down narrow and deep  containment hierarchies. When implementing semantic constraints (It is best to implement them in terms of the class definition; Often this will lead to increasing number of classes in which case the constraint must be implemented in the behavior of the class, usually, but not necessarily, in the constructor). When implementing semantic constraints in the constructor of a class (place the constraint test in the constructor as far down a containment hierarchy as the domain allows). The semantic information on which a constraint is based (is best placed in a central third -party object when that information is volatile). The semantic information on which a constraint is based (is best decentralized among the classes involved in the constraint when that information is stable). A class must know what it contains, but it should never know who contains it (Some design patterns break this rule, for example, Chain of Responsibility (used often with Composite)). Objects which share lexical scope (i.e. those contained in the same containing class; should not have uses relationships between them).

The Inheritance Relationship: Inheritance should only be used to model a specialization hierarchy. Derived classes must have knowledge of their base class by definition (but base classes should not know anything about their derived classes; State pattern). All data in a base class should be private (i.e. do not use protected data). Theoretically, inheritance hierarchies should be deep, i.e. the deeper the better; Pragmatically, inheritance hierarchies should be no deeper than an average person can keep in their short term memory (A popular value for this depth is six). All abstract classes must be base classes; All base classes should be abstract classes. Factor the commonality (of data behavior, and/or interface); as high as possible in the inheritance hierarchy. If two or more classes only share common data (no common behavior) (then that common data should be placed in a class which will be contained by each sharing class). If two or more classes have common data and behavior (i.e. methods) (then those classes should each inherit from a common base class which captures those data and methods). If two or more classes only share common interface (i.e. messages, not methods) (then they should inherit from a common base class only if they will be used polymorphically). Explicit case analysis on the type of an object is usually an error (the designer should use polymorphism in most of these cases). Explicit case analysis on the value of an attribute is often an error (The class should be decomposed into an inheritance hierarchy where each value of the attribute is transformed into a derived class). Do not model the dynamic semantics of a class through the use of the inheritance relationship (An attempt to model dynamic semantics with a static semantic relationship will lead to a toggling of types at runtime). Do not turn objects of a class into derived classes of the class (Be very suspicious of any derived class for which there is only one instance). If you think you need to create new classes at runtime (take a step back and realize that what you are trying to create are objects; Now generalize these objects into a class). It should be illegal for a derived class to override a base class method with a NOP method (no-operation), I.e. a method which does nothing. Do not confuse optional containment with the need for inheritance (modelling optional containment with inheritance will lead to increasing number of classes). When building an inheritance hierarchy (try to construct reusable frameworks rather than reusable components).

Multiple Inheritance: If you have an example of multiple inheritance in your design (assume you have made a mistake and prove otherwise). Whenever there is inheritance in an object-oriented design ask yourself two questions 1) Am I a special type of the thing I’m inheriting from? And 2) Is the thing I’m inheriting from part of me?. Whenever you have found a multiple inheritance relationship in a objectoriented design (be sure that no base class is actually a derived class of another base class, i.e. accidental multiple inheritance).

The Association Relationship: When given a choice in an objectoriented design between a containment relationship and an association relationship, choose the containment relationship.

Class Specific Data and Behavior: Do not use global data or functions to perform bookkeeping information on the objects of a class (class variables or methods should be used instead).

Physical Object-Oriented Design: Object-oriented designers should never allow physical design criteria to corrupt their logical designs (However, very often physical design criteria is used in the decision making process at logical design time). Do not change the state of an object without going through its public interface (No public/protected data members, No friends).

Dino Esposito in May 14, 2009 have presented a lecture on Design Patterns, Refactoring and Sane Principles in Days of Microsoft’2009 in Faculty of Mathematics and Informatics, University of Sofia, Bulgaria, which I have attended.

These are my notes from the lecture:

Bad software design… deterioration in design. Bad software is hard to maintain and evolve. Complete redesign may not be an option. STOP at the first sign of deterioration.

Foundation of Software Design- Structured design (high cohesion; low coupling); and Separation of Concerns (modularity; information hiding). ClassA and ClassB are cohesive when changes to A have no repercussion on B. The problem is in the hidden dependencies, not in the public explicit (cohesion) dependencies.

Single Responsibility Principle (SRP)- give each class just one reason to change; and “Reason to change” == “responsibility”. In example: Invoice class does not have a responsibility to print itself.

Coupling: Level of dependency between 2 modules. ModuleA and ModuleB are coupled when changes to A force you to make changes on B.

Achieve stable constructed interfaces. ModuleA does not need to know internals of B.

Separation of Concerns (since 1974). Concern == feature of system. Taking care of each of the concerns: for each one concern, other concerns are irrelevant. Hiding implementation of behavior.

Object Oriented Design: 1st principle- Find pertinent object; 2nd principle- Program to an interface.

OOD is one paradigm. Nouns in requirements document are best candidates for classes, verbs- for functions (methods in classes).

Difference between inheritance and composition: inheritance enables polymorphism in parralel to composition, in general.

Advanced principles: 1) Open/Close; 2) Substitution; 3) Dependency Inversion. Open/Close- open for extension, close for modification; Substitution- subclasses should be substitutable for their base classes; Dependency Inversion- Low-level modules injected into the high-level module (not invoked by). Thus inverting the control of flow. Various patterns: dependency injection; service locator.

Dino Esposito (http://weblogs.asp.net/despos/) is Microsoft Most Valuable Professional and is one of the world’s authorities on Web technology and software architecture. He writes articles covering topics such as AJAX, Silveright, software design and patterns. The event was sponsored by Kulov.net, Musala Soft, Microsoft and Faculty of Mathematics and Inforamtics, University of Sofia, Bulgaria. The lecture was Chapter 3 of his book Microsoft® .NET: Architecting Applications for the Enterprise (PRO-Developer).