OO is not all that and a bag of chips

[Nelek]

TLDR; Most excesses are bad.

M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

[Greg Utas]

I think I see what you're getting at. Is there an example that you can point to? If I'm guessing correctly, it would probably fit in well with what Sutter suggests in Virtuality[^]. If every virtual function is private and invoked by a non-virtual function that is public, that provides a place to add pre- and post-code. But it would certainly have some limitations.

Robust Services Core | Software Techniques for Lemmings | Articles

[Greg Utas]

sickfile wrote:

Do it in OOP and you will make it big.

You might have a lot of boilerplate, which is a PITA but not "big". It would be big if, say, functional programming was a much better fit for the problem.

Quote from Kevlin Henney:

"Once you reach a particular size, anything beyond that is no longer a reflection of functionality."

It's often true that inside a big system, there's a small system struggling to get out. But as a blanket statement, this quote is just a platitude.

sickfile wrote:

The Facebook iOS app has over 18000 classes. How do you compare it to Quake 3 that can render 30FPS of a 3D world on Pentium 3?

18000 classes is a joke. But you can't compare it to the portion of a game that renders graphics, which is highly algorithmic and doesn't require much OO, although your point might be that this wouldn't stop some people from trying to do it that way.

Robust Services Core | Software Techniques for Lemmings | Articles

[realJSOP]

Software failure isn't caused by the tools or paradigms used to develop it - it's cased the the programmers not doing it right.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

[Slacker007]

#realJSOP wrote:

it's caused by the the programmers not doing it right.

exactly.

[Nelek]

Greg Utas wrote:

although your point might be that this wouldn't stop some people from trying to do it that way.

as in IoT... only because you can, doesn't mean you should :rolleyes: :-D

M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.

[Sander Rossel]

I have a Console application that disagrees :D

using System;

namespace ConsoleApp1
{
class Program
{
static void Main()
{
IMessageGetter messageGetter = new BoohCodewitchMessageGetter();
IMessagePrinter messagePrinter = new ConsoleMessagePrinter();
IInputAwaiter inputAwaiter = new ConsoleInputAwaiter();
string message = messageGetter.GetMessage();
messagePrinter.PrintMessage(message);
inputAwaiter.AwaitInput();
}
}

public interface IMessageGetter
{
    string GetMessage();
}

public interface IMessagePrinter
{
    void PrintMessage(string message);
}

public interface IInputAwaiter
{
    void AwaitInput();
}

public abstract class BaseMessageGetter : IMessageGetter
{
    public abstract string GetMessage();
}

public abstract class BaseMessagePrinter : IMessagePrinter
{
    public abstract void PrintMessage(string message);
}

public abstract class BaseInputAwaiter : IInputAwaiter
{
    public abstract void AwaitInput();
}

public class BoohCodewitchMessageGetter : BaseMessageGetter
{
    public override string GetMessage() => "Booh codewitch, your opinion sucks!";
}

public class ConsoleMessagePrinter : BaseMessagePrinter
{
    public override void PrintMessage(string message) => Console.WriteLine(message);
}

public class ConsoleInputAwaiter : BaseInputAwaiter
{
    public override void AwaitInput() => Console.ReadKey();
}

}

Best, Sander sanderrossel.com Migrating Applications to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly

[honey the codewitch]

*headdesk*

Real programmers use butterflies

[honey the codewitch]

sickfile wrote:

We don’t have a mathematical model for OOP

That's an extremely good point. To be fair, as I've said elsewhere on the thread I use OO in places - like if I expose an API to whatever i'm writing that will often be OO. And I tend to use OO here and there for other reasons when I'm stuck in a hard OO env like Java or C# I limit its use though: 1. Does it help explain the code? 2. Does it work with the rest of the code rather than against it? 3. Does it encapsulate an abstraction such that it makes it simpler to employ? There are so many times when the answers to those questions are no, and I see people using objects. See @SanderRossel's console app upthread - he was ribbing me but it's a good example of class misuse.

Real programmers use butterflies

[honey the codewitch]

Nelek wrote:

as in IoT

You mean my wifi enabled AI toaster is overkill? :-D

Real programmers use butterflies

[honey the codewitch]

I didn't intend to imply otherwise, despite the overarching topic. I switched gears.

Real programmers use butterflies

[honey the codewitch]

I'd have to dig up some of old code off of my one drive if it's there. i wasn't using github until more recently. People usually don't describe it the way I do. It's a technique I picked up while doing research into making a rather ambitious business integration system with COM+ like features. Someone demonstrated cross cutting functionality using the Curiously recurring template pattern - Wikipedia[^] It gave me one of those aha moments, and since, whenever I see a CRTP like above, i half expect it. Dr. Dobbs has an article about doing cross cutting but they don't use generic programming to do it. <h1>Aspect-Oriented Programming & C++</h1> | Dr Dobb's[^] But if you poke at it you can see there's opportunities for factoring into a template

Real programmers use butterflies

[honey the codewitch]

fair enough. it just seems like a popular thing to do in this case. i see it all over with .NET projects.

Real programmers use butterflies

[honey the codewitch]

also CS is only somewhat engineering. It's half voodoo. :laugh:

Real programmers use butterflies

[Greg Utas]

It will be when someone hacks into it to burn your house down. :laugh:

Robust Services Core | Software Techniques for Lemmings | Articles

[Greg Utas]

"We don't have a mathematical model for OOP" sounds like a lament from a formal methods fanboi, in which case the objection can be ignored.

Robust Services Core | Software Techniques for Lemmings | Articles

[honey the codewitch]

heh. I look at this way - if we don't have a mathematical model for it then we're limited in the sorts of transformations we can do the code. Why would anyone want to transform code? A compiler does just that. A mathematical model lends itself to rigorous checking as well. I'm not a purist about it, but I certainly see the advantages of it and it's one of the reasons I'm fond of functional programming.

Real programmers use butterflies

[Sander Rossel]

That code is uber 1337! :D But usually... TL;DR: I agree with your post. The long version: I tend to write a bunch of interfaces (as necessary) that explain the function of the code. Take, for example, an IUserRepository. When I see a (ASP.NET Core) Controller being injected with an IUserRepository I know this Controller does something with users. I don't know (or care) where the users come from, but I know I need them. If you look at the specific code that uses the IUserRepository you'll find stuff like userRepository.GetUser(id), which is way more descriptive than some code that accesses a database. So in that sense, I often use classes and methods to describe what my code is doing. That, for me, and to lesser extent re-use of code, are the biggest pros of OOP. I'm not a big fan of re-use anymore. Back in the day I re-used all the things, but just because two pieces of code incidentally need the same results doesn't mean they do the same thing. I now make a clear split of functional re-use and technical re-use. Functional re-use is rare, because that would mean a user has two ways to do the exact same thing. It happens, but not all that often. I think I write my code less "OOP" than seven or even five years ago. The OOP I still write is more architectural in nature (like I now make heavy use of DI and interfaces, but not so much of base classes and such). I've written some simple programs in Haskell, a purely functional language, but I think that doesn't work all that well. It comes natural to think in objects and to have side effects at some point. Nevertheless I started to write more functional in my OOP code, mostly no side effects. I'm pretty sure my bug-to-code ratio went down since I've employed the no side effects approach. A function just does its thing and produces a result, but it won't affect the overall flow or state of the program. All the results come together in the calling function, mostly a controller, and then I do all the side effects in one spot. Makes the code a lot easier to read and you have a lot less to think about. It's still OOP, so it doesn't always work like that, but I try when I can. Another change in my code is the use of delegates instead of one-function interfaces. Makes for less abstraction and classes and it's still easy to read. The biggest game changer for me, and this saved me a lot of bugs, was when I started to use curly braces for one line if and loop statements though :D

Best, Sander

[Daniel Pfeffer]

honey the codewitch wrote:

I'm glad we don't build bridges and skyscrapers.

We've been building physical structures for thousands of years, and writing software for less than 80. Architecture and civil engineering are obviously more mature disciplines than software engineering. Assuming civilization survives, I am certain that our software development efforts will be viewed by future engineers in the same manner that the builders of mud huts are viewed by modern civil engineers. (But we do build some very impressive mud huts! :-\ )

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.

[Greg Utas]

Software techniques will undoubtedly improve, but there are things from 45 years ago that I don't find primitive. I think software will always be difficult because, unlike engineers, we continually evolve existing products and, unlike mechanics, we repair them while they are up and running.

Robust Services Core | Software Techniques for Lemmings | Articles