Beyond Objects: Programming in the 21st Century Overview

ON BEYOND OBJECTS PROGRAMMING IN THE 21 PROGRAMMING IN THE 21TH THCENTURY CENTURY COMP 590-059 FALL 2023 David Stotts Computer Science Dept UNC Chapel Hill

OO Has its Critics Including some serious objections See the Wikipedia OOP article There are only two kinds of languages: the ones people complain about and the ones nobody uses. Bjarne Stroustrup, The C++ Programming Language

Java-style OO ( reference ) What is good in Java-style OO ? platform independent similar syntax to C and C++ pointer abstraction and discipline automatic garbage collector easy intro to OOP less-steep learning curve clear structure, classes from the start

Java-style OO ( reference ) What needs fixing ? Nullity Tony Hoare has said that the null reference was his billion dollar mistake when he designed it into ALGOL in 1965. This one not-type-safe item (a variable that can contain a value that is NOT a valid object) leads to unexpected behaviors and program crashes. Adopting it is Java makes it similar to handling a segfault errors in C ( from referencing illegal memory using data as addresses in C ) Rigidity After programming in Java for a while, you would notice you write the same code multiple times. As technology advanced, there was a huge spike in increased boilerplate code in Java, thereby making it bulky.

Java-style OO ( reference ) What needs fixing ? Limited functional language support Java was made purely object-oriented. However, many programmers and domains of programming came to require features from both imperative and declarative languages. Flawed scope/inheritance abstraction We have four access specifiers in Java: public, protected, private and package-protected/default/friendly. There was no way to allow access to sub-classes and restrict access to other classes in the package.

Improvements ( reference ) JVM-based languages like Kotlin and Scala ( see list ) Keep the JVM, use new syntax and semantics to fix the issues Java itself presents Example: Kotlin reduced boilerplate ingrained null-safety multi-paradigm ( improved OOP and incorporates functional ) sealed classes ( type-safe inheritance at compile time, inspired by Rust/Haskell ) String templates (inspired by Python/PHP) operator overloading (like in C and Python). data classes (which are records in Java). features like extension and inline functions, and coroutines.

What are Issues with OO? Goals: OO methods/models were intended to increase reuse increase modularity How do we do support each in OO PLs and models? Objects allow calling code (methods) without having to mod it or know it (reuse) Packages (modularity)

What are the failings in OO? Goals: OO methods/models were intended to increase reuse increase modularity How do we do fail to support each? Sheer size modules can get much larger than we can keep in mind (and therefore easily and effectively reason about) Encapsulation allowed, not required (breaks modularity, breaks abstractions) Not easy to separate out different concerns in a module/class, not easy to keep a class cohesive

Encapsulation in Java Example . . . yes, we can use the language to do it public class EnCapso { private String fName; private String lName; private int age; private double salary; EnCapso (String fn, String ln, int a, double s) { this.fName = fn; this.lName = ln; this.age = a; this.salary = s; } public int getAge() { return this.age; } public void setAge(int a) { this.age = a; } public double getSalary() { return this.salary; } public void setSalary(double num) { this.salary = num; } public String getName() {return this.fName + " " + this.lName;} public void raiseSalary(double inc) { this.salary += inc; } }

Encapsulation in Java Example . . . but, we don t have to do it public class NoCapso { String fName; // public since not declared private String lName; // public int age; // public double salary; // public NoCapso (String fn, String ln, int a, double s) { this.fName = fn; this.lName = ln; this.age = a; this.salary = s; } public int getAge() { return this.age; } public void setAge(int a) { this.age = a; } public double getSalary() { return this.salary; } public void setSalary(double num) { this.salary = num; } public String getName() {return this.fName + " " + this.lName;} public void raiseSalary(double inc) { this.salary += inc; } }

Encapsulation in Java Can reach into the object even with getters setters, etc. public class EncapDemo { public static void main (String[] args) { EnCapso pEN = new EnCapso("Anne", "Smith", 27, 23456.78); NoCapso pNO = new NoCapso("Mark", "Jones", 45, 45678.91); System.out.println("Encapsulated object, Class EnCapso "); System.out.println(pEN.getAge()); //System.out.println(pEN.age); // cant do it due to encapsulation pEN.raiseSalary(15000.00); //pEN.salary = pEN.salary + 21000.00; // cant do it, cant reach in System.out.println(pEN.getSalary()); //System.out.println(pEN.salary); // cant do it System.out.println("Non Encapsulated object, Class NoCapso "); //System.out.println(pNE.getAge()); // the correct way, call public getter System.out.println(pNO.age); // wrong, reaching into object pNO //pNO.raiseSalary(21000.00); // correct way, call a public method pNO.salary = pNO.salary + 21000.00; // wrong, reaching into object pNO //System.out.println(pNO.getSalary()); // correct way, call public getter System.out.println(pNO.salary); // wrong, reaching into object pNO } }

Killing Modularity in Java public class EncapDemo { public static void main (String[] args) { EnCapso pEN = new EnCapso("Anne", "Smith", 27, 23456.78, 15.50); // register hours worked for (int i=1; i<=6; i++) { pEN.addDay(i*2); } // get pay info System.out.println(pEN.totHours()+" hours"); // good way System.out.println(pEN.totPay()+" dollars"); /* // bad way to get pay info double nHours = 0.0; for (int d=0; d<pEN.nDays; d++) { nHours += pEN.hours[d]; } double totPay = nHours * pEN.rate; System.out.println(nHours+" hours worked"); System.out.println(totPay+" dollars paid"); */ } }

Killing Modularity in Java public class EnCapso { private String fName; private String lName; private int age; private double salary; double[] hours; //double hours = 0.0; int nDays; double rate; EnCapso (String fn, String ln, int a, double s, double r) { this.fName = fn; this.lName = ln; this.age = a; this.salary = s; this.hours = new double[31]; this.nDays = 0; this.rate = r; } public double totHours() { double tot = 0.0; for (int i=0; i<this.nDays; i++) { tot += this.hours[i]; } return tot; //return this.hours; } public double totPay() { return this.totHours() * this.rate; } public void addDay(double h) { this.hours[nDays] = h; nDays++; //hours += h; nDays++; } public int getAge() { return this.age; } public void setAge(int a) { this.age = a; } public double getSalary() { return this.salary; } public void setSalary(double num) { this.salary = num; } public String getName() { return this.fName + " " + this.lName; } public void raiseSalary(double inc) { this.salary += inc; } }

More failings in OO Concurrency will be increasingly critical Moore s Law is dead and multi-core is defacto the rule PLs must manage safe (correct) concurrent algorithms and this is intellectually difficult compated to single thread programming OO models and PLs have lacked concurrency at the outset and this is being added Java threads, e.g. Some computation models presume concurrency, it is inherent and not add-on ( Actor ) Functional model is maturing, is useful OO structure being added to functional PLs Multi-paradigm languages adding functional capabilities to OO structure

END END