Object Oriented Programming really an Advantage

[Alain De Vos]

oop is one pararadigm. the other is funcfional. Both together. So oopme up with scala or fsharp running on a virtual machine.

 

[ralphbsz]

1) May be it is a SLAC report?

No, it's a book: small, bound, available in book stores. But you made me look in the high energy physics search engine (now known as INSPIRE, it used to be SPIRES), and while I find lots of publications about related topics (SPEAR, SSRL, accelerator control, control system programming ...), none about objects, and none with a name that rings a bell. And I know that I was never a co-author on any paper with the author of the book ... one of the things that ended my career at SLAC was that I had no interest in what is called "machine physics", the art and science of building and operating accelerators. I was always an instrumentation and data analysis person.

I'll keep looking.

 

[vmisev]

oop is one pararadigm. the other is funcfional. Both together.

That’s what Ivan Čukić is preaching

 

[mer]

That’s what Ivan Čukić is preaching

At the lowest level, isn't OOP functional? Object methods that implement something like read a register, increment a value, I think is fundamentally "functional".
I've found thinking in OOP lets me deconstruct/derive the overall requirements, regardless of how the code is actually written.

 

[Barney]

What I am saying is that C++ is not an object-oriented language anymore.

Solitaire was AI back in the day....

 

[bgavin]

I’m such a dinosaur.
I use a class for encapsulation but never used inheritance. No need.

 

[mer]

I’m such a dinosaur.
I use a class for encapsulation but never used inheritance. No need.

I've found it depends highly on the problem you are solving.
Having the knowledge to know when "not to" do something is as important as knowing "when to".

I've seen stuff at $JOB where a class needed a timer but someone wrote it as "inheriting from a timer". Ok, not so bad, but then "class needs timer of type A and timer of type B so multiple inheritance from A and B. Oh and since the timer classes have the same method names like start, stop, how do I make sure which inherited start I am calling or overriding"
Yeah stupid stuff.

 

[Alain De Vos]

There are interfaces to avoid mulitple inherintance.

 

[ralphbsz]

There are interfaces to avoid mulitple inherintance.

Same problem. Timer X is an interface that uses methods start() and stop(). Timer Y uses methods start() and stop(). If class A wants to "implement interfaces" X and Y, the resulting code will be difficult to read, since every time start() or stop() are used it needs to be disambiguated.

In this case, it's just easier for class A to contain two timer objects, instead of inheriting from them, or implementing them.

 

[astyle]

I always got lost in stuff like 'inheritance polymorphism' and when it's possible to override a method or variable that was inherited from a parent class and when it's not. Sometimes I'd get compiler errors because I tried to override a variable that was declared 'private static void'...

 

[kent_dorfman766]

Same problem. Timer X is an interface that uses methods start() and stop(). Timer Y uses methods start() and stop(). If class A wants to "implement interfaces" X and Y, the resulting code will be difficult to read, since every time start() or stop() are used it needs to be disambiguated.

In this case, it's just easier for class A to contain two timer objects, instead of inheriting from them, or implementing them.

When to subclass vs when to instantiate traits is a major field of discussion in OO programming. Never let either path become your religious dogma. I've been on the fence for years about whether multiple inheritence should be allowed. I rarely end up using it, and some languages don't allow it at all.

But yes, some classes scream "inherit me" but the practicality of doing so leads one down the rabbit hole. Timers and Threads are such beasts.

 

[JohnK]

NOTE: I haven't gotten a chance to read all the messages in this thread just yet.

For fun, object orientation with sbcl,

other/tut30_clos/test.lisp · master · Alain De Vos / sbcl_tut · GitLab

GitLab.com

gitlab.com

Interesting!

Although not good at reading Lisp and all the dialects (I did do quite a bit in a CAD lisp dialect and some Scheme) it looks as though 'balance' is accessible by any procedure. The typical OOP bank account operations are "withdraw" and "deposit", whereas 'balance' is a local state to the account object itself and not an object (this is where the fun begins). If you start coding up a way for the account to keep track of the 'balance', management of the account becomes easier and more "black-box-ish" and you may see what I mean.

Also, note; what I find interesting with the "message passing" aspect of OOP is how easy it is to NOT account for unknown methods (aside from the obvious design implications--how functions are implemented--in a 'message passing' methodology). -i.e. In the typical "function" method you typically just don't code up the unsupported methods. However, I think the "functions as return" method is a bit more elegant because you can just create a wrapper function (with the use of a simple COND in this lisp case) which acts an API of sorts for your object -i.e. ship the wrapper function and another programmer knows how to use your object.

The object (account) is shown below as a list:

;; functions returned as messages
(define w1 100)
> (w1 . 100)
((w1 'withdraw) 50)
> (w1 . 50)
((w1 'withdraw) 75)
> "Insufficient funds"

;; functions only
(define w2 100)
> (w2 . 100)
(make-deposit 20 w2)
> (w2 . 120)
(make-withdraw 150 w2)
> "Insufficient funds"