advice to oop students

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

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)

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

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. 

oop heroes

Dan Ingalls
Alan Kay
Grady Booch
Rebecca Wirf Brock
Robert Martin
Kent Beck
David West