Why encapsulation? why private? Why scopes?

[Kuberr24]

One thing I never understood when learning programming is why make everything private? What's the use of a scope? When are there advantages to using this?

I don't see the advantage of making it so certain parts of your code cannot acces other parts of your code because they're private. Why not make everything public and not risk you accidently try to acces something that you can't.

 

[kingkingyyk3]

Advantage :

scope a
    globals
        private integer ABIL_ID = 'A000'
    endglobals
endscope
scope b
    globals
        private integer ABIL_ID = 'A001'
    endglobals
endscope

 

[Jesus4Lyf]

It's a way to make things "behind the scenes". If you encapsulate, you know for sure what can change what. It helps with debugging, for example, and making sure there is a single source of truth for various things. For example, you could use the GetBonusDamage for a bonus system, or if there was no encapsulation, you could get it directly. If the implementation changed, your code would break. That's why people create a clear, assigned interface instead of letting people read/write whatever values where they feel like it (no encapsulation).

Example:

library lib
    struct x
        integer count
        static method operator [] takes unit u returns thistype
            return thistype(GetUnitUserData(u))
        endmethod
        method modify takes integer i returns nothing
            set this.count=this.count+1
        endmethod
        method get takes nothing returns integer
            return this.count
        endmethod
    endstruct
    function Add takes unit u, integer i returns nothing
        call x<u>.modify(u)
    endfunction
    function Get takes unit u, integer i returns nothing
        return x<u>.get()
    endfunction
endlibrary</u></u>

This is a classic. You have no reason to use Add, or even .modify(), because you could just use x[unit].count. Well, what if internally, you wanted to change it to store the integer in a hashtable, because Blizzard breaks structs somehow or because you want the count to be relevant to not the unit but the owner of the unit? With encapsulation, it is easy because there is a single source of truth for the functions (change the above to make the struct private, and the "count" member private also).

 

[TheDamien]

One thing I never understood when learning programming is why make everything private? What's the use of a scope? When are there advantages to using this?

I don't see the advantage of making it so certain parts of your code cannot acces other parts of your code because they're private. Why not make everything public and not risk you accidently try to acces something that you can't.

The idea is that your code should be segregated into distinct units, which expose their functionality through a consistent interface and hide the implementation details from other parts of the program. By ensuring that other parts of your code will only ever depend on the interface, you are free to change the implementation of a struct or library without breaking existing code.

 

[kingkingyyk3]

        call x<u>.modify(u)
</u>

Unable to change a unit into integer.

 

[Nestharus]

Another reason is naming. You don't want to muddle up your environment with a billion names. Keep the environment clean and simple and the code will be that much more maintainable.

 

[Vexorian]

One thing I never understood when learning programming is why make everything private?

This is about the worst mistake programming teachers make and it is quite a horrible one. You don't make everything private. I've had programming teachers tell me that all of a class' attributes should be private and all the methods public, it is bullocks. That's not encapsulaltion. It is lame-o-stuff, because then they will end up going with getters-and-setters and make the whole thing useless. Or they will make a method public even though it is just a subroutine of something else that the user should never bother calling.

The point of encapsullation is to hide implementation details as much as possible from the people using your program. This should be a philosophy in all parts of the program and not just the "private keyword". Why is it? Because the more implementation details you expose to users, the harder it will get to update your stuff later.

 

[Zwiebelchen]

Imagine a factory production line full of machines. Machine 3 is broken and you want to fix it.
And now imagine, that all controls, sensors and measurement systems are concentrated in the control room.

You might argue, that you have a better overview like that, but that isn't so bright in that situation. You get confused by all those switches and monitors and have almost no chance to find the real source of the problem.

And now, imagine that every machine has its own controls. You know machine 3 is broken, step up to it and check only those things that are related to your machine. You will find the problem much easier and faster than with a "public" control room.


I hope that analogy helped. It's the same with encapsulation. The more data you have accessable, the less overview you have.

 

[Frozenhelfir]

I mostly just use private in JASS so I can re-use names, such as ABIL_ID

 

[Hatebreeder]

Well, for crucial things, like systems that globally influence your game, like a custom Attribute Systems or some Battle Engage Systems, I make them librarys and make everything which is influencable, such as funtions that like "Radius" and globals which Dynamically increase/decreases like "CountPlayers" are made public.

Everything else which the systems itself should ONLY be using I make private.

Though, I don't do this for Spells.
For spells it's OK to use scopes and make everything private, unless you want to make some crazy linked spells, which each depend on each other. Then you are most likely bound to public.

Anyways, all I am saying is, that you should find what suits you best.

 

[weaaddar]

You don't make everything private. I've had programming teachers tell me that all of a class' attributes should be private and all the methods public, it is bullocks. That's not encapsulaltion. It is lame-o-stuff, because then they will end up going with getters-and-setters and make the whole thing useless

Not true. The point behind something like::

private MyObj _obj;

public MyObj obj
{
get{
return _obj;
}
set{
_obj = value;
}
}

Is because if you have code using your DLL, and the DLL changes and let say you add some logic to the getter like::

...
get{
return _obj ?? _obj = new MyObj();
}
....

If you didn't have a getter like this and just a direct variable reference, then your code using [ljass]_obj[/ljass] would have to be recompiled. (note: this only works for languages with sensible compilation models like D,Java,C# etc, not C++ because C++ is awful).

As for Jass it helps a bit of logic, private variables can hide usage and intent. I like to keep fields private, and write a getter property. I wish you'd adopt C# style properties as that would be some great easy syntax.

 

[Anachron]

This is about the worst mistake programming teachers make and it is quite a horrible one. You don't make everything private. I've had programming teachers tell me that all of a class' attributes should be private and all the methods public, it is bullocks. That's not encapsulaltion. It is lame-o-stuff, because then they will end up going with getters-and-setters and make the whole thing useless. Or they will make a method public even though it is just a subroutine of something else that the user should never bother calling.

Are you serious? Who in the hell thinks like that?

 

[Vexorian]

Not true. The point behind something like::

private MyObj _obj;

public MyObj obj
{
get{
return _obj;
}
set{
_obj = value;
}
}

Is because if you have code using your DLL, and the DLL changes and let say you add some logic to the getter like::

...
get{
return _obj ?? _obj = new MyObj();
}
....

If you didn't have a getter like this and just a direct variable reference, then your code using [ljass]_obj[/ljass] would have to be recompiled. (note: this only works for languages with sensible compilation models like D,Java,C# etc, not C++ because C++ is awful).

As for Jass it helps a bit of logic, private variables can hide usage and intent. I like to keep fields private, and write a getter property. I wish you'd adopt C# style properties as that would be some great easy syntax.

Sounds like a technical issue caused by over optimistic compilation rather than a good reason to use a getter or setter. I'd say that's more of a language flaw...

vJass has method operators which are just that same thing. And since vJass is not subject to stuff like that. It is silly to make a getter or setter. If you ever need to replace your property field with a getter/setter you can use properties aka method operators to replace the field in your API with a method and be happy..

Are you serious? Who in the hell thinks like that?

Many programming teachers I have had in college so far. And by reading blogs out there, I am not alone...

Anyway, envapsulation = hiding implementation details. If you use those languages mentioned by weaaddar, you'll have to use getters and setters to hide the implementation details or else you'll have the issues mentioned by him. As for vJass, using getter and setters is probably just a very fancy way to obfuscate your code.... Of course, if your users only need to read a field and not to write it then you will have to use a property to make the field read-only ... Well, maybe not since there is a readonly keyword after all...

 

[weaaddar]

No this is a pretty well understood practice, and in the real world its godsend.
C# even made the sytatic sugar super duper easy::

public MyType MyObj{get;private set;}

Is how you would declare an object that is "readonly" by the outside world. You can latter down the line add a backing variable and the logic behind the getter and setter.

And the point is to avoid issues. If I have assemply A and it is using assembly B, if assembly B has a direct public facing variable reference and B might change how that variable is populated based on some logic, I have to put that logic into A, and conseqeuntly whenever B changes, A must change too. If I hide that logic in B, I don't have to worry about A having to change each time I make a modification to the implementation details of B (unless i'm using C++ because its linking model is from the stone age).

Don't get me wrong, for Jass 9/10 times there is no reason to follow the pattern of private field, public operator for it. The reason might be for something related to a key in a hashtable.

e.g.

private integer m_key;

public operator Key=(integer value)
{
    RemoveSavedInteger(....,m_key);
    m_key = value
    SaveInteger(....,value);
}

This example is how you might want to rehash if a user changes the structs key. Or if the behavior is never wanted use the readonly keyword (for Vjass only), or create an operator in Zinc.

 

[Anachron]

Many programming teachers I have had in college so far. And by reading blogs out there, I am not alone...

But then, how did they get the job?

Anyway, envapsulation = hiding implementation details. If you use those languages mentioned by weaaddar, you'll have to use getters and setters to hide the implementation details or else you'll have the issues mentioned by him. As for vJass, using getter and setters is probably just a very fancy way to obfuscate your code.... Of course, if your users only need to read a field and not to write it then you will have to use a property to make the field read-only ... Well, maybe not since there is a readonly keyword after all...

Agreed.