Citations in Web context now can be machine-readable

Creating a common language for describing in machine-readable form citations in web is the goal of the Protocol for Web Description Resources (POWDER), released by World Wide Web Consortium. By using Powder’s specifications, a Web site can make claims about where information came from and how it can be used. [http://www.technologyreview.com/web/23355/page2/]

Similar approach can be implemented in Content management systems (CMS) and document revision (sub-)systems.

DevReach 2009, Bulgaria

I have attended DevReach’2009: Microsoft technologies at your reach (12-13 October).

Modeling: Here and Now by Chris Sells, Connecting to the Clouds: The Azure Services Platform by Luka Debeljak, From One Web Server to Two: Making the Leap by Richard Campbell, Being Productive with ASP.NET MVC by Hadi Hariri, SQL Server Intelligence by Remi Caron, Fun with Garbage Collection by Ed Musters at the first day of sessions of the conference. And the next day I have attended Practical Parallel Programming with Visual Studio 2010 by Tiberiu Covaci, SOLID Design Principles by Hadi Hariri, Building Data Visualization Applications with WPF by Tim Huckaby, Will It Blend? Building Websites with All Flavors of ASP.NET by Todd Anglin, SharePoint Web Part Development (Deep Dive) by Ed Musters, and The Daily Scrum by Stephen Forte & Remi Caron.

These are my notes listed by sessions:

Modeling: Here and Now There exist types of data models, 3 in count: graph (generally used for programming- behaviour), tree (generally used for transmission- interop), relational (generally used for storage- permanence). Re-factoring DB in VS is a very powerful feauture which requires only the schemas of the DB.

Connecting to the Clouds: The Azure Services Platform The vision of Microsoft was Software + Service which is applied in the Azure Services Platform. The Cloud is an additional platform, a hosted software platform, a shared infrastructure, it is virtualized and dynamic, and you pay as you use it. The Cloud is close to an infinite amount of computer power and is flexible. The Azure Platform consists of blobs, tables, and queus. Blobs is a file system with meta about the files where Web Apps are placed as executables. Tables are DB tables. Queus are tunels for application communication- Service Bus is suppposed to take place here. Nice whitepapers about Azure can be found at davidchappell.com.

From One Web Server to Two: Making the Leap The reason for adding web server is actually reliability. Configurations between web servers must be identical. Single affinity in network configuration refers to sending requests from on visitor IP always to one and the same server in the farm. The letter is important for web sessions saving. Single affinity increases the network traffic by 10%. Google says over 3 sec. for page loading makes you lose visitors.

Being Productive with ASP.NET MVC MVC is about Convention over Configuration assuming certain things. M (the model) is missing in APS.NET MVC, it is replaced by ViewModel and normally 1:1 ViewModel and View relation. One way to implement aspect-oriented programming is by action filters. For complex views (like homepage) the main view calls Controllers to render by pointing where to render their views in the first.

SOLID Design Principles – Single Responsibility Principle: the more we touch, the more bugs can born; A class should have only one reason to change. – Open Closed Principle: A class should be open for extension but closed for change; This is solved by polymorphism, and avoiding switch statements in general. – Liskov Substitution Principle: if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program. – Interface Segregation Principle: the interface is a contract and if you do not implement a function from an interface you are breaking the contract; Clients are supposed to depend on methods that they do not use. – Dependency Inversion Principle: Program to an Interface, not a Class; Use IoC containers. At objectmentor.com are many more principles.

The Daily Scrum In Harvard Business Review before 20 years the idea is first explained that people lose ‘relay race’ if work in issolation. Scrum is an agile process that focuses on communication. Expose problems fundamental to your organization and enable you to fix them earlier. Make small 2 week sprints ending with presenting everything to the client. This way making the client an active member of the team. Separate the basic job types in small things and work on small parts from all types in order to have a solution ready for presentation at the client.

I was able to have talks with a few speakers and present to them my visions which can be found in this blog, too. I have made few friendships with attendees, too. One of the greatest benefits was to meet live with attendees and presenters at the coffee breaks.

Context-powered (social wisdom of the crowd) tagging

When a registered user decides to tag something with some terms, the systems asks to compare shared tags between the new source and recently added such by the same user or by his friends. By friendship the system understand users with similar tagging of one material or friends through social networking service like Facebook, or both.

Tags are not simply statements like “This ‘url’ material is ‘tag-term1′, ‘tag-term1′ and ‘tag-term3′”, but are used as “This ‘url’ material is ‘tag-term’ more than ‘url-already-tagged1′, ‘url-alreday-tagged2′ and few than ‘url-already-tagged3′, ‘url-already-tagged4′”. Every tagging term can be used as a comparison between materials.

Presenting users with social encouraging analyzes of common understandings on topics and what their friends have tagged enables a unique way to make new friendships and understand more about your friends.

This way tags can become context-oriented and gain meaning with more of their usage like Semantic web RDF terms which are pre-defined by definition.

Browsing tagged content can give the system more about the characteristics of the user in relation with the registered users tagged the content and the friends of the letter. This gives an ultimate way to determine which ad to present.

I have red a paper on Foundations and Technologies of The Semantic Web in 5th National Student Scientific-Technical Conference in city of Sozopol (Bulgaria, Europe), 27-30 September, 2009. On the letter I have presented a comparison between semantic web and the so-called wisdom of the crowd stuff.

This was inspired by the answers I have received to my questions in this event.

Norm Judah, CTO Microsoft Worldwide Services & IT, lecture in Bulgaria

I have attended a lecture of Norm Judah, CTO Microsoft Worldwide Services & IT, in University of Sofia (SU), Bulgaria organized by Microsoft Bulgaria and IT Academy to Faculty of Mathematics and Informatics SU.

All of these are my views according to the notes I have take.

The lecture was titled ‘Computing and Colaboration’ with sub-title ‘The Next Wave’ and was about what we do to plan future products.

Norm have presented the understanding of MS about the 3 SCREENS- TV, mobile phone, PC- and how the users want to do one and the same things on all these screens. 3 Screens and the Cloud slide lists the MS services WindowsLive, XBOXLive, and Zune and explains how content must look the same way on all these screens.

N. Judah have explained to us how avatars in XBOX came as an idea. And have concluded that taking things from how people interact in business and placing them in gaming might be successful.

Therefore, Norm concluded, knowing the intent and personality gives how the user behaves with the system.

We have seen the understanding of MS about extending into the Cloud. A diagram from traditional datacenter, to virtual datacenter, to private cloud, up to public cloud of capacity on demand and global research illustrates this. It challenges Software + Services architecture.

We have watched a movie about MS and Ford product of voice controlled car assistant that can tell you, the driver, where is the nearest coffee bar and how to reach it or which road to take to avoid traffic jams, or to choose music in accordance to the your criteria and so on.

We have got a historical review of the last 20 years. Bill Gates have wrote papers before two decades predicting that we will have information on our fingertips within next decades.

The presentation concluded on the behalf of the video that there are different things to do with the Cloud:

1. Move to the Cloud (BPOS, CMS, Live meeting)
2. Use the Cloud (Windows Azure, .NET Services, SQL Azure)
3. Be the Cloud (SaaS Provider, SOA, ESB)

Microsoft Azure platform contains: Windows Azure, .NET Services, and SQL Azure.

Later we have watched another interesting video ‘A glimpse ahead’ and N. Judah pointed www.officelabs.com address from where we can find other such videos. I have got excited about the timeline of communication taken from the Cloud in the video.

At the end of the presentation we have a few minutes to ask questions. I was not able to ask my questions, but have succeeded to ask a guy from the staff of Judah what I was interested and this is what I receive as an answers.

1. About Semantic Web in the Cloud? Tim Berners-Lee have initiated lobbying usage of machine understandable content and services (See Resource Description Framework) back in 2001. MS Research has no video in relation with the letter in Channel 9 MSDN. Term-based and HTML links, and tag-based (wisdom of the crowd) powered search technologies are not context oriented as Semantic web technologies. Do you apply A.I. technologies over semantic web?
2. Social networking as a Cloud computing way to coordinate people who are with shared goals? MyBO (my.barackobama.com) have got over a million registered users which with clever coordination practices through the system have helped a lot in making Barack Obama the present President of U.S. In Bulgaria using Facebook technologies of Events and Groups have been organized protests in front of the National Assembly.

1) Microsoft uses the technology of Semantic web but does not share/ publish a lot of schemas. The video that you have watched about MS and Ford car assistant makes many and complex semantic web requests to Bing in order to tell the driver which road to take. We do not do AI, we do voice recognition which I will not call AI. Microsoft does not see semantic web as the next web.

2) Microsoft has a big vision about social networking in the next 10 years. MS have created the advertising system of Facebook. We scan the database of Twitter to see if users have some new features in Bing which is in Beta version for now.

It was an excellent opportunity to see how Microsoft thinks.

Semantic Web

I like the above interview and I have decided to write down the foundations of Semantic web according to it as a struggle to make the first popular.

http://se-radio.net/podcast/2008-11/episode-116-semantic-web-jim-hendler
Software Engineering Radio Episode 116: The Semantic Web with Jim Hendler

We have spent a lot of our times in thinking of very fast ways to explain Semantic web and the best I like is:
Right now, if I have a document, I can put it on the web and instant point to any other document with a simple link. But if I have a database or a spreadsheet I can not put that on the web and have it point another database or spreadsheet.
So, the sense is figuring out what is the database and the infrastructure by which data and definitional information can comes to the web rather than these documents is the heart of the Semantic web.

Web for machines, software, programs:
The key concept is right now the information on the web is primarily described for human inns, but if I am using data or something like that it is very hard to describe that for human use, because what I meant to do is aggregated, collated, queried, all things that pure happen back behind somewhere in the infrastructure, than when I present it to the human it is going to look like a table or a text or a web site, so it is really about building a new infrastructure for the web, to make far more the data work together and of course that will require more machines and machine integration things.

Three things you need:
1. Data format that can include links- If I need to integrate DBs I need someone to knowing what can be merged and what can not be merged, which things link to which other things. RDF is primarily the language that gives you that. So we need a standard for the kind of data description.

2. Means for describing terms of that data- If I have a DB, I look at a column called C27 column 19 and I see that it is filled with the number 15, that doesn’t help me much, if I want a merge with another DB. If I know that that represents the age of a person, then I can find the another DB which have either other properties of that person or other ages of people. Now I know how to put them together. An Ontology or Domain description in a formal way to represent it.
These Ontologies define the meanings of things and here is where the term semantic comes.
If I want to link data together I need to know what is it about, and it is often about something that is not in the DB.
We need to take data out of the database into a place where it can be merged or you need query dynamically the DB.
RDF gives you data in triple stores- graph. If you take two table you can not guarantee that you will get table as a result of merging, if you have two trees I can not guarantee that I will have a tree as a result. Merging graphs always gives you graphs.
Directed labeled graph is RDF.
OWL (higher level data schema) to represent the Ontologies.

3. Standard way to query RDF- SPARQL.

Erik Meijer, Functional Programming, Channel 9 MSDN

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).

Handling Dependency Injection in C

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
}

MetaOCaml-Resource Aware Programming

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

Resource Aware Programming

Object-Oriented Design Heuristics

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).

Lecture on Design Patterns, Refactoring, Sane Principles to make you a better developer by Dino Esposito

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).