Programming basics


Published on

Published in: Technology, Real Estate
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Programming basics

  1. 1. programming basics basicsLadislav Martincik
  2. 2. Content - Simple question - Complexity OF MODELING reality (Not-reality) - OOP - Coupling (Connascence) - big applouse ;)ALL the time discussion please!
  3. 3. Why oop?class Component attr_accessor :name, :price def initialize name, price @name = name @price = price end def to_s "#{name}: $#{price}" endend
  4. 4. What is better?def pay(from, to, amount, rounding = 0.5) ....enddef pay(transaction) ....end
  5. 5. Holy OOP Keep “large”* software projects manageable by human programmers.* what is LARGE?
  6. 6. Real Programming HUMAN to HUMAN ** Complexity our brain can handle 4/+-2** This is one of the reasons why we have high-levelprogramming languages and not assembler.
  7. 7. REal OOPModeling based on Real world experience andMathematics- Modularization- Abstraction -- Understandability- Encapsulation -- Information Hiding-Composability -- Structured Design- Hierarchy-Continuity
  8. 8. Modularization Decompose problem into smaller subproblems that can be solved separately.
  9. 9. Modularization class Component include PrintableComponent attr_reader :name, :price ... end module PrintableComponent def to_s "#{name}: $#{price}" end end
  10. 10. Abstraction --Understandability Terminology of the problem domain is reflected in the software solution. Individual modules are understandable by human readers.
  11. 11. Abstraction --Understandability set :environment, :development set :user, :deploy desc "Deploy to production" task :deploy do scp :local, "deploy@#{server}/#{root_dir}" end
  12. 12. Composability --Structured Design Interfaces allow to freely combine modules to produce new systems.
  13. 13. Composability --Structured Design gem "bundler" plugins module Namespace module Namespace2 class X; end class Y < X; end end end
  14. 14. Hierarchy class Component attr_reader :sub_components end class Car < Component def initialize(color, type) @sub_components << top) @sub_components << driver) end end
  15. 15. Continuity Changes and maintenance in only a few modules does not affect the architecture.
  16. 16. Continuity DRY - Do not repeat yourself Coupling - ConNascence
  17. 17. ConNascenceTwo software components are connascent if achange in one would require the other to bemodified in order to maintain the overallcorrectness of the system. Connascence is away to characterize and reason about certaintypes of complexity in software systems.
  18. 18. ConNascenceStrength - The stronger the form of connascence, the more difficult,and costly, it is to change the elements in the relationship.Name < Type < Meaning < Position < ...Degree - The acceptability of connascence is related to the degreeof its occurrence.def fun1(x1, x2) < def fun1(x1, x2, x3, x4, ...)Locality - Stronger forms of connascence are acceptable if theelements involved are closely related. - Stronger forms of connascence are acceptable if the elementsinvolved are closely related. - Stronger forms of connascence are acceptable if the elementsinvolved are closely related. - Stronger forms of connascence are acceptable if the elementsinvolved are closely related. - Stronger forms of connascence are acceptable if the elementsinvolved are closely related.
  19. 19. C of Name def pay(from, to, amount, correction) transaction do from.move(to, amount, correction) end end
  20. 20. C of TYPE def pay(transaction) if transaction.kind_of? Array DUCK TYPING transaction.each do |t| end else def pay(transaction) end if transaction.respond_to :each end transaction.each do |t| end else enddef pay(transaction) end Array(transaction).each do |x| endend
  21. 21. C of MEANINGclass Role def can_access_admin?(role_id = 0) if role_id == 1 # Admin true elsif role_id == 2 # Ambassador true else false end class Role end ADMIN = 1; AMBASSADOR = 2end def can_access_admin?(role_id = 0) if role_id == ADMIN true elsif role_id == AMBASSADOR true else false end end end
  22. 22. C of Positiondef pay(from, to, amount, correction) ....enddef pay(options = {}) ....end def pay(from, to, options = {}) ... end
  23. 23. C of Algorithm class User def self.encrypt_password Digest::SHA1.hexdigest(password) end end class User attr_writer :encryption def initialize encryption = Digest::SHA1.hexdigest end def self.encrypt_password password end end
  24. 24. Conclusion Name < Type < Meaning < Position < ALGORITHM Name < Type < Meaning < Position < ALGORITHM
  25. 25. Thank you Questions? Opinions?
  26. 26. OOP - NEXT time- Single responsibility principle- Open/closed principle- Liskov substitution principle- Interface segregation principle- Dependency inversion principle