.NET Megathread 3.5: await GetGoodPosts()

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›299 »

spiderlemur: Nov 6, 2010

Ithaqua posted:

1) You wouldn't mock the Person class, you'd mock the repository that returns them. Then you'd construct those Persons that you're using for your test however you want. Yes, you'll need to add interfaces and use standard DI techniques to provide an instance (whether it's a mock implementation of your Repository or a real one) at runtime. If the property isn't relevant to your test, leave it as null or default. If your Person object touches the database, that's bad. Don't do that.

In general, once you know the typical techniques for unit testing, the statement, "This is hard to test" is almost always followed by "...because it's badly designed". The answer to "How do I unit test this?" then becomes "Fix the bad design." Sometimes that requires working with what you have and writing some awful integration tests to give you a safety net while you're fixing the design. That's okay.

2) I don't use EF frequently.

I think your first question kind of answers the second one. The person class does touch the database, it's a 1:1 with the table itself (so is every single model object). Should intermediate objects be built to separate things from what a database happens to be storing? If we have a Person model and a Person database table, should they give any fucks about how they're related to one another? I think we're kind of Frankensteining this separation into ViewModels (ViewModels have hard calls into the Repository) which leads into the fuckery of the View being exposed to way more data than it needs and more importantly something that's impossible to test when it's written that way.

Good info on mocking/DI. Kind of what I figured and right now it's not really possible to mock the Repository without a redesign, but thankfully it's being heavily considered. Need some better practices going forward. Currently trying to learn that bit. I don't know how to fix the bad design yet without creating more bad design.

spiderlemur fucked around with this message at 06:07 on Aug 30, 2016

# ? Aug 30, 2016 05:53

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 22:19

spiderlemur: Nov 6, 2010

Kind of a separate question: Is there any point to integration tests (and/or using poo poo like Selenium), or can everything more or less be covered with good unit testing?

In a perfect world I see myself creating a mock repository, creating my controller and injecting it that repository, then see what comes out of the other end by inspecting the ViewData on the Controller properties.

# ? Aug 30, 2016 06:11

amotea: Mar 23, 2008; Grimey Drawer

spiderlemur posted:

I think your first question kind of answers the second one. The person class does touch the database, it's a 1:1 with the table itself (so is every single model object). Should intermediate objects be built to separate things from what a database happens to be storing? If we have a Person model and a Person database table, should they give any fucks about how they're related to one another? I think we're kind of Frankensteining this separation into ViewModels (ViewModels have hard calls into the Repository) which leads into the fuckery of the View being exposed to way more data than it needs and more importantly something that's impossible to test when it's written that way.

This was a good question IMO. You ran into something most teams only run into when it's too late and their codebase has gotten very hard to maintain. A popular solution that's currently in vogue is Domain Driven Design (DDD).

I haven't had the chance to try it myself yet, but one of its points is that you shouldn't share one big model of a Thing throughout the codebase. Instead, make a separate model for every different conceptual context you need to use the Thing in (they call this a BoundedContext). A lite version of this can be found in MVVM where some say you should always create a new ViewModel if you need to use a Model in a View (instead of just using the Model).

Read more about it e.g. here: http://martinfowler.com/bliki/BoundedContext.html

In practice it should also help to model your domain better and e.g. enforce restrictions in some situations but not in others. (After spending some time with F#'s discriminated unions I found out that properly modeling the domain is half the work in creating solid code.)

# ? Aug 30, 2016 10:37

Bognar: Aug 4, 2011; I am the queen of France; Hot Rope Guy

No particular order here, I'm just responding to things as I find them:

spiderlemur posted:

The person class does touch the database, it's a 1:1 with the table itself (so is every single model object).

I think there's a terminology mismatch here. Does your Person class have code inside of it that explicitly accesses the database? Or is that that Entity Framework accesses the database in order to construct your Person object? In the latter case, we wouldn't typically say that the Person class interacts with the database.

spiderlemur posted:

Isn't EF going to grab every property of every object (a lot of table joins) on that Person when I really only care about one? It seems bad because a lot of information is being passed into the View when I only use or care about 2% of it in the page.

Entity Framework will get every property that exists in the Persons table. That means all primitives and complex types that belong to the Person class. It will *not* automatically join other tables unless you explicitly tell it to (with a .Include() call). If you are accessing navigation properties (other tables) from the Person class without calling .Include() then you are doing something called lazy loading, where EF transparently goes to the database and asks for the object at the point you try to access it (after the initial query).

spiderlemur posted:

I think we're kind of Frankensteining this separation into ViewModels (ViewModels have hard calls into the Repository) which leads into the fuckery of the View being exposed to way more data than it needs and more importantly something that's impossible to test when it's written that way.

This is bad. ViewModels should be very dumb classes that only hold data (or just know how to construct themselves given other data). The Controller should be responsible for building the ViewModel, including all the data access required in doing that (or delegating data access to a Repository), and then passing it to the View. For your own sanity, the View should have no way of introducing an additional database call.

spiderlemur posted:

Is there a better pattern I can be using for returning minimal amounts of data rather than huge complex objects and the queries associated with them?

If you know exactly what properties you want out of the EF model, you can project them into another type and EF is smart enough to build a simpler SQL query. For example:

C# code:

var viewModels = db.Persons
    .Where(p => p.Name.StartsWith("J"))
    .Select(p => new PersonViewModel
        {
            Id = p.Id,
            Name = p.Name,
        })
    .ToList()

would roughly translate to

SQL code:

SELECT Id, Name
FROM Persons
WHERE Name LIKE 'J%'

# ? Aug 30, 2016 14:51

spiderlemur: Nov 6, 2010

Sounds like a big step in the right direction would be to make the Repository mockable, have it return ViewModels directly more often for page specific stuff (sometimes returning the full model object and making the ViewModel in the controller is more useful so we could re-use that method, such as something like "GetPersonById()"), and remove all data accessing logic from those ViewModels.

Biggest hindrance in making that Repository class mockable is the hard tie-in with Identity Framework. The repo is initialized automatically from a base class that each controller inherits from which calls GetUserId() to setup some permissions inside the Repository and it's LINQ queries.

# ? Aug 30, 2016 15:31

Opulent Ceremony: Feb 22, 2012

spiderlemur posted:

Biggest hindrance in making that Repository class mockable is the hard tie-in with Identity Framework. The repo is initialized automatically from a base class that each controller inherits from which calls GetUserId() to setup some permissions inside the Repository and it's LINQ queries.

There's nothing hard about mocking that, we have the same setup. Just make the property that you attach the Repository in your base controller an interface that your EF DbContext Repo class also implements. Have the constructor for the base controller instantiate the EF one. Then make a separate unit test project, where you have a fake Repo class that also implements the same interface and write your unit tests against that.

# ? Aug 30, 2016 15:51

smarion2: Apr 22, 2010

Not sure if this would be the right thread for this but has anyone messed with Microsofts CNTK at all? It looks pretty cool and my new job asked me to look into it to try to correct some bad data. Feeling a bit overwhelmed at the moment but I'm sure its not so confusing once you study the documentation for awhile. Any advice for someone with no experience in neural networks?

https://github.com/Microsoft/CNTK/wiki/Tutorial

# ? Aug 30, 2016 15:56

Destroyenator: Dec 27, 2004; Don't ask me lady, I live in beer

amotea posted:

Something like this http://fsharp.org/specs/component-design-guidelines/ ?

I didn't know about that one, thanks!

spiderlemur posted:

Kind of a separate question: Is there any point to integration tests (and/or using poo poo like Selenium), or can everything more or less be covered with good unit testing?

In a perfect world I see myself creating a mock repository, creating my controller and injecting it that repository, then see what comes out of the other end by inspecting the ViewData on the Controller properties.

If you're just newing up the controller you don't have any guarantees that the app will successfully start up, routing, injection, model binding or anything else in the pipeline will do as you expect.

This post is little old but is still very doable and I think aspnet core is going to encourage more of this: https://blogs.msdn.microsoft.com/webdev/2013/11/26/unit-testing-owin-applications-using-testserver/

Setup the first time is a little trickier because you have to work out how to manage injecting your mocks and stuff, but I think it can be a useful midway point between simple controller tests and full blown UI tests.

# ? Aug 30, 2016 16:00

ljw1004: Jan 18, 2005; rum

Asymmetrikon posted:

Thanks, that did the trick. It seemed weird to me that something that sounded like a standard library namespace would be in Nuget and not just built-in.

Asymmetrikon, just to say, thanks again for your example of SqlClient. The type will remain in NuGet for sure (since the future of .NET is for it to be broken up into small components on NuGet to let you produce minimal binaries). But what's needed is for ctrl+dot to bring up the quickfix of "add using statement and NuGet reference" so it'll be as easy to add as it always was. I've been able to use your example of SqlClient to hammer home the need for through the VS/.NET team, and it is a compelling example!

(the other point of view is that we want VS itself to be minimal and lightweight, and so any extra functionality comes under intense scrutiny...)

ljw1004 fucked around with this message at 22:01 on Aug 30, 2016

# ? Aug 30, 2016 21:54

ljw1004: Jan 18, 2005; rum

NihilCredo posted:

Right now, Visual F# itself is an optional checkbox in the installation, so people who hear about F# have to first go back and install it.

For the next version of VS we're radically overhauling the installer. The idea is that lots of people don't care for the vast amount of stuff that VS does, and if they can get by with a 500mb install of VS (rather than 5gb) then they'd be happy to. https://www.visualstudio.com/en-us/news/releasenotes/vs15-relnotes

Notwithstanding the minimal goal, for now we've made F# a preselected checkbox. Let's see how that goes.

quote:

If you want more people to try out F# - and I'm firmly convinced it's such a charming language that that's all it needs to succeed - this is where I'd start:
- Integrate all the features of F# Power Tools into the basic Visual F# package, or include it as part of the same installation
- Make the Visual F# Package automatically included in all of the following Visual Studio components: Web Development, .NET Desktop Development, Mobile Development with F#. Also UWP Development, once the work on .NET Native support is finished.

We're steadily adding more F# features. Something at the moment is a rewrite of the F# language service to be built off the same project system stuff as C#/VB. That will give several things for free (colorization, debugging services, intellisense filtering, ...) and make other things easier. Here's some of the work in progress: https://github.com/Microsoft/visualfsharp/blob/roslyn/vsintegration/src/FSharp.Editor/ColorizationService.fs#L46

All of this should provide a much more solid foundation for the F# Power Tools too.

# ? Aug 30, 2016 22:01

Mr Shiny Pants: Nov 12, 2012

That sounds really good, I am not sold on all the modules though.

I don't mind a 1GB install on my 256GB SSD, I do mind the SQL stuff though, that always installs services on the system which the languages do not do.

# ? Aug 31, 2016 07:51

Che Delilas: Nov 23, 2009; FREE TIBET WEED

spiderlemur posted:

Kind of a separate question: Is there any point to integration tests (and/or using poo poo like Selenium), or can everything more or less be covered with good unit testing?

In a perfect world I see myself creating a mock repository, creating my controller and injecting it that repository, then see what comes out of the other end by inspecting the ViewData on the Controller properties.

Integration tests can expose problems with things like third party services or strange database states that you wouldn't see if you are just mocking those calls. Also, they're another layer of safeguard - if all your unit tests pass but an integration test fails, you're going to jump all over that to find out why. If it was a sneaky bug that you didn't have a unit test for, you're going to write one if it's possible and be drat grateful the integration test was there.

My approach in an ideal world would be the pyramid; extremely thorough unit tests that are run all the time, integration tests for common code paths that would run less often (nightly, maybe?), and end-to-end tests for the most common user operations that would run before release (Gotta make sure that bigwig client can still log in after you optimize that ostensibly unrelated algorithm).

Also, I think these things are easier to appreciate when you stop thinking of the time they're costing you when you're creating them. When you write two modules and unit test the poo poo out of them right then, going back over and writing integration tests to verify their interaction seems like overkill. But after you've added a hundred more modules around those two, and not touched those original two for 14 months and suddenly need to make a change, those additional layers of tests will feel like the additional safety nets they are.

# ? Aug 31, 2016 09:53

ModeSix: Mar 14, 2009

ljw1004 posted:

For the next version of VS we're radically overhauling the installer. The idea is that lots of people don't care for the vast amount of stuff that VS does, and if they can get by with a 500mb install of VS (rather than 5gb) then they'd be happy to. https://www.visualstudio.com/en-us/news/releasenotes/vs15-relnotes

This is pretty sexy. I can't wait for the actual release of this. Will be nice to trim it down from a 27GB install, that takes close to 1.5 hours to complete, to just what I actually need.

# ? Aug 31, 2016 11:59

RICHUNCLEPENNYBAGS: Dec 21, 2010

Ithaqua posted:

1) You wouldn't mock the Person class, you'd mock the repository that returns them. Then you'd construct those Persons that you're using for your test however you want. Yes, you'll need to add interfaces and use standard DI techniques to provide an instance (whether it's a mock implementation of your Repository or a real one) at runtime. If the property isn't relevant to your test, leave it as null or default. If your Person object touches the database, that's bad. Don't do that.

In general, once you know the typical techniques for unit testing, the statement, "This is hard to test" is almost always followed by "...because it's badly designed". The answer to "How do I unit test this?" then becomes "Fix the bad design." Sometimes that requires working with what you have and writing some awful integration tests to give you a safety net while you're fixing the design. That's okay.

2) I don't use EF frequently.

It's going to be really cool when Entity Framework has the in-memory provider and you don't have to futz around with pointless interfaces just for tests IMO.

# ? Sep 1, 2016 00:44

Gul Banana: Nov 28, 2003

it's already done! EF Core is missing some features but in-memory works fine

# ? Sep 1, 2016 00:53

22 Eargesplitten: Oct 10, 2010

Is this use of this.foo a bad practice?

code:


var foo;
public void setFoo(foo)
{
     this.foo = foo;
}

My teacher used to do that, but her best practices were way out of date.

# ? Sep 5, 2016 19:33

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

22 Eargesplitten posted:

Is this use of this.foo a bad practice?
code:
var foo;
public void setFoo(foo)
{
     this.foo = foo;
}
My teacher used to do that, but her best practices were way out of date.

public object Foo { get; set; }

Properties are more terse ways of expressing the same thing; the compiler creates the backing field and the get/set methods.

Using this to disambiguate a property or field from a local variable is fine.

# ? Sep 5, 2016 19:36

22 Eargesplitten: Oct 10, 2010

Why would you use an object rather than a property there? How would that even work? It seems like you would have to create a property inside of that new object.

This is where C# deviates from Java, I guess?

# ? Sep 5, 2016 19:59

jony neuemonic: Nov 13, 2009

22 Eargesplitten posted:

Why would you use an object rather than a property there? How would that even work? It seems like you would have to create a property inside of that new object.

This is where C# deviates from Java, I guess?

Maybe I'm misunderstanding your question, but "object" is the type of the property in that example. What Ithaqua posted is C#'s sugar for auto-implemented properties.

Give this a read.

# ? Sep 5, 2016 20:18

22 Eargesplitten: Oct 10, 2010

Okay, that makes more sense. For some reason I was thinking that the code was trying to get a property from within an instance of a class without naming the property. I didn't think of having a private object that you would need to use a getter and setter to access.

Is object like var, but for objects rather than standard variables?

# ? Sep 5, 2016 21:34

Dirty Frank: Jul 8, 2004

22 Eargesplitten posted:

Okay, that makes more sense. For some reason I was thinking that the code was trying to get a property from within an instance of a class without naming the property. I didn't think of having a private object that you would need to use a getter and setter to access.

Is object like var, but for objects rather than standard variables?

object is the base class of every other object, if you define a class like:

code:

class Foo
{
}

Its base class is implicitly object.

var is just for convenience, it means something like "whatever type you say afterwards", so if you write:

code:

var aFoo = new MyNameSpace.SexyThings.Foo();

code:

var aFoo = MethodWhichReturnsAFoo();

then var is a stand in for MyNameSpace.SexyThings.Foo, basically the compiler figures out what the most specific Type it could be is.

# ? Sep 5, 2016 21:45

Bognar: Aug 4, 2011; I am the queen of France; Hot Rope Guy

var is only used with type inference. That is, where the compiler can figure out what type you mean without having to explicitly tell it. For example, all of these pairs are the exact same code when compiled:

C# code:

string str = "some string";
var str = "some string";

List<int> list = new List<int>();
var list = new List<int>();

object is an explicit type in the type system that every other type inherits from. All of these are not the same code when compiled:

C# code:

string str = "some string";
object str = "some string";

List<int> list = new List<int>();
object list = new List<int>();

The end result is that this is valid:

C# code:

var str = "some string";
var length = str.Length; // compiler knows that str is of type string

while this is not:

C# code:

object str = "some string";
object length = str.Length; // compilation error - str is an object type which does not have a Length method

e:f;b

e2: also, var is not valid outside of a function. So your above example with a private variable specified with var is invalid.

Bognar fucked around with this message at 21:49 on Sep 5, 2016

# ? Sep 5, 2016 21:47

raminasi: Jan 25, 2005; a last drink with no ice

This is more of a tooling question, but does anyone know the most sane way to get git submodules to play nice with Visual Studio? The particular problem I'm having is with NuGet: Package restore puts the packages in the main repo packages dir where the submodules can't find them. (Maybe "add the submodule projects to the main repo solution" isn't the way to go here?)

# ? Sep 6, 2016 00:30

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

raminasi posted:

This is more of a tooling question, but does anyone know the most sane way to get git submodules to play nice with Visual Studio? The particular problem I'm having is with NuGet: Package restore puts the packages in the main repo packages dir where the submodules can't find them. (Maybe "add the submodule projects to the main repo solution" isn't the way to go here?)

Specify an explicit package path in nuget.config.

# ? Sep 6, 2016 00:42

Neitherman: Sep 25, 2006; _{He will die without safety brief.}

I want to develop a small web application in VS2015 Enterprise. According to the OP the best option for doing this is creating an ASP.Net MVC application. Is this still the case? If so, what is a good resource or tutorial for someone with a little web development experience (I've developed some small POC applications using a Tornado/MySQL/Bootstrap stack) but no experience with web development using Microsoft standards?

# ? Sep 6, 2016 06:18

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

Neitherman posted:

I want to develop a small web application in VS2015 Enterprise. According to the OP the best option for doing this is creating an ASP.Net MVC application. Is this still the case? If so, what is a good resource or tutorial for someone with a little web development experience (I've developed some small POC applications using a Tornado/MySQL/Bootstrap stack) but no experience with web development using Microsoft standards?

http://asp.net :v:

The MVC project template in VS is pretty solid depending on your needs - it'll scaffold a simple set of components that you can then tinker with or modify as necessary.

# ? Sep 6, 2016 15:21

jony neuemonic: Nov 13, 2009

Neitherman posted:

I want to develop a small web application in VS2015 Enterprise. According to the OP the best option for doing this is creating an ASP.Net MVC application. Is this still the case? If so, what is a good resource or tutorial for someone with a little web development experience (I've developed some small POC applications using a Tornado/MySQL/Bootstrap stack) but no experience with web development using Microsoft standards?

Pick either ASP.NET MVC or ASP.NET Core MVC and do the MVC Movie tutorial:

http://www.asp.net/mvc/overview/getting-started/introduction/getting-started (ASP.NET MVC)

https://docs.asp.net/en/latest/tutorials/first-mvc-app/index.html (ASP.NET Core MVC)

It's not a great tutorial (I'd love to see something as in-depth as Michael Hartl's Rails tutorial) but it'll get you touching most of the bits of a basic ASP.NET application. If you don't have any reason to pick one over the other, go with Core. It's got some nice improvements over the older version and the documentation is better organized (if a little unfinished).

# ? Sep 6, 2016 15:22

ljw1004: Jan 18, 2005; rum

raminasi posted:

This is more of a tooling question, but does anyone know the most sane way to get git submodules to play nice with Visual Studio? The particular problem I'm having is with NuGet: Package restore puts the packages in the main repo packages dir where the submodules can't find them. (Maybe "add the submodule projects to the main repo solution" isn't the way to go here?)

I think the most sane way is to switch over to project.json to list your NuGet dependencies (rather than project.config that you're using now).

You can use project.json to express NuGet dependencies for any project type. https://blogs.msdn.microsoft.com/lucian/2015/08/19/using-project-json-for-other-project-types/

Modern profiles (like UWP and .NETCore) solely use project.json for their NuGet dependencies.

In the future, the ability to specify NuGet dependencies in a sane way will get added to .csproj. At that time you'll have a choice between project.json and csproj for listing your NuGet dependencies. Both approaches will be sane and supported. So you're not losing anything by switching to project.json now.

Note that some packages don't work in the new sane manner... (1) the "new sane way" won't execute install scripts that are part of nuget packages, since they're inherently insane. (2) some nuget packages might need to shuffle files into different directories because of a break in NuGet.

# ? Sep 6, 2016 16:08

Neitherman: Sep 25, 2006; _{He will die without safety brief.}

jony neuemonic posted:

Pick either ASP.NET MVC or ASP.NET Core MVC and do the MVC Movie tutorial:

http://www.asp.net/mvc/overview/getting-started/introduction/getting-started (ASP.NET MVC)

https://docs.asp.net/en/latest/tutorials/first-mvc-app/index.html (ASP.NET Core MVC)

It's not a great tutorial (I'd love to see something as in-depth as Michael Hartl's Rails tutorial) but it'll get you touching most of the bits of a basic ASP.NET application. If you don't have any reason to pick one over the other, go with Core. It's got some nice improvements over the older version and the documentation is better organized (if a little unfinished).

Sounds good. I don't have much in the way of constraints when creating this app (other than it must use a COM object to access data on the backend) so I'll go with the Core version. Thanks!

Edit: NEVERMIND I DID NOT READ THE INSTRUCTIONS I AM AN IDIOT PLEASE IGNORE

Neitherman fucked around with this message at 16:58 on Sep 6, 2016

# ? Sep 6, 2016 16:38

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Neitherman posted:

Sounds good. I don't have much in the way of constraints when creating this app (other than it must use a COM object to access data on the backend) so I'll go with the Core version. Thanks!

Edit: NEVERMIND I DID NOT READ THE INSTRUCTIONS I AM AN IDIOT PLEASE IGNORE

I can't confirm this but I would expect that you'll have problems getting COM interop to work with .NET Core, if you can get it to work at all.

# ? Sep 6, 2016 17:21

Zero The Hero: Jan 7, 2009

ljw1004 posted:

For the next version of VS we're radically overhauling the installer. The idea is that lots of people don't care for the vast amount of stuff that VS does, and if they can get by with a 500mb install of VS (rather than 5gb) then they'd be happy to. https://www.visualstudio.com/en-us/news/releasenotes/vs15-relnotes

Notwithstanding the minimal goal, for now we've made F# a preselected checkbox. Let's see how that goes.

I hope that grid layout is going to be optional, I like the tree structure in the current installer. It's very well organized.

# ? Sep 6, 2016 17:50

22 Eargesplitten: Oct 10, 2010

Is it bad to have multiple levels of inheritance? For example:

code:


abstract class Ship
{
      int health = 1;
      float speed = 1;
}

class EnemyShip : Ship
{
       //blah
}

class FastShip : EnemyShip
{
       public void FastShip()
       {
              speed = 1.5;
        }
}

Or should I just have FastShip inherit Ship? Assume EnemyShip has variables shared by FastShip.

Actually, is there a common best practices standard like Google's standards for Java?

# ? Sep 6, 2016 18:29

EssOEss: Oct 23, 2006; 128-bit approved

Best practice is to avoid inheritance and only do it if you really really have to. Most people tend to horribly misuse it before they know what they are doing. Are you sure you wouldn't be happier with composition instead? Almost certainly so!

Instead of EnemyShip, maybe you have Ship.Faction that is an enemy object. Instead of FastShip, maybe Ship.MotionModel defines some fast parameters. And so forth. All you need is a Ship class, with maybe an IShip interface for some architectural separation (better API boundaries and simpler tests due to easy mocking capability).

# ? Sep 6, 2016 18:35

raminasi: Jan 25, 2005; a last drink with no ice

EssOEss posted:

Best practice is to avoid inheritance and only do it if you really really have to. Most people tend to horribly misuse it before they know what they are doing. Are you sure you wouldn't be happier with composition instead? Almost certainly so!

Instead of EnemyShip, maybe you have Ship.Faction that is an enemy object. Instead of FastShip, maybe Ship.MotionModel defines some fast parameters. And so forth. All you need is a Ship class, with maybe an IShip interface for some architectural separation (better API boundaries and simpler tests due to easy mocking capability).

I agree with all of this but to directly answer the question: There is nothing inherently wrong with multiple levels of inheritance like that.

# ? Sep 6, 2016 18:38

Horn: Jun 18, 2004; Penetration is the key to success; College Slice

raminasi posted:

I agree with all of this but to directly answer the question: There is nothing inherently wrong with multiple levels of inheritance like that.

I don't agree with this, if all you're changing are the initial values of common members than inheritance doesn't add anything except some code complexity. If you had a Ship and a FastShip that behave in fundamentally different ways (ie not just faster, stronger) then inheritance is worthwhile.

# ? Sep 6, 2016 18:47

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

I assume you're working on a video game. This great article talks about (among other things) how the programmers behind Starcraft painted themselves into a corner due to overuse of inheritance: http://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft

I know next to nothing about video game programming, but I think these days a more compositional approach is usually preferred, similar to what EssOEss is suggesting: https://www.raywenderlich.com/24878/introduction-to-component-based-architecture-in-games

But unless you're planning to make some huge codebase it probably doesn't matter too much. Just do it in the way that feels most comfortable, and along the way you'll probably discover the strengths and weaknesses of the approach you took.

# ? Sep 6, 2016 18:53

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

raminasi posted:

I agree with all of this but to directly answer the question: There is nothing inherently wrong with multiple levels of inheritance like that.

There's nothing inherently wrong with it, but this is something I've commonly seen:

BaseFoo : DerivedFoo : DoubleDerivedFoo : ... : SuperSpecificFoo

You need to add a field that most properly belongs on "BaseFoo" because it describes some fundamental aspect of Foos, but you really only need it on SuperSpecificFoo at the moment. Architecturally it would make sense to put it on BaseFoo.

Someone says "No, it's way too risky to modify BaseFoo, it's used everywhere!"

# ? Sep 6, 2016 19:37

22 Eargesplitten: Oct 10, 2010

Reading about composition rather than inheritance, that makes a lot of sense in a lot of ways. And I will be using the shots as component objects.

On the other hand I'm doing something really simple, a remake of this game from my childhood: https://youtu.be/i6FnNY0tyGU

I'll keep components in mind, but I'm not sure there will be much opportunity for those beyond the shots, models, and textures.

In this case, would interfaces really be the best idea? The only objects will be four types of ship including yours, two types of shots (yours and enemies'), and the blocks you fly around. It seems like it would be better to use a parent class since you can just write up the methods in that parent class rather than having to write out the majority of the methods for each individually.

Why would inheritance be best for implementing completely different behavior? It seems like that's where it would help the least. The different behavior I can think of would be more aggressive pathfinding, although that should wait until I have something that works.

Sorry if this stuff is obvious, I haven't been in school for a while and I only got to the classes where they introduced inheritance and interfaces in my last semester.

# ? Sep 6, 2016 19:52

biznatchio: Mar 31, 2001; Buglord

LOOK I AM A TURTLE posted:

I assume you're working on a video game. This great article talks about (among other things) how the programmers behind Starcraft painted themselves into a corner due to overuse of inheritance: http://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft

Inheritance isn't inherently bad, you just have to design your taxonomy very carefully because if you let it grow naturally, you end up doing absolutely awful things shortsightedly that hamstrings you later on. The Starcraft example shows inheritance for the sake of it, without any apparent rhyme or reason to it. Why are game units inherited from the class created to show particles? In what world does that make sense?

I suspect the answer to that question would be something like "Well, you see particles were the only sprites that could move on the map on the time, and game units need to move, so it was easiest to just inherit from the particle class..."

Any justification for inheritance that includes the words "...it was easiest to just..." is a big red flag because it implies there was a better solution but instead of sticking to proper design, corners are being cut and technical debt is being piled on.

# ? Sep 6, 2016 20:45

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 22:19

Neitherman: Sep 25, 2006; _{He will die without safety brief.}

Ithaqua posted:

I can't confirm this but I would expect that you'll have problems getting COM interop to work with .NET Core, if you can get it to work at all.

I tried adding a reference to my COM DLL and VS yelled at me. It said I'd have to create a NuGet package or something to be able to reference the DLL. Considering this DLL is not one that either me or my company have authored I don't think it's wise to go down that road. Guess I'll just stick to the ole heavyweight ASP.NET stuff.

# ? Sep 7, 2016 02:26

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›299 »