Goodbye, Object Oriented Programming

The author's beef with encapsulation seems to be that when an object A is used as an argument in the constructor to object B, the latter needs to do a deep copy (as keeping a pointer is not "safe"), which is of course not always possible.

I'm at a loss as to what this has to do with encapsulation, and even less able to understand how any language with user-defined data types is going to be able to avoid it.

Languages with immutable data structures?

> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library.

Like react?

It's a great video, and clearly the design behind Swift has tried to address many of the biggest problems with modern OOP. But Swift is by necessity a multi-paradigm language that has to interface with existing OOP code.

If you're writing a Mac or iOS app, you're generally writing Cocoa with either Swift or ObjC syntax. Cocoa is unbearably stateful. For a simple app, you not only don't get to work with value types, you typically don't even get functions or methods which return anything.

Obviously for something more complex, your non-UI code can absolutely be written with the principles described in that video in mind, but if you try to apply those principles to Cocoa APIs directly, you're going to be fighting against its stateful nature constantly.

Regarding:

Class Copier { Scanner scanner; Printer printer; function start() { printer.start(); } }

---

Placing a Start() in a PoweredDevice base class doesn't make sense in the real world. There are plenty of "powered devices" that don't have start buttons. A phone, a fish tank pump, a smoke alarm, none have a "start." A powered device should have just that, a PowerOn() and PowerOff() or SetPower(bool isOn). I wouldn't even create a PoweredDevice base class unless you have a reason. This is the main fault in your design.

Scanner.Start() should return a byte[] which is the result of the scan: byte[] Scanner.Start(); A scanner is an input device.

Printer.Start() should take an argument of byte[] as to what it is to print: void Printer.Start(byte[] byteArr); A printer is an output device.

Having said that, your Copier class would look like this:

  Class PoweredDevice
  {
     void SetPower(bool isOn)
     {
       ...
     }
     // Start() doesn't belong here.
  }

  Class Copier : PoweredDevice
  {

    Scanner scanner;
    Printer printer;

    void override SetPower(bool isOn) {
        printer.SetPower(isOn);
        scanner.SetPower(isOn);
        base.SetPower(isOn);
    }

    void Start()
    {
        byte[] document = scanner.Start();
        printer.Start(document);
    }
  }

This can easily be enhanced to handle copy counts:

    void Start()
    {
        byte[] document = scanner.Start();
        for (int x = 0; x 

Ideally you wouldn't even make an inheritable Start() method. The Scanner class would have a byte[] Scan() method and the Printer class would have a Print(byte[] byteArr) method. You're trying to ram a square peg into a round hole. Use inheritance when it is convenient and makes sense to do so. Don't force it. Think, what does a scanner and a printer have in common that works the same, then put that in your base class. A power button is about it.

A lot of inheritance is done backwards. You make your classes then find commonalities and put that in your base class. Only create a base class first if you've thought about your object model and you know the commonalities.

Also, there is no reason to make your inheritance chain deep, just because. Build your objects in a way that makes sense. Don't write code or base objects you will never use. You can always insert a class in the chain when necessary.

Mastering OOP is hard, and people who have mastered it get paid a lot of money for their skill. It took me a few years to really understand how to design with it. It's invaluable though. A good object model is a thing of beauty, and a hell of a lot of fun to design.

Edit: I don't know why the editor won't keep the CR's.