1. programming
basics
basics
Ladislav Martincik

2. Content
- Simple question
- Complexity OF MODELING
reality (Not-reality)
- OOP
- Coupling (Connascence)
- big applouse ;)
ALL the time discussion please!

3. Why oop?
class Component
attr_accessor :name, :price
def initialize name, price
@name = name
@price = price
end
def to_s
"#{name}: $#{price}"
end
end

4. What is better?
def pay(from, to, amount, rounding = 0.5)
....
end
def pay(transaction)
....
end

5. Holy OOP
Keep “large”* software projects
manageable by human
programmers.
* what is LARGE?

6. Real Programming
HUMAN to HUMAN **
Complexity our brain can
handle 4/+-2
** This is one of the reasons why we have high-level
programming languages and not assembler.

7. REal OOP
Modeling based on Real world experience and
Mathematics
- Modularization- Abstraction -- Understandability
- Encapsulation -- Information Hiding-
Composability -- Structured Design- Hierarchy-
Continuity

8. Modularization
Decompose problem into smaller subproblems
that can be solved separately.

9. Modularization
class Component
include PrintableComponent
attr_reader :name, :price
...
end
module PrintableComponent
def to_s
"#{name}: $#{price}"
end
end

10. Abstraction --
Understandability
Terminology of the problem domain is reflected
in the software solution. Individual modules are
understandable by human readers.

11. Abstraction --
Understandability
set :environment, :development
set :user, :deploy
desc "Deploy to production"
task :deploy do
scp :local, "deploy@#{server}/#{root_dir}"
end

12. Composability --
Structured Design
Interfaces allow to freely combine modules to
produce new systems.

13. Composability --
Structured Design
gem "bundler"
plugins
module Namespace
module Namespace2
class X; end
class Y < X; end
end
end

14. Hierarchy
class Component
attr_reader :sub_components
end
class Car < Component
def initialize(color, type)
@sub_components << Wheel.new('left top')
@sub_components << Door.new('left driver')
end
end

15. Continuity
Changes and maintenance in
only a few modules does not affect
the architecture.

16. Continuity
DRY - Do not repeat yourself
Coupling - ConNascence

17. ConNascence
Two software components are connascent if a
change in one would require the other to be
modified in order to maintain the overall
correctness of the system. Connascence is a
way to characterize and reason about certain
types of complexity in software systems.

18. ConNascence
Strength - 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 degree
of its occurrence.def fun1(x1, x2) < def fun1(x1, x2, x3, x4, ...)
Locality - Stronger forms of connascence are acceptable if the
elements involved are closely related.
- Stronger forms of connascence are acceptable if the elements
involved are closely related.
- Stronger forms of connascence are acceptable if the elements
involved are closely related.
- Stronger forms of connascence are acceptable if the elements
involved are closely related.
- Stronger forms of connascence are acceptable if the elements
involved are closely related.

19. C of Name
def pay(from, to, amount, correction)
transaction do
from.move(to, amount, correction)
end
end

20. C of TYPE
def pay(transaction)
if transaction.kind_of? Array
DUCK TYPING
transaction.each do |t|
t.run
end
else
transaction.run def pay(transaction)
end if transaction.respond_to :each
end transaction.each do |t|
t.run
end
else
transaction.run
end
def pay(transaction) end
Array(transaction).each do |x|
x.run
end
end

21. C of MEANING
class 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 = 2
end def can_access_admin?(role_id = 0)
if role_id == ADMIN
true
elsif role_id == AMBASSADOR
true
else
false
end
end
end

22. C of Position
def pay(from, to, amount, correction)
....
end
def pay(options = {})
....
end
def pay(from, to, options = {})
...
end

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
encryption.call password
end
end

24. Conclusion
Name < Type < Meaning < Position < ALGORITHM
Name < Type < Meaning < Position < ALGORITHM

25. Thank you
Questions? Opinions?
ladislav.martincik@gmail.com
martincik.com
martincik.com

26. OOP - NEXT time
- Single responsibility principle
- Open/closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle