Successfully reported this slideshow.

Object oriented programming in 2014:Standard or Legacy?

0

Share

1 of 43
1 of 43

Object oriented programming in 2014:Standard or Legacy?

0

Share

Download to read offline

From the OOP cult in the 90s to now: What happened? What failed? The current combinations with other software architecture paradigms?

1) The Great Hopes About OOP
2) There is no Silver Bullet
3) Case: Epigami Docker OO Infrastructure

From the OOP cult in the 90s to now: What happened? What failed? The current combinations with other software architecture paradigms?

1) The Great Hopes About OOP
2) There is no Silver Bullet
3) Case: Epigami Docker OO Infrastructure

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Object oriented programming in 2014:Standard or Legacy?

  1. 1. Object Oriented Programming in 2014: Standard or Legacy? Mathieu François @Universitas Bina Nusantara 07/11/2014
  2. 2. Did Object Oriented Dominate Programming? Introduction 1. The Great Hopes About OOP* 2. There is no Silver Bullet 3. Case: Epigami OO Infrastructure * Object Oriented Programming
  3. 3. Programming: Art or Science?
  4. 4. Computer Science vs Programming The Art of Computer Programming
  5. 5. Practices In Real World
  6. 6. Who Studies History In Engineering?
  7. 7. The Great Hopes About OOP Software?
  8. 8. • Encapsulation • Polymorphism • Inheritance • Class of objects (constructor) • Instance of class • Method vs data • Message passing • Abstraction OOP Definition
  9. 9. OOP Hype In The Mid-90s
  10. 10. Why the OOP Cult? OOP perceived as the solution for all software development challenges: • Code reuse and recycling • Encapsulation of knowledge • Isolation of bug impacts • Design benefits, especially for very large programs • Maintenance
  11. 11. Pure languages: Ruby, Python, Smalltalk, Scala, Eiffel Languages mainly OOP but also have procedural elements: C++, Java, C#, VB.NET Languages historically procedural but extended with OO features: Pascal, VB, Fortran, Perl, Cobol 2002, PHP OOP In Almost Every Languages
  12. 12. Profusion Of OOD Solutions
  13. 13. 20 Years Later… How Did OOP Succeed?
  14. 14. OOP For Kernel Development?
  15. 15. OOP For Kernel Development Linux, Windows, OS X… They are still all based on good old-fashioned C
  16. 16. OOP For Web App?
  17. 17. OOP For Web App? Yes: Languages, DOM, JSON No: Service Oriented Architecture, Event- Driven Design More about SOA in a few slides...
  18. 18. There Is No Silver Bullet
  19. 19. There Is No Silver Bullet By Fred Brooks (1986), also author of The Mythical Man month (1975) Essential Complexity vs Accidental Complexity Since ‘modern’ languages (Fortran, COBOL), no real improvement about accidental complexity
  20. 20. org 7C00h jmp short Start ;Jump over the data (the 'short' keyword makes the jmp instruction smaller) Msg: db "Hello World! " EndMsg: Start: mov bx, 000Fh ;Page 0, colour attribute 15 (white) for the int 10 calls below mov cx, 1 ;We will want to write 1 character xor dx, dx ;Start at top left corner mov ds, dx ;Ensure ds = 0 (to let us load the message) cld ;Ensure direction flag is cleared (for LODSB) Print: mov si, Msg ;Loads the address of the first byte of the message, 7C02h in this case ;PC BIOS Interrupt 10 Subfunction 2 - Set cursor position ;AH = 2 Char: mov ah, 2 ;BH = page, DH = row, DL = column int 10h lodsb ;Load a byte of the message into AL. ;Remember that DS is 0 and SI holds the ;offset of one of the bytes of the message. ;PC BIOS Interrupt 10 Subfunction 9 - Write character and colour ;AH = 9 mov ah, 9 ;BH = page, AL = character, BL = attribute, CX = character count int 10h inc dl ;Advance cursor cmp dl, 80 ;Wrap around edge of screen if necessary jne Skip xor dl, dl
  21. 21. OOD Is Not the Only Design Approach Other Approaches or ‘Schools Of Thought’: • Functional • Event-driven • Data-driven • ‘Unix Philosophy’
  22. 22. Object-Relational Impedance We use Object Relation Mapping (ORM) because Object DBs didn’t really take off
  23. 23. “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Bad collaboration or project management have not solved by OOP Conway’s Law Still Applies to OOP
  24. 24. Conway’s Law Illustrated
  25. 25. But The Main, Main Failure Of OOP Is...
  26. 26. CORBA, DCOM fundamental flaw was to assume Location Transparency Local vs Distributed Objects
  27. 27. Network Is Not Transparent
  28. 28. Welcome to the REST API Web (Economy) From OOA to SOA
  29. 29. Case: Epigami OO Architecture
  30. 30. Why Not Apply OOD To Our Infrastructure?
  31. 31. Infrastructure Since 15 years • Hardware Technologies +++ • Virtualization Technologies +++ • System Configuration Management +
  32. 32. ‘Infrastructure As A Code’: Really? First deployment automation in the 90s (Jumpstart SUN & Co) Puppet & Chef are just improved automation, not a new real paradigm
  33. 33. Light virtualization based on containers From Infrastructure to Application-centric The New Kid On The Block: Docker
  34. 34. Docker In A Nutshell
  35. 35. Infrastructure ‘Code’ Lifecycle
  36. 36. Infrastructure ‘Code’ Lifecycle If Infrastructure is Code, why not use OOD?
  37. 37. OOD Applied to Docker Docker Image Build Running Container ‘Jailed’ Process FROM <image> Init Script EXPOSE <service> Container Link Link Alias Object-Oriented Class Instance of Class Encapsulation Inheritance Constructor Method Message Passing Abstraction
  38. 38. Infrastructure Object Hierarchy
  39. 39. Benefits • Isolation • Security • Modularity • Traceability • Automation (Continuous Deployment) • Flexibility • Performance • Scalability • Price
  40. 40. Summary • Pros & Cons of OOD • There is no Silver Bullet • Continuous Evolution of the design paradigms, built on top of the previous ones

Editor's Notes

  • 2do:
    title?
    background pix
    epigami logo
  • 2do:
    toc
  • 2do:
    mention kopi discussion after
  • http://en.wikipedia.org/wiki/The_Art_of_Computer_Programming
    http://www.dijkstrascry.com/knuth
    http://en.wikiquote.org/wiki/Edsger_W._Dijkstra

  • Vendor or techno agnostic
    15y experience = x generations in IT?
  • To understand why we are here: what were the choices made by the engineers before. There was always a reason even behind weird or stupid designs; our predecessors were at least as smart than we are
  • http://en.wikipedia.org/wiki/Object-oriented_programming
  • 2do:
    Find kitch book about OOP (Delphi…)

    If not OOP, not good
  • 2do:
    Miracle cure medecine

  • Gradient of OOP' across languages
    Pure languages (everything is object: primitives, characters up to classes, blocks...)
    Ruby, Python, Smalltalk, Scala, Eiffel
    Languages mainly OOP but also have procedural elements
    C++, Java, C#, VB.NET
    Languages historically procedural but extended with OO features:
    Pascal, VB, Fortran, Perl, Cobol 2002, PHP
  • http://en.wikipedia.org/wiki/Software_design_pattern
    2do: book cover design pattern
    Enterprise desing patterns?
  • http://wiki.apidesign.org/wiki/OOP?
    SOA vs OOA
    There's been a lot of interest in Service-Oriented Architecture (SOA) at my company recently. Whenever I try to see how we might use it, I always run up against a mental block. Crudely:
    Object-orientation says: "keep data and methods that manipulate data (business processes) together";
    Service-orientation says: "keep the business process in the service, and pass data to it".
    Edit: The answers saying "OO for internals, SOA for system boundaries" are great and useful, but this isn't quite what I was getting at.

    API call = get GPS location from Google Map = call to remote object? No, it's serialized data (JSON, XML)




  • http://wiki.apidesign.org/wiki/OOP?
    SOA vs OOA
    There's been a lot of interest in Service-Oriented Architecture (SOA) at my company recently. Whenever I try to see how we might use it, I always run up against a mental block. Crudely:
    Object-orientation says: "keep data and methods that manipulate data (business processes) together";
    Service-orientation says: "keep the business process in the service, and pass data to it".
    Edit: The answers saying "OO for internals, SOA for system boundaries" are great and useful, but this isn't quite what I was getting at.

    API call = get GPS location from Google Map = call to remote object? No, it's serialized data (JSON, XML)


    Objective-C + Java for IOS/Android
    Android dev = all Mobile features are implemented via extending Android services (New Activity, Service...)


    Service Extends
    Activity Extends





  • http://en.wikibooks.org/wiki/X86_Assembly/Bootloaders
  • add source
  • CORBA = many issues as 'design by commitee' (all features included to satisfy everyone=> too complex to implement => compat issues)
    design by dev is much better btw
    Location transparency = STUPID... does not address network latencies, losses... => status unknwon usually 30s TCP timeout



  • So now: Web programming is Service-based architetcure, not Object-based architecture
    Quota, security boundary, etc..
    REST APIs that follows what made Web succesful = looser coupling, but scalable
    => REST attributes, Or Unix applied to Web programming?
    ... transparency, ...
    Or The Strenghts of Unix Philosophuy?
    Unix (BSD / MIT) = Interne
    TCP/IP Internet Has won against Telc
    Unix Modularity & Glue Model Has won against OO ‘Enterprise Architecture’ ?


  • 2do:
    mention kopi discussion after
  • (still some long way to go, but already widely used on mission-critical platforms)
  • - Isolation => bug in staging or co-hosted site has no impact on Live
    - Security => security bug in 1 container does not impact other containers and host OS + services and
    data with different levels of security are separated
    - Modularity => Can improve/replace transparently components
    - Traceability => Build files are versioned, helps tracking and coordination, easy to make rollback too
    - Automation => Continuous Deployment => Dev is pushed granular, faster updates, no Huge integration syndrom
    - Flexibility = Can experiment new ideas very quickly; fast changes from Marketing co-exist with slower changes of Core Product
    - Performance = very small overhead
    - Scalability => Can move perf bottleneck to dedicated node without any change to architecture
    - Price => Cheapest virtualization solution, fully Open Source
    - Techno perspectives => bright future, lot of changes to expect: partnerships with MS and VMware

  • ×