prasadtalasila · May 30, 2017 08:14
diff --git a/advice to oop students b/advice to oop students


 Do post-mortem after finishing a program / project;
 Success / failure of a project is not a precondition for post-mortem.

 Write code for others and for your future self.

 Code is poetry. Code is never finished, it's only abandoned.

 Measure (test) the phenomenon (program).

 Software development is a social activity.

 Write simple, but not silly code. Clever code is a minefield.

 Read a lot and read widely. Best programmers are polymaths.

 Read good code.

 Rabbit at rest slowly turns into a tortoise.
 Tortoise on the run slowly turns into a rabbit.

 Remember the skill pyramid - don't know, somehow got it done, can do it again the same way, document it so that others can follow your steps
 More formal: https://hr.od.nih.gov/workingatnih/competencies/proficiencyscale.htm

 Know the productivity curve. (Ref: J Rainberger)

 Be the domain expert. Remember the advice of David West.
 A cashier who just dispenses cash is a poor banker.
 A programmer who works in isolation from business is a liability.


 Message oriented programming
 	model for a software system

      				message embedded in protocol					       message embedded in protocol				
 		input ---------------------------------> processing -------------------------------------> output

 	quite a few of the errors are due to unexpected input
 	DB is also an input
 	Not much thought is given to messages and protocols
 	document legal range of inputs and the protocols used for communication


diff --git a/Alan Kays Objects b/Alan Kays Objects
 From paper
 An Early History of Smalltalk, Alan Kay
 (Ref: http://www.vpri.org/pdf/hc_smalltalk_history.pdf)

 Essential principles
 1) Everything is an object
 2) Objects communicate by sending and receiving messages (in terms of objects)
 3) Objects have their own memory (in terms of objects)

 Principles that kept on changing between versions of smalltalk
 4) Every object is an instance of a class (which must be an object)
 5) The class holds the shared behavior for its instances (in the form of objects in a program list)
 6) To eval a program list, control is passed to the first object and the reminder is treated as its message.

 Four techniques that gave OOP much power - persistant state, polymorphism, instantiation (inheritance), methods as goals

 OOP is all about dependency management.   - Robert C Martin

 all the object's state must be private.

 An object is a virtual server.  - Butler Lampson

 In 1961, a staff sergent of US Air Force shipped a tape with three section.
 1) Pointers to procedures
 2) Procedures
 3) Data records with a number of pointer table indirectly pointing to the procedure that can read the record.
 The staff sergent was solving the problem of changing the format of the record with out apriori agreement. This is truly object oriented programming.


 I was too blythe about the [OOP] term back in the 60s and should have chosen something like "message oriented" – Alan Kay

 OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. - Alan Kay
 (Ref: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

diff --git a/David West notes b/David West notes

 project size - lines of code
 -----------------------------
 classes with about 7+-2 methods
 methods with 5+-2 lines of code
 project with about 10-15 own objects and 30-45 imported objects
 a project with a total of about 200 lines of code
 don't create more than 20% of the needed functionality; rest should come from libraries

 composition (delegation) is always preferable to inheritance

 inheritance is a mistake; substitutability (polymorphism) is needed, but without inheritance

 "OOP is Dead, Long Live OODD, David West"

 David Taylor, business model books
diff --git a/Eric Evans notes b/Eric Evans notes
  Don't strive for perfect design
 	It is better to ship an imperfect design that works than to vascillate between perfect design and a hackish solution put together in last minute
 	Prefer a simple model that covers 90% of the cases over an abstract model that covers 99% of the cases
 		Divert all the cases not covered by the simple design to look up table kind of structure

 	Give unclear parts of design, messages with transitory sounding names. Make all the stakeholders be aware of the transitory nature of the unclear parts. Don't force clear sounding abstractions over unclear design.

 	Respect the old code; it kept the business going for so long. 
diff --git a/oop heroes b/oop heroes
 Dan Ingalls
 Alan Kay
 Grady Booch
 Rebecca Wirf Brock
 Robert Martin
 Kent Beck
 David West


	Do post-mortem after finishing a program / project;
	Success / failure of a project is not a precondition for post-mortem.

	Write code for others and for your future self.

	Code is poetry. Code is never finished, it's only abandoned.

	Measure (test) the phenomenon (program).

	Software development is a social activity.

	Write simple, but not silly code. Clever code is a minefield.

	Read a lot and read widely. Best programmers are polymaths.

	Read good code.

	Rabbit at rest slowly turns into a tortoise.
	Tortoise on the run slowly turns into a rabbit.

	Remember the skill pyramid - don't know, somehow got it done, can do it again the same way, document it so that others can follow your steps
	More formal: https://hr.od.nih.gov/workingatnih/competencies/proficiencyscale.htm

	Know the productivity curve. (Ref: J Rainberger)

	Be the domain expert. Remember the advice of David West.
	A cashier who just dispenses cash is a poor banker.
	A programmer who works in isolation from business is a liability.


	Message oriented programming
	model for a software system

	message embedded in protocol message embedded in protocol
	input ---------------------------------> processing -------------------------------------> output

	quite a few of the errors are due to unexpected input
	DB is also an input
	Not much thought is given to messages and protocols
	document legal range of inputs and the protocols used for communication
	From paper
	An Early History of Smalltalk, Alan Kay
	(Ref: http://www.vpri.org/pdf/hc_smalltalk_history.pdf)

	Essential principles
	1) Everything is an object
	2) Objects communicate by sending and receiving messages (in terms of objects)
	3) Objects have their own memory (in terms of objects)

	Principles that kept on changing between versions of smalltalk
	4) Every object is an instance of a class (which must be an object)
	5) The class holds the shared behavior for its instances (in the form of objects in a program list)
	6) To eval a program list, control is passed to the first object and the reminder is treated as its message.

	Four techniques that gave OOP much power - persistant state, polymorphism, instantiation (inheritance), methods as goals

	OOP is all about dependency management. - Robert C Martin

	all the object's state must be private.

	An object is a virtual server. - Butler Lampson

	In 1961, a staff sergent of US Air Force shipped a tape with three section.
	1) Pointers to procedures
	2) Procedures
	3) Data records with a number of pointer table indirectly pointing to the procedure that can read the record.
	The staff sergent was solving the problem of changing the format of the record with out apriori agreement. This is truly object oriented programming.


	I was too blythe about the [OOP] term back in the 60s and should have chosen something like "message oriented" – Alan Kay

	OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. - Alan Kay
	(Ref: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en)

	project size - lines of code
	-----------------------------
	classes with about 7+-2 methods
	methods with 5+-2 lines of code
	project with about 10-15 own objects and 30-45 imported objects
	a project with a total of about 200 lines of code
	don't create more than 20% of the needed functionality; rest should come from libraries

	composition (delegation) is always preferable to inheritance

	inheritance is a mistake; substitutability (polymorphism) is needed, but without inheritance

	"OOP is Dead, Long Live OODD, David West"

	David Taylor, business model books
	Don't strive for perfect design
	It is better to ship an imperfect design that works than to vascillate between perfect design and a hackish solution put together in last minute
	Prefer a simple model that covers 90% of the cases over an abstract model that covers 99% of the cases
	Divert all the cases not covered by the simple design to look up table kind of structure

	Give unclear parts of design, messages with transitory sounding names. Make all the stakeholders be aware of the transitory nature of the unclear parts. Don't force clear sounding abstractions over unclear design.

	Respect the old code; it kept the business going for so long.
	Dan Ingalls
	Alan Kay
	Grady Booch
	Rebecca Wirf Brock
	Robert Martin
	Kent Beck
	David West