Is Object-Oriented necessary? 2024/3/24 Object-Oriented Conference LINE Yahoo Naoki Kishida

Motivation ● Beginners to programming say "I don't know Object-Oriented yet" ● Why not be able to write `for` loops first? ● Even if you understand "Object-Oriented", you can't write that you want to write ● "Object-Oriented" has become a goal for beginners ● Can they program if they understand OO? ● Reason why they can't write program is because you don't understand ● This kind of useless misunderstanding should be eliminated ● OO is unnecessary for beginners. You can put it off quite a bit later

Motivation ● "Object-Oriented" has been left with an ambiguous meaning ● Common definition is not required because it is not used in the real field ● Isn't it better to use words other than "Object-Oriented" that can narrow down and express without misunderstanding? ● In development, picking out what only "Object-Oriented" can express and use the word "Object-Oriented" for them

Breaf History ● 1960s: Original implementation in Simula ● 1970s: Named and conceptualized by Alan Kay ● 1980s: Popularized with C++ ● Practical definitions of encapsulation, inheritance, and polymorphism ● 1990s: Massive popularity with the spread of GUI ● If you labeled it as Object-Oriented, it will sell, so make everything OO ● 2000s: Decline due to web technology ● Functional style trend, from method to process ● after 2010: Into the legend... ● It seems amazing, but they don't know what it actually means

Alan Kay's Object-Oriented ● Isn't it a programming technique? ● Smalltalk introduced Simula-style object functionality on commercialization ● Easy to use for professional programmers ● He said "It's out of my hands" ● Research on end-user computiong ● Programming for end users to use computers ● Definitions are fragmentary ● Seems difficult to use as a guideline for the development ● Redifinition and restructuring are required ● So out -of scope

Object-Oriented methodology ● Three amigos method ● OMT(Object Modeling Technique) ● Rumbaugh ● Object modeling ● OOSE(OO software engineering) ● Jacobson ● Analyse by use-case ● Booch method ● Booch ● Development process ● Other, Coad/Yourdon's OOA/OOD、Shlaer/Mellor method, etc..

Why have so many methods emerged ● Same model can be used through analysis and code ● Methods are required to handle the difficult inheritance ● Adding development topics around classes and inheritance ● Analysis, project management, etc ● If you named it object-oriented, you would make money ● get budget for research ● books and software will sell ● Software engineering had become all object-oriented ● The name of software engineering is no longer popular ● This conf should be "Software engineering conf" (no one comes...)

Dream of integrating Object-Oriented methods ● Three amigos gathered at Rational ● Tried to integrate disparate methods ● Since the work was not progressing, only the notation was unified ● UML 「オブジェクト指向方法論の世界」より

Disadvantages of object-oriented methods ● assuming the water-fall ● Analysis→Design→Implementation ● To use same model are only front-loaded implementation ● Just coding by diagrams ● Architecture is not incorporated ● It is before networking era, it is assumed that processing on one divece ● Impedance mismatch with RDBMS ● Unable to handle complex server configurations ● In practice, the architecture determines the implementation ● Application must be build in one piece

From method to process ● Defining the documents for each step will result in a waterfall ● Necessary to explore the architecture as the service grows ● It is difficult to decide in advance just the shape of the code ● Good software comes from good processes ● CMM was popular ● Rational's unified method had also become RUP(Rational Unified Process) ● Devoting computing resources to the development process ● Continuous integration ● Git process(In the past, copying a repository was unthinkable)

Object-Oriented is based on inheritance ● Straustrup(C++ developer) ● "Object-oriented programming is programming that uses inheritance" ● Rambough(OMT) ● "There is some debate as to exactly what characteristics are required of an object-oriented approach. These discussions usually involve four aspects: identity, classification, polymorphism, and inheritance ● Booch(Booch method) ● "If a language does not directly support inheritance, it cannot be called object-oriented"

Object-Oriented is based on inheritance ● By having this definition, it becomes easier to explain ● How to use object-oriented ● Why it is no longer used ● What is object-oriented method

Considering conditions other than inheritance ● Object-Oriented if method(obj) is written as obj.method() ● I doubt whether it is effective enough to make a big trend ● Object-Oriented if you use classes ● structure enough? ● Object-Oriented if you write data and functions together ● Abstract Data Type ● Object-Oriented if you create objects ● To avoid static, to create objects for object-oriented laundering ● All good ideas for development is Object-Oriented ● Software engineering branding failure...

Abstract Data Type ● Define a type that is resistant to change and flexible by exposing only data operations ● Encapsulation of data ● Includes only data operations as operations

The paradigm is not on the language but on the feature ● The distinction between Object-Oriented language and Functional language is meaningless ● Object can be treated as functions, and functions can be treated as objects. it is mixable ● introducting syntactic sugar, it can be used as a language feature ● Languages have Object-Oriented features and Fuctional features in their own way ●

Relationship between objects and functions ● Objects and functions are commutative ● Objects with no attrs and single method can be treated as function ● Java lambda expression ● A function that returns a element by giving a name can be treated as an object Function myObj(int a, int b) { return name -> switch(name) { case "a" -> a; case "b" -> b; case "mul" -> a * b; case "add" -> a + b; default -> throw new RuntimeException(); }; } class MyFunc() { int apply(int a, int b) { return a + b; } }

Implements functional feature with design patterns ● Design patterns complement the missing feature of the language ● Something is wrong to memorize patterns and write them by hands ● Many patterns are no longer necessary introducing of language feature ● Usage patterns of higher-order functions are reproduced using class and inheritance ● ex Template methods

Template methods ● Basics of polymorphism abstract class Base { abstract void before(); abstract void after(); void proc() { before(); println("Hello"); after(); } } class School extends Base { @Override void before() { println("Stand up"); } @Override void after() { println("Sit down"); } }

Implement with higher-order functions ● Higher-order functions make it simple void proc(Runnable before, Runnable after) { before.run(); println("Hello"); after.run(); } proc(() -> println("Stand up"), () -> println("Sit down")); ※ Runnable is used to represent a function with no arguments and no return value

Differential programming ● Extracting different parts of similar processes ● Extracting commpon parts in normal functions

Polymorphism is branching in advance evaluation ● How to aggregate conditions ● Thinking about the cart summarization ● Calculation is different between Packed and Bulk sealed interface Type { record Bulk(int price, int unit) implements Type {} record Packed(int price) implements Type {} } record Item(Type type, int amount) {} var cart = List.of( new Item(new Packed(300), 3), new Item(new Bulk(250, 100), 230));

branch with switch ● branch with switch var cart = List.of( new Item(new Packed(300), 3), new Item(new Bulk(250, 100), 230)); int total = cart.stream() .mapToInt(item -> switch(item) { case Item(Packed(int price), int amount) -> price * amount; case Item(Bulk(int price, int unit), int amount) -> price * amount / unit; }).sum();

branch with inheritance ● Using inheritance seems to be more streamlined ● no change the calc part even if another Type added sealed interface Type { int calc(int amount); record Bulk(int price, int unit) implements Type { int calc(int amount) { return price * amount / unit; } } record Packed(int price) implements Type { int calc(int amount) { return price * amount; } } } var cart = List.of( new Item(new Packed(300), 3), new Item(new Bulk(250, 100), 230)); int total = cart.stream() .mapToInt(item ->　 item.type().calc(item.amount())) .sum();

Problems when using inheritance ● It is necessary to follow multiple classes ● It is difficult to write when the condition is not only Type ● Time zone, etc ● branching is requrered within the Type ● It is a problem if there is Type that you don't know ● In business processing, it is better to have all in one place

Object-Oriented is a state management technique ● Commonize a state management ● example ● I/O ● List abstract class IO { boolean opened; void open() { if (opened) return; openImpl(); opened = true; } void close() { if (!opened) error; closeImpl(); opened = false; } abstract void openImpl(); abstract void closeImpl(); } class MyIO extends IO { @Override void openImpl() { println("oeped!"); } @Override void closeImpl() { println("closed!"); } }

Use object-oriented at the terminal ● State management appears at the end of the module ● Ex: DOM、HTTP、DB connections requre state management ● Intermediate processing can be stateless GUI logic data store user application DOM HTTP DB conn

Use object-oriented at the terminal ● Inherit DBConnection to implement MySQLConnection and OracleConnection, it good to use object-oriented ● but MySQLConnection and OracleConnection are required as only one implementation ● If browser manages GUI state, GUI framework can be stateless ● Structured GUI definition and event handlers ●

Are subtyping object-oriented? ● It is true that subtyping is an important function of inheritance ● Object oriented does not touch on type theory other than subtype ● Functional ● Generics ● Different type of subtyping ● For inheritance subtyping, specify the base type explicitly ● Nominal type ● Inheritance=Nominal type+attribute extension ● There is also a way to consider it as subtype if it has the specified element ● Structual subtyping

Are subtype Object-Oriented? ● Nominal types may be called Object-Oriented, but it is possible to have a richer discussion with type theory ● The mechanism of nominal types itself can be independent from OO ● Beginners should only understand the concept of nominal types to use Java ● interface implementation cannot necessaryly be considered OO ● realization of the disjoint union ● Ex: Type must be either Bulk or Packed sealed interface Type { record Bulk(int price, int unit) implements Type {} record Packed(int price) implements Type {} }

How to use Object-Oriented ● Recognize the dataness and the modularity of classes ● Layer your application ● Use Object-Oriented at the endpoints of application

Class dataness and modularity ● Class have properties as data type and as modules ● Class as data type ● Muliple instance ● fields hold another data that includes ● Class as module ● basically Singleton ● fields hold another module that depends ● Becomes a subsystem ● Collection of processes class Name { String first; String last; Name(String first, String last) { this.first = first; this.last = last; } String toString() { return first + " " + last; } } @RestController class Greeting { @GetMapping("/hello") String hello() { return "hello"; } @GetMapping("/myname") Name myName() { return new Name("Naoki", "Kishida"); } }

Consider pure data types ● Pure functions ● No side effect ● Same return value for same arguments ● Pure data type ● No side effects outside of the data type ● Same return value for same arguments and same attributes

Layer your application ● Separate module and data ● Application processing is stateless ● Module is a collection of functions ● Dividing function, use layer ● avoiding infinite loops ● Data flows on layers ● Data-oriented programming

Summary ● Object-Oriented is programming that uses inheritance and state management ● Words other than object-oriented can be used for other than inheritance ● Easy to communicate technically because there is no confusion ● Object-Oriented rarely appears in application ● Managing state on terminal, the middle will be stateless=Functional ● Required for frameworks and middleware ● Let's study object-oriented and create frameworks and middleware!