My understanding of the term "namespace" is essentially that of a class; a container of methods and variables. Although that seems to be doubling up on what I consider to be the definition of a class.
Can someone confirm or clarify that belief?
I would say a namespace is a way of logically grouping symbols (classes, functions, ... depending on the exact language you're working with) in a container that ensures that those symbols don't collide with other symbols (which could have the same name) in other namespaces.
Namespace is mainly used for avoiding name conflicts. Suppose if you a class named A but this class may be defined by others . so in this cases you need to separate your class from others. In that instance Namespace is come to act. For eg: you given namespace 'using yourname ' in this name space you defined a class A. so that this class can be distinguished by yourname.A. similary for methods ,variables all thing you can defined in your own namespace.
A namespace is used to have different programming rules in the same program module. Let's say you want to define the function 'string_addition' to mean 'string1' + 'string2' = 'string1string2', but later in the same program you want to define 'string_addition' to mean 'string1' + 'string2' = 'string3'. You can use namespaces, so that in the same file you can call on the different namespaces and get both kinds of rules.
namespace h:stringadd(string1, string2) = string1string2
namespace f:stringadd(string1, string2) = string3
a namespace provides a context for an identifier you are referring to. So in that sense, a class is also a namespace.
In the general sense, a namespace defines a set of names which are unique. In other words, a name is only unique within a namespace.
As this concept applies to different languages, there are many variants that include issues like encapsulation, namepsacing, scope and so on.
A namespace is the domain in which a given name remains unique. For example you may define many classes named Widget but they must all appear within seperate domains to be uniquely identifiable from one another.
The domain in which a name appears depends upon the context in which it is defined. For example in the .NET world, a class name must be unique within a namespace, which itself must be unique within an assembly, so one could say that the domain in which a class name is unique is a namespace and the domain of a namespace is an assembly
Namespace is a group of classes. It becomes a .dll after compilation. So we can add that .dll file to our project and can easily use those classes.
Namespaces aren't a feature of OOP. Specify a programming language.
And, yes, in general they are similar to classes, but only those classes which contain no non-static members (since a namespace couldn't be instantiated to form an object).
Related
I have the following Namespace with 2 functions in it that I want to use, but I'm not sure how I access them?
I tried importing ("using" for C#) but those 2 functions arent in the namespace.
Do I have to create a class and create those functions myself?
The weird thing is, those 2 functions are found within a different namespace:
Regardless of where it is, how would I turn these into functions I can call from my code?
When I try to access those functions in my code, they don't know up :
I think you're getting a bit confused. It's understandable with namespaces.
Gds.GoogleMap.UltimatePlus.Math.Mathservice is not a namespace name. The namespace name is Gds.GoogleMap.UltimatePlus.Math . MathService is the class name.
If you put the statement
using Gds.GoogleMap.UltimatePlus.Math;
at the top of your file then all you need to do to declare a new object is to say:
MathService myService = new MathService();
assuming it has a default constructor.
Give it a try.
I am studying OWL and I am trying to build an Ontology using Protege.
I found an option called Equivalent To in Protege.
What is that option for please? Is it for dividing the space of instances? or is it to set the Object properties that a class can have?
Equivalent to applies to class expressions, object properties and data properties.
Equivalence in class expressions
In class expressions, equivalence means that two classes have the same individuals in any interpretation (i.e., the two classes are alternate names, or equivalent definitions, for the same set of individuals).
Equivalence in data and object properties
For object and data properties, asserting that two properties are equivalent means that their domains and ranges apply to both properties, and that every assertion using one property can be rewritten as using the other.
Example
For example, suppose I declare a hasOwner object property and an ownedBy as equivalent, then: MyCar hasOwner Me implies MyCar ownedBy Me.
According to wikipedia
Dependency is a relationship that shows that an element, or set of elements, requires other model elements for their specification or implementation.[1] The element is dependent upon the independent element, called the supplier.
So is it not the same as unidirectional association?
Do we use dependency when an operation in one class uses object of the other class as its parameter?
How are unidirectional association and dependency different.
Any example would be very helpful
Dependency :
Indicates that a client element(of any kind, including classes,
packages, use cases, etc) has knowledge of another supplier element,
and a change in supplier can effect the client.
So "dependency" is very broad relationship.Suppose that if a class-object(client) has another class-object(supplier) as a member,if a class-object send a message to another class-object,if a class-object takes another class-object as an parameter from its methods, even if a class(client) is subclass of another class(supplier) there will be dependency since change from supplier will effect clients.
Technically all of those relationships can be shown by "Dependency" line. But some of above relationships already has special notations: such as for superclass-subclass relationship we have generalization relationship.No need to show also "dependency" line because if they have generalization relationship, they have dependency. And we have "association" relationship for class-object(client) who has another class-object as a member [attribute]. So also no need to show extra dependency line in this situation.
Actually "Dependency" is badly defined relationship for class diagrams. But it can be usefull for showing dependency in which UML has no special notation such as :
if you has another class-object(supplier) as a parameter in one of your class(client) methods
if you have dependency to global variables
when you call static methods on another classes.
local variables (which you think you have important dependency)
public class RepositoryManager
{
public UpdatePriceFor(ProductDescription description)
{
Time date = Clock::GetTime();
Money oldPrice =description.GetPrice();
...
}
private IList<Item> itemsList = new List<Item>();
}
So all "associations" are also shows "dependency".But "dependency" is
broad-general-weak relationship.As a rule if there is a special
relationship which is more specific-stronger than dependency
relationship than use it. And lastly use all your relationship
"economically". Show only important ones based on modeler-model reader
perspectives.
[ Source : Adapted from Craig Larman's Applying UML and Patterns book ]
Check Fowlers bliki for further information DependencyAndAssociation
Association means that the two associated entities are linked semantically. Dependency only declares that there is a... well, dependency of some sort. All associations are dependencies, while a dependency does not actually mean association. For example, class 'A' depends on class 'B' if it has a method that takes 'B' and passes it as argument to a function in another class. But if 'A' calls some method of class 'B', it should be modeled as association.
Disclaimer I have read the UML specification and also asked myself this question a number of times. I arrived at at the definition above, but I'm still not sure it is 100% correct.
Please have a look at the following question: What's the naming convention for classes in the DataAccess Project?
JDK talks about using Namespaces to separate the Data Logic Layer and the Business Logic Layer and not to use Hungarian notation to name interfaces e.g. IPersonDAL for the data access layer. I have followed the recommendations of this answerer in the code below:
Imports com.app.BusinessLogicLayer.Interfaces
Imports com.app.DataLogicLayer.Interfaces
Namespace BusinessLogicLayer
Public Class Order
Implements com.app.BusinessLogicLayer.Interfaces.IOrder
Public Sub Insert()
Dim IOrder As com.app.DataLogicLayer.Interfaces.IOrder = New com.app.DataLogicLayer.Order
End Sub
End Class
End Namespace
Namespace DataLogicLayer
Public Class Order
Public Sub Insert()
End Sub
End Class
End Namespace
Namespace BusinessLogicLayer.Interfaces
Public Interface IOrder
End Interface
End Namespace
Namespace DataLogicLayer.Interfaces
Public Interface IOrder
End Interface
End Namespace
Classes in the business logic layer e.g. Order implement interfaces (IOrder from Business Logic Layer) and use interfaces (IOrder from Data Logic Layer) i.e. the presentation layer communicates with the Business Logic Layer and the Business Logic Layer communicates with the data logic layer with interfaces. Notice that because of this reason; interfaces have to be fully qualified with the namespace. For this reason; isn't it better to name interfaces using hungarian notation e.g. IPersonBLL and IPersonDAL or am I missing something?
Well, this is a subjective topic, but here goes...
Firstly, avoid abbreviations like DAL. Code Analysis yells about acronyms and abbreviations; you're supposed to write it out. In my experience it's wise advise. Opening up ancient code that's full of abbreviations causes a lot of unnecessary WTF moments (pun intended).
Even when spelling things out, when you have 50 classes sitting in your BusinessLogic folder like this:
Company.Product.BusinessLogic
PersonEntity
OrderEntity
MaterialEntity
EmployeeEntity
CustomerEntity
etc.
My gut tells me it's time to refactor. I feel it's better to move the Entity tag to the namespace, so you have this:
Company.Product.BusinessLogic.Entity
Person
Order
Material
Employee
Customer
etc.
Same things applies to interfaces.
This also makes it easier to refactor. If I want to start calling my Entities "BusinessObjects", I just have to rename the namespace, not the class names and file names.
It can be a pain to qualify your class names, but you normally only have to specify the parent namespace, not fully-qualify them. Resharper -> Cleanup Code does wonders here.
In summary, I would not add Hungarian notation to my interface/class name just to make references easier to deal with.
Update: Example
Data Access Layer:
Namespace Company.Product.DataAccess.Adapter
Public Class Product
End Class
End Namespace
Business Layer:
Imports Company.Product.DataAccess
Namespace Company.Product.BusinessLogic.Entity
Public Class Product
Dim adapter As New Adapter.Product()
End Class
End Namespace
User Interface (ideally your UI should only interact with the business layer, never with the data layer directly):
Imports Company.Product.BusinessLogic
Namespace Company.Product.UserInterface.Webpage
Public Class Product
Dim productEntity As New Entity.Product()
End Class
End Namespace
Notice that because of this reason; interfaces have to be fully qualified with the namespace. For this reason; isn't it better to name interfaces using hungarian notation e.g. IPersonBLL and IPersonDAL or am I missing something?
I see what you are saying, but I don't understand why fully-qualifying the names is bad or why it would be "better" to name the interfaces using "Hungarian" notation. (And I say this as a truly unrepentant fan of Simonyi's apps Hungarian.)
Remember that regardless of the names and locations of the classes/interfaces, the compiler is going to produce the same object code. The apparent nesting level is not going to "slow down" your code to any perceptible degree.
If it really bothers you to type out the names (and Intellisense is of no consolation), you can always use something like a namespace alias with a using directive. But I'd be careful with overusing these—I think it makes the code even harder to read.
If I have a view with two or more words, e.g.:
public function actionApprovalQueue()
what is the naming convention of the view file itself?
approval-queue.php
approvalQueue.php
approvalqueue.php
??
The documentation on Conventions only says:
View files should be named after the view name. For example, the index
view is in the index.php file.
which gives no clue about views with two or more words.
When it comes to naming conventions, it comes down to what suits your organisation, or what is followed in your organisation, or what the rest of your team decides. The key is consistency throughout your code base.
I would say go with the dash(hyphen), because variables are generally named $xyzAbc or $xyz_abc. So it would make sense to use approval-queue.php.
Definitely do not go for approvalqueue.php.
Edit: Read more about Yii's conventions here.
Yii recommends naming variables, functions and class types in camel case which capitalizes the first letter of each word in the name and joins them without spaces. Variable and function names should have their first word all in lower-case, in order to differentiate from class names (e.g. $basePath, runController(), LinkPager). For private class member variables, it is recommended to prefix their names with an underscore character (e.g. $_actionList).
Because namespace is not supported prior to PHP 5.3.0, it is recommended that classes be named in some unique way to avoid name conflict with third-party classes. For this reason, all Yii framework classes are prefixed with letter "C".
A special rule for controller class names is that they must be appended with the word Controller. The controller ID is then defined as the class name with first letter in lower case and the word Controller truncated. For example, the PageController class will have the ID page. This rule makes the application more secure. It also makes the URLs related with controllers a bit cleaner (e.g. /index.php?r=page/index instead of /index.php?r=PageController/index).