oop - How does pattern-match driven logic look like in real world applications? -

i stumbled across following passage (while reading pep-3119, question isn’t language-specific). emphasis mine.

in particular, there need process objects in way wasn't anticipated creator of object class. not best solution build in every object methods satisfy needs of every possible user of object. moreover, there many powerful dispatch philosophies in direct contrast classic oop requirement of behavior being strictly encapsulated within object, examples being rule or pattern-match driven logic.

i’m familiar oop: code structured around objects mirror concepts or real-world entities, encapsulate states, , can acted upon through methods.

how rule or pattern-match driven logic work? like?

real-world examples (perhaps in web application back-end domain?) appreciated. here’s corresponding example in oop.

i believe pep-3119 article describes solution expression problem. solution describe abstract base classes.

to understand abstract base classes useful first elucidate difference between abstract , concrete entities. abstract entity has no implementation. concrete entity has implementation. entities in object-oriented programming either properties or methods.

a class in object-oriented programming languages group of concrete entities. object-oriented programming languages have interfaces groups of abstract entities. abstract base class mixed bag of entities. default entities abstract can made concrete giving them default implementation, can overridden if necessary.

an example of abstract base class in java (correct me if wrong):

abstract class equals<t> {     public boolean equals(t x) {         return !notequals(x);     }      public boolean notequals(t x) {         return !equals(x);     } }  class person extends equals<person> {     public firstname;     public lastname;      public person(string firstname, string lastname) {         this.firstname = firstname;         this.lastname  = lastname;     }      public boolean equals(person x) {         return x.firstname == firstname &&                x.lastname  == lastname;     } } 

anyway, moving on expression problem. philip wadler has following it:

the expression problem new name old problem. goal define datatype cases, 1 can add new cases datatype , new functions on datatype, without recompiling existing code, , while retaining static type safety (e.g., no casts).

the expression problem slicing , dicing data types manageable pieces, while still allowing data type extended arbitrarily. data type can visualized 2 dimensional matrix of cases , functions. example, consider document data type:

            text       drawing   spreadsheet         +-----------+-----------+-----------+ draw()  |           |           |           |         +-----------+-----------+-----------+ load()  |           |           |           |         +-----------+-----------+-----------+ save()  |           |           |           |         +-----------+-----------+-----------+ 

the document data type has 3 cases (text, drawing , spreadsheet) , 3 functions (draw, load , save). hence, has been sliced , diced 9 pieces can implemented in object-oriented languages java follows:

public interface document {     void draw();     void load();     void save(); }  public class textdocument implements document {     public void draw() { /* draw text doc... */ }     public void load() { /* load text doc... */ }     public void save() { /* save text doc... */ } }  public class drawingdocument implements document {     public void draw() { /* draw drawing... */ }     public void load() { /* load drawing... */ }     public void save() { /* save drawing... */ } }  public class spreadsheetdocument implements document {     public void draw() { /* draw spreadsheet... */ }     public void load() { /* load spreadsheet... */ }     public void save() { /* save spreadsheet... */ } } 

so have sliced , diced document data type 9 manageable pieces. however, have chosen first slice data type functions , dice cases. therefore, easy add new cases (all create new class implements document interface). however, can't add new functions interface. therefore, our data type not extensible.

however, object-oriented approach not method of slicing , dicing data types. text emphasized says, there's way:

in particular, there need process objects in way wasn't anticipated creator of object class. not best solution build every object methods satisfy needs of every possible user of object. moreover, there many powerful dispatch philosophies in direct contrast classic oop requirement of behavior being strictly encapsulated within object, examples being rule or pattern-match driven logic.

in object-oriented way behavoir strictly encapsulated within object (i.e. each class implements set of methods , in our example above, same set of methods). alternative rule or pattern-match driven logic in data type first sliced cases , diced functions. example, in ocaml:

type document   = text   | drawing   | spreadsheet  fun draw (text)        = (* draw text doc... *)   | draw (drawing)     = (* draw drawing doc... *)   | draw (spreadsheet) = (* draw spreadsheet... *)  fun load (text)        = (* load text doc... *)   | load (drawing)     = (* load drawing doc... *)   | load (spreadsheet) = (* load spreadsheet... *)  fun save (text)        = (* save text doc... *)   | save (drawing)     = (* save drawing doc... *)   | save (spreadsheet) = (* save spreadsheet... *) 

again, have sliced , diced document data type 9 manageable pieces. however, first sliced data type cases , diced functions. therefore, easy add new functions it's not possible add new cases. therefore, data type still not extensible.

this expression problem. if slice data type functions first it's easy add new cases difficult add new functions. if slice data type cases first it's easy add new functions difficult add new cases.

the expression problem arises because of inherent need extend data type. if data type never needs extended may use either of 2 approaches (which henceforth call object-oriented approach , functional approach). however, practical purposes data types need extended.

if need extend data type adding new cases object-oriented approach (e.g. in graphical user interfaces operations remain same new visual elements may added). if need extend data type adding new functions functional approach (e.g. practically general purpose programs can think of).

now, if data type needs extended adding both new cases , new functions that's going problem. however, can done in dynamic languages javascript , python using inspection (the word pep-3119 article uses). problem because it's dynamic solution compiler can't guarantee have implemented pieces of data type , if go definition of expression problem last clause and while retaining static type safety. hence, dynamic languages still don't solve expression problem.

anyway, pep-3119 article talks both invocation , inspection means of selecting piece of data type. invocation preferred because if function can invoked means implemented. inspection dynamic solution , hence not correct.

if want know how abstract base classes solve expression problem suggest read rest of pep-3119 article. more information on expression problem suggest read bob nystrom's blog post on “solving expression problem”.