Anti Object-Oriented Design Patterns

368 views

Published on

This talk shows an analysis of some object oriented design patterns that are there to fight against the object oriented design and the rules and constraints of some of the most popular OOP languages.

Some of these patterns will be discussed in detail, analyzing their nature from the PLT (Programming Language Theory).

For each one, an alternative using non-OOP design will be discussed. The final purpose of the talk is to provide some insights about OOP and what would be the benefits of mixing such a paradigm with others like functional programming.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
368
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Anti Object-Oriented Design Patterns

  1. 1. Anti- Object Oriented Design Patterns Alvaro Polo DEVCON  2013  
  2. 2. Design Patterns What’s a design pattern? “A   general   reusable   solu-on   to   a   commonly   occurring   problem   within   a   given   context   in   so8ware  design”,  Wikipedia   DEVCON  2013  
  3. 3. Design Patterns But, what kind of commonly ocurring problem are we talking about? DEVCON  2013  
  4. 4. Design Patterns No, this is all about software design DEVCON  2013  
  5. 5. Problems unsolved by the language _uppercase: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp movq %rdi, -8(%rbp) movl %esi, -12(%rbp) movl $0, -16(%rbp) LBB0_1: movl -16(%rbp), %eax cmpl -12(%rbp), %eax jge LBB0_3 movslq -16(%rbp), %rax movq -8(%rbp), %rcx movb (%rcx,%rax), %dl movb %dl, -17(%rbp) movsbl -17(%rbp), %esi cmpl $97, %esi jl LBB0_2 DEVCON  2013   movsbl -17(%rbp), %eax cmpl $122, %eax jg LBB0_2 movsbl -17(%rbp), %eax addl $65, %eax subl $97, %eax movb %al, %cl movslq -16(%rbp), %rdx movq -8(%rbp), %rsi movb %cl, (%rsi,%rdx) LBB0_2: movl -16(%rbp), %eax addl $1, %eax movl %eax, -16(%rbp) jmp LBB0_1 LBB0_3: popq %rbp ret
  6. 6. Problems unsolved by the language _uppercase: movsbl -17(%rbp), %eax pushq %rbp cmpl $122, %eax .cfi_def_cfa_offset 16 jg end_if .cfi_offset %rbp, -16uppercase(char *str, int strl) { movsbl -17(%rbp), %eax void movq %rsp, %rbp addl i++) { for (int i = 0; i < strl; $65, %eax .cfi_def_cfa_register %rbp char c = str[i]; subl $97, %eax movq %rdi, -8(%rbp) movb %al, if (c >= 'a' && c <= 'z') %cl movl %esi, -12(%rbp) -16(%rbp), %rdx str[i] = 'A' movslq 'a'; + c movl $0, -16(%rbp) } movq -8(%rbp), %rsi begin_for: movb %cl, (%rsi,%rdx) } movl -16(%rbp), %eax end_if: cmpl -12(%rbp), %eax movl -16(%rbp), %eax jge end_for addl $1, %eax movslq -16(%rbp), %rax movl %eax, -16(%rbp) movq -8(%rbp), %rcx jmp begin_for movb (%rcx,%rax), %dl end_for: movb %dl, -17(%rbp) popq %rbp movsbl -17(%rbp), %esi ret cmpl $97, %esi jl end_if DEVCON  2013  
  7. 7. Problems caused by the language We want to represent IPv4 addresses in our Java program. Suggestions? class IpV4Address { private uint bits = 0; public static IpV4Address fromCidr(String cidr) { ... } public bool isInSameNetwork(IpV4Address addr, Netmask netmask) { ... } ... }; DEVCON  2013  
  8. 8. Problems caused by the language We want to represent IPv4 addresses in our program. Suggestions? class IpV4Address { private uint bits = 0; public static IpV4Address fromCidr(String cidr) { ... } public bool isInSameNetwork(IpV4Address addr, Netmask netmask) { ... } ... }; DEVCON  2013  
  9. 9. Problems caused by the language Let  me  introduce  the  An@-­‐  Object  Oriented  Design  PaGerns   DEVCON  2013  
  10. 10. Singleton Pattern DEVCON  2013  
  11. 11. Singleton Pattern public class Application extends Configurable { private static Application instance; OOP establishes some constraints: ü Every object is bounded to a}lifecycle private Application() { ... ü Every classstaticas many instances as fit into has Application getInstance() { public if memory (instance == null) instance = new Application(); return instance; } // The functionality of the application goes here ... Singleton is fighting against these rules! } DEVCON  2013  
  12. 12. Singleton Pattern What if we bend the rules? ... object Application extends Configurable { // The functionality of the application goes here ... } DEVCON  2013  
  13. 13. Strategy and Co. DEVCON  2013  
  14. 14. Strategy and Co. interface Player { void attack(Player enemy); // Other stuff the player does ... } interface Weapon { void attack(Player enemy); } ü  Java is a pure-OOP programming language ü  Everything is modeled using objects class AbstractPlayer implements Player { private Weapon weapon; public setWeapon(Weapon weapon) { this.weapon = weapon; } public void attack(Player enemy) { weapon.attack(enemy); } } class Axe implements Weapon { ... } class Sword implements Weapon { ... } class Bow implements Weapon { ... } DEVCON  2013   Strategy is fighting against the lack of other mechanism to represent behavior!
  15. 15. Strategy and Co. What if we have a non-pure OOP language? class player { public: typedef std::function<void(Player&)> weapon; void set_weapon(weapon& w) { _weapon = w; } void attack(player& enemy) { _weapon(enemy); } private: weapon _weapon; }; void axe(player& enemy) { ... } void sword(player& enemy) { ... } void bow(player& enemy) { ... } DEVCON  2013  
  16. 16. Strategy and Co. The lack of functions is not a matter exclusive for strategy pattern ü  Observer pattern ü  Factory (method) pattern ü  Adapter pattern ü  … DEVCON  2013  
  17. 17. Visitor DEVCON  2013  
  18. 18. Visitor interface CarElementVisitor { void visit(Wheel wheel); void visit(Engine engine); void visit(Body body); void visit(Car car); } interface CarElement { void accept(CarElementVisitor visitor); } class Wheel implements CarElement { public void accept(CarElementVisitor visitor) { visitor.visit(this); } } class Engine implements CarElement { public void accept(CarElementVisitor visitor) { visitor.visit(this); } } class Body implements CarElement { public void accept(CarElementVisitor visitor) { visitor.visit(this); } } DEVCON  2013   class Car implements CarElement { public void accept(CarElementVisitor visitor) { for(CarElement elem : elements) elem.accept(visitor); visitor.visit(this); } } class Mechanic implements CarElementVisitor { public void visit(Wheel wheel) { ... } public void visit(Engine engine) { ... } public void visit(Body body) { ... } public void visit(Car car) { ... } }
  19. 19. Visitor Why not simply…? interface CarElementVisitor { void visit(Wheel wheel); void visit(Engine engine); void visit(Body body); void visit(Car car); } class Car implements CarElement { public void accept(CarElementVisitor visitor) { for(CarElement elem : elements) visitor.visit(elem); visitor.visit(this); } elem is a } CarElement, and visit(CarElement) DEVCON  2013   is not defined in visitor!
  20. 20. Visitor Call visit(Wheel w) interface CarElement { void accept(CarElementVisitor visitor); } class Wheel implements CarElement { public void accept(CarElementVisitor visitor) { visitor.visit(this); } } class Engine implements CarElement { public void accept(CarElementVisitor visitor) { visitor.visit(this); } } visit(Engine Call class Body implements CarElement { public void accept(CarElementVisitor visitor) { visitor.visit(this); } } Call visit(Body b) DEVCON  2013   That’s why we need to redefine accept() again and again e)
  21. 21. Visitor What if we dispatch the message based on… ü The receiver of the message, and… ü The arguments of the message? Let me introduce the double dispatch! Visitor pattern is there to provide double dispatch semantics not supported by the language DEVCON  2013  
  22. 22. Conclusions DEVCON  2013  
  23. 23. Conclusions ü  Design patterns are bad ü  NOOOOOOOOOOO!!!!!!! ü  Design patterns are useful, even when they fight against the language ü  We must learn from our errors and languages must evolve to avoid them And some opinions ü  OOP as implemented by Java is almost over ü  Learn Scala DEVCON  2013  
  24. 24. Q&A DEVCON  2013  

×