Performance Tuning for .NET Core

Re:Performance Tuning for .NET Core by wvenable on Tuesday January 15, 2019 @04:12PM (#18915350)

I understand the argument for composition-of-inheritance but they rarely apply when you actually need to do it. Often it's to reach in and fix a bug or enhance the behaviour of an existing component. You simply can't do that with composition.

Without inheritance (if the class is sealed) I often end up having to re-write the entire component or simply accept my fate. So that is a lose-lose situation.

[ Parent | on HN ]

Re:Performance Tuning for .NET Core by scarface74 on Tuesday January 15, 2019 @04:45PM (#18915715)

That's where delegation comes in. You wrap each public method of Foo in another class call MyFoo and then fix the one method you care about. With C# and R# it's a simple matter of:

Create a new class

Create a private variable:

private Foo _foo

Click on _foo

Resharper menu -> Generate Code -> create Delegating members.

[ Parent | on HN ]

Re:Performance Tuning for .NET Core by wvenable on Tuesday January 15, 2019 @06:11PM (#18916590)

But you can't pass that into places that accept Foo because MyFoo isn't of the type Foo so that's a non-starter is most cases.

Secondly this code generation solution is just re-implementing inheritance again poorly and with the above mentioned limitation. I fail to see how code generating a proxy is any way better than (or significantly different from) inheritance.

[ Parent | on HN ]

Re:Performance Tuning for .NET Core by scarface74 on Tuesday January 15, 2019 @08:39PM (#18917564)

Hopefully the code was written to depend on interfaces and not hard coded types.

[ Parent | on HN ]

Re:Performance Tuning for .NET Core by wvenable on Tuesday January 15, 2019 @09:55PM (#18917894)

So if you implement an interface and then use code generation to create proxy from a "parent class", congratulations you just reinvented inheritance. What's the difference?

[ Parent | on HN ]