Is it fair to say that a Java programme is structured as follows ?
PACKAGES contain CLASSES contain OBJECTS contain VARIABLES.
The variables interact with Variables in other Classes through Methods ?
No, not really.
First of you have packages - they can contain other packages or classes.
Each class can contain inner classes, fields (which are instances of classes or native types), static members, etc.
An object contains fields (not variables since some may be final) and methods.
Object instances (final or not) have methods which may have an effect on them or the input or some global state.
Dont try to over-simplify it - it is not very complicated but it is neither thiiiis simple.
Related
which one is best and efficient way to organize query, mutation and subscription class?
Partial class
[ExtendObjectType(OperationTypeNames.Query)]
others?
And what is the difference, what is happening behind the scenes?
In this official docs
If we just want to organize the fields of one of our types in different files, we can use partial classes in the Annotation-based approach.
But in workshop ExtendObjectType is used
I have also asked the same question here
With partial classes nothing special is happening behind the scenes as it's just a regular C# feature.
Its downsides are that they can not be used across assemblies and you can't replace or remove fields that where defined in another partial class.
Type extensions on the other hand are being merged with the original type definition by Hot Chocolate. They work across assemblies and allow you to hide or replace members of the original type definition.
As you've quoted from the documentation, partial classes are easier to use if you just want to split your type definitions into different files within the same project. For a more Hot Chocolate integrated way of combining these multiple files (classes) Type Extensions should be used.
In OO languages like C++, Java or C#, there are access modifiers like public, private, protected. Some languages have other modifiers like internal. All of them specifies who can access a certain variable or method. And for variables, this term access means both the ability to read and modify. But the most common scenario for accessing variable is making it publicly visible to others but keeping the ability to modify within the class. And this is achieved through many tactics using getter setter etc.
My question is, why don't we have a access modifier for the most common scenario, which can be named something like visible? Then the variable marked with it can be read by external classes or methods. But can only be modified within the class.
Your suggestion would encourage the implementation detail of how the state is represented within the class to be made public.
Using one level of indirection - properties - allows you to separate out the public API of a type from its implementation. That can be of great benefit:
You can make when a value is computed, e.g. lazily populating some data
You can change how a value is stored, e.g. via delegation to some other type
You can rename the implementation details without worrying about breaking callers
I'm all for languages making it easier to expose read-only state (as C# 6 is doing with read-only automatically implemented properties, for example) but I wouldn't encourage the fields themselves to become more visible.
I am new to ASP.Net MVC. I have a couple of controllers and models. They all use a set of static functions and constants which I call common code.
In my MVC project I have folders for Controller, models and view etc,
Where is all the common code supposed to be put ?
Is is OK to create a Common folder and create new class for my static functions and same for global constants ?
If you reuse this common code often across solutions, you might want to consider compiling it into its own class library and simply referencing the assembly.
Another thing you'll want to consider is the nature of the common functions. Are they truly just helper functions (like manipulating strings and stuff like that) or do they make more sense mixed into your business layers?
Basic rule is to keep it organized be consistent. There's no right or wrong way to structure your application...only hundreds of thousands of opinions.
Exactly you can create Helper folder when you set your extension methods or another common utility.
But for constants suggest you to create Ressource File
Remarks : All text , warning or info messages, put theses elements in ressource and don't write in code, for gloabalization need(It's my case on project)
I know that you can create new classes in R, but why would you want to? I've thought of two reasons:
You can use the is. function to test whether an object belongs to a particular class (classifications of objects)
To only allow certain classes of entries into slots of an object (e.g., only a string for the surnmane and only a number for a zip code in the person class).
I haven't thought of situations where these benefits couldn't be achieved fairly easily by other means or when they'd really be useful.
I hope that this isn't too open ended and more concrete examples how one might use defining classes would be great. Thanks for any thoughts.
Its called Object-Oriented programming. Look it up, but in short:
Objects encapsulate behaviour - eg the behaviour of the 'print' method for a class is specific to that class. You can then keep the code for that method on that class separate from other code. You then only have to tell your users to "print" the thing - which is something they already do - and they get a nicely custom printed version of your thing, without having to use a special print function, like "printMyThing(thing)".
Objects inherit behaviour from their parent classes - eg the 'formula' method for the glm class falls back to the formula method for the lm class (not sure if this is true, but its just for illustration.
In short, its a Good Thing.
Question:
Is there a static way to reliably determine the type contained by a type derived from CollectionBase, using Reflection or Microsoft.Cci?
Background:
I am working on a code generator that copies types, makes customized versions of those types, and converters between. It walks the types in the source assembly via Microsoft.Cci. It prints out source code using textual templates. It does a lot of conversion and customization, and tosses out code that I don't care about.
In my resulting code, I intend to replace List<T> everywhere that a CollectionBase, IEnumerable<T>, or T[] was previously used. I want to use List<T> because I am pretty sure I can serialize it without extra work, which is important for my application. T is concrete in every case. I am trying not to copy CollectionBase classes because I'd have to copy over the custom implementation, and I'd like to avoid having to do that in my code generator.
The only part I'm having a problem with is determining T for List<T> when replacing a custom CollectionBase.
What I've done so far:
I have briefly looked at the MSDN docs and samples for CollectionBase, and they mention creating a custom Add method on your derived type. I don't think this is in any way enforced, so I'm not sure I can rely on that. An implementor could name it something else, or worse, have a collection that supports multiple types, with Object as their only common ancestor.
Alternatives I have considered:
Maybe the default serialization does some tricks that I can take advantage of. Is there a default serialization for CollectionBase collections, or do you generally have to implement it yourself? If you have to do it yourself, is there some reliable metadata I could look at in order to determine the types? If it supports default serialization, does it rely on the runtime types of the items in the collection?
I could make a mapping in my code generator of known CollectionBase types, mapped to their corresponding T for List<T>. If a given CollectionBase type that I encounter isn't in the list, throw an exception. This is probably what I'll go with if I there isn't a reliable alternative.
I'm still not sure enough about what you want to do to give advice. Still, do your CollectionBase-derived classes all implement Add(T)? If so, you could look for an Add method with single parameter of type other than object, and use that type for T.