Recent comments in /f/explainlikeimfive

Alokir t1_ixege0v wrote

Think of a class as a concept in the real world, like Dog or Animal. A class contains all data definitions and functionality necessary to work with this concept.

The functionality that relates to these concepts are called methods. For example, a Dog can bark, walk and wiggle its tail.

If you want to talk about a specific Dog you use the Dog class as a blueprint and create a dog object. Each time this happens the constructor is called automatically, which is a special method that is meant to set the initial values for the newly created object.

A struct is a way to group data together, it's easier to handle than having many individual variables.

1

lobsang_ludd t1_ixdcsy2 wrote

Struct: a bundle of data combining some set of named fields of different (potentially overlapping) types. It models an "AND" relationship between its fields, asserting that at some point in the system state they were all true together. It has no behaviour, and its data cannot be changed - although you can make a copy with a different value in a particular field.
Class: A bundle of data with behaviours. It has some set of methods that can be used to act on it, changing the data in accordance with the rules defined by its programmers. Classes can have an inheritance hierarchy, where instances of a derived class can use code from the parent class or an override method in their own class.

Constructor: A special case of the methods of a class, which is run when a new instance of the class is made. It's generally responsible for ensuring the assumptions made by other methods will be true.

2

anotherlolwut t1_ixdatkw wrote

Start with a Struct. That's the most basic part.

A Struct is kind of like an array. It's a bundle of data all stored right next to each other in memory, but it doesn't all have to be the same kind of data. You can have a character array, an int, and a float all be part of a single Struct.

My Reddit info can be represented as a Struct (though you wouldn't do it unless you were working in plain C). I have a user name (character string), a number of posts (int) and an account age (double, representing years).

A Class is like a Struct, but it can perform functions. The functions are part of the data stored in that object. Classes have done other features that Structs don't, but basically, think of it as Struct with functions.

As a Reddit user, I can make a post. You could resident this as RedditUser.makePost(). The benefit of this over just using regular functions in C is that makePost() can know the data in RedditUser, so I don't always need to pass it things like my user name.

Now, Reddit has a bunch of users. Like a dozen or so. When someone logs in and wants to make a post, Reddit has to create an object for them to gather their profile info and allow them to do stuff. It might load user profile data from a big database and read it through a Class called RedditUser. The function that does that is a Constructor, and it is part of the RedditUser Class.

Basically, RedditUser knows how to accept some set of data and assign it to the properties of the Class (the character string for my user name, the int for the number of posts I've written, etc.).

A single Class can have lots of Constructors to be ready for any kind of incoming data, like if it gets to read the big Reddit database or if I'm making a post as an unregistered guest.

2

oneeyedziggy t1_ixdasff wrote

So think of classes as representing a thing... Like pie. You can make a new pie and it's not the class itself, but it is A pie.

Constructors are like a method that runs upon making a new pie... Set the flavor, crust type, size, et cetera.

Methods are things the pie does (the metaphor is breaking down a bit, but stay with me)... A pie might have an "eat" method that subtracts from it's current amount and returns a text description of the subtle flavor notes... Or maybe a specific message for the last slice about how uncle marvin was pissdd because he was saving that piece for your aunt. (so, like a function that belongs to a class)

I'm not a C# dev so while the rest may be close enough, Imma have to just have a go at describing structs: I'm pretty sure they just typed sets of properties... Like a class without methods... Like you might instead make a pie struct (because honestly, pies probably don't need methods, they don't DO a lot, and they're probably not dynamic or complex enough to need a constructor) so then you just make a "feast" class that has a bunch of food struct-typed properties with single eat method that takes the name of a food and subtracts from its quantity

2

Zealous___Ideal t1_ixdafut wrote

Programming is tricky to explain to a 5 year old.

A class is like “all your toy trucks”

A constructor is “how does fisher-price make your trucks?”

Structs are a list of all the things on your truck: Its lights, its wheels, etc.

Methods are all the cool things your truck can do: Honk, back up, scare the dog.

5

km89 t1_ixdadxz wrote

A "class" is a group of related code, typically organized such that you can instantiate an "object". For example, you might have a Fruit class that contains all the methods and properties that a fruit can do (ripen, rot, color, etc).

A "method" is something that the object can do. As noted above, a Fruit class might have methods for ripening or rotting; these methods would contain the code necessary to manipulate the object to do those things.

A "property", which you didn't ask about but which is important, is something about the object--not something that it can do, but something about its current state. A Fruit's Color property (Fruit.Color, for example) could be set to red, or orange, or yellow, or whatever else.

Here's an example of how properties and methods can work together.

 class Program{
      public static void main(String[] args){
           Fruit banana = new Fruit(); //This calls the constructor, which currently doesn't do anything.
           banana.Color = "Green"; //Sets the Color property of the Fruit object to green.

           banana.Ripen(); //Calls the Ripen method, which for the sake of argument here changes the color

           Console.WriteLine(banana.Color); //Would write to the console the color of the fruit. 
                                                 //For the sake of argument, assume the Ripen() method 
                                                 //changes the color from green to yellow, so this would 
                                                 //write out "Yellow" to the console.
      }
 }

When you first instantiate an object, you call that object's "constructor". A constructor is a special method that contains all the logic needed to set the object up initially, before you begin to do anything with it. This will get slightly more technical, but imagine this:

 class Recipe{
      private List<string> ingredients;
      
      Recipe(){
           ingredients = new List<string>();
      }
 }

Above, the Recipe class has a private List of ingredients (and it's declared with List<string> because the List class can be of any type, so you're telling the compiler that all of the stuff in this List will be of the string data type). It's private, because nothing should be able to directly access it. But, also notice how it's not actually instantiated. The constructor, which is the one method in this class, instantiates the List object. An actually useful class would also have methods for getting and setting the ingredients, but they're not listed here.

Constructors are occasionally paired with "destructors." A destructor is another special method that handles any logic the object needs to do before it goes away. If you don't manually declare one, the compiler will put a fake one in for you, so don't worry about these unless you have to.

Structs are different from classes. They share a lot of similarities, but ultimately they're more limited and less able to change. The big difference is that they're not really objects and thus shouldn't--or can't--be changed after creating them, and they can't be used to inherit from.

Here's a good link that has a rundown of the differences between structs and classes, which I'll link rather than just typing out the differences here.

>https://www.c-sharpcorner.com/blogs/difference-between-struct-and-class-in-c-sharp

2

Phage0070 t1_ixbvg7f wrote

Your submission has been removed for the following reason(s):

Loaded questions, or ones based on a false premise, are not allowed on ELI5 (Rule 6).

If you would like this removal reviewed, please read the detailed rules first. If you believe this was removed erroneously, please use this form first. If you believe this was removed erroneously, please use this form and we will review your submission.

1

BurnOutBrighter6 t1_ixbsocp wrote

Sugar itself isn't bad for you, TOO MUCH sugar is bad for you.

For like 99.99999% of our evolutionary history, food was scarce and unpredictable. It was practically impossible to find enough calories to eat too much. Therefore, having the trait "whenever you encounter an energy-rich food source, eat as much as you can and turn any excess energy consumed into fat" was a GOOD thing. Any animals that had this trait, including our ancestors, had a survival advantage! If you craved to eat as much high-energy food as you could find, you were more likely to survive a famine, drought, injury, or illness.

On the time scale that evolution creates changes, food becoming cheap and plentiful in the modern age happened extremely recently. It's only been like ~150 years that regular non-rich people could afford enough food that it's easily possible to eat too much. To evolution, that's essentially nothing. That's a single-digit number of generations! Human evolution takes tens of thousands of years or more to produce changes.

So that's the problem: We're all still running a program in our brains that says "eat as much sugar as you can find" because that strategy gave our ancestors a survival advantage for like a billion years, and now it's backfiring for the last hundred years or so and there hasn't been time to change the program yet.

2

The_Truthkeeper t1_ixbqyze wrote

Evolution is a slow process. Your body doesn't know that it's not a hunter-gatherer barely managing to survive by hunting the woolly mammoth. Your body thinks it desperately needs every calorie it can get if you're going to build up enough fat to survive the harsh winter, and it knows sweet things are rich in calories.

3

DecafWriter t1_ixbqyfd wrote

Sugar isn't strictly bad for us. The body uses sugar for a lot of important things like being the primary source of energy in the body. Too much of anything is bad and we just tend to have too much sugar. When we have too much sugar it throws our body out of balance and can even lead to the body not producing the natural sugars that it needs.

Cravings are the body's way of telling us we need something. When you're dehydrated you crave water because you need it. Sugar is one of the main ways we get energy so the brain sends out reward signals when we ingest sugar because it wants to keep getting high-energy foods. In nature, it's difficult to get energy-dense foods like that so it wants us to keep eating more. The problem is, with modern society we've made it too easy to get processed sugar. Ultimately, it's just too much of a good thing.

3

OathToAwesome t1_ix7g5hr wrote

Although we use base 10 for most counting today, it's worth noting that base 12 shows up in a lot of ways too. It's arguably more optimal, since it allows you to divide cleanly by multiples of 2, 3, and 4, rather than just 2 and 5.

Early numbering systems used base 12, which is why you'll see things like time (60 seconds, 24 hours) or angles (360 degrees) use multiples of it, because easy divisibility is useful for those things.

1