The document discusses object-oriented programming (OOP) principles and concepts like modularization, abstraction, encapsulation, composability, hierarchy, and continuity. It defines concepts like coupling and connascence, explaining how stronger coupling between elements makes a system more difficult to change. It provides examples of how OOP principles like abstraction allow problems to be modeled based on the real world.

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