I want to design a system that a user can define class, object, attribute and value flexibly and objects can bound to class(es) then get attributes of class and then have values for each attribute.
I want to set multiple value for some attribute for example if an object has 2 phone number for 2 place (phone and number are attributes of Location Class) I want to know that which phone is for which place for 1 object? What is the best designing?
My design is like bellow:
Class: Id, Name
Object: Id, Name
ClassObject: Id, ClassId, ObjectId
Attribute: Id, Name, ClassId
Value: Id, ClassObjectId, AttributeId, Value
Answer to your design question:
In order to associate the phone and place you have to use an additional class "place" and give the attribute "phone" to class "place". An instance of class "location" may have 2 instances of class "place".
This requires that you have another two tables:
"link": Id, SourceId, TargetId,RelationId
"relation": Id, SourceClassId, TargetClassId, Name
Btw. Your metamodel is interesting: it is very flexible by allowing an object to belong to multiple classes.
Hence you can express:
Object "Arnold Schwarzenegger" belongs to classes: BodyBuilder, Immigrnt, Actor, Book Author, Businessman, Politician.
On the other hand you have no inheritance / subtype relationship between classes.
It seems that you have no explicit value type declaration in your attribute definition.
Related
I need to make an inherited class from a base class with a selected variable.
for example,
if the base class have 3 variable name, age, marks
but inherit class must have name and marks only
how can we do it
When designing object-oriented code, subclasses should be the specializations. The situation you describe makes the base class the specialization because it has more specific requirements than the subclass.
There is a principle called the "Liskov Substitution Principle" that says all subclasses should work where the base class works - and this wouldn't be the case as calling subclass.age would fail.
Instead, the base class should have the two common properties, and there should be a subclass that represents the extended class that represents the situation where an age would be used.
Score
Name
Marks
AgedScore extends Score
Age
The names are examples here, ideally you'd name them after what they relate to in the business domain.
When I have a class Car that represents a single car, and a class Cars that implements methods which manipulate Car objects and one of whose methods will return a Collection of Car objects, how would I "have to" name my variable that holds the instantiated Cars object?
For example:
$whatDoINameThis = new Cars;
$cars = $whatDoINameThis->getAllCars();
Since it is an instantiation of the Cars object, the intuitive name for it would be $cars, but the second variable in my code is the one that actually holds cars, so it's more intuitive if I name that one $cars.
Is there some nice and tidy, popular and agreed-upon convention as to what I should name my first variable in such cases?
Please don't mark the question as "opinion-based". I'm asking about conventions, or what is good for collaboration.
The name I use for the inner collection of a collection-like class that holds its elements is contents.
All the examples I am finding for using the AliasToBean transformer use the sessions CreateSqlQuery method rather than the CreateQuery method. They also only return the basic value types, and not any object's of the existing mapped types.
I was hoping it would be possible that my DTO have a property of one of my mapped Domain objects, like below, but I am not getting traction. I get the following exception:
Could not find a setter for property '0' in class 'namespace.DtoClass'
My select looks like the following on my mapped classes (I have confirmed the mappings pull correctly):
SELECT
fcs.MeasurementPoint,
fcs.Form,
fcs.MeasurementPoint.IsUnscheduled as ""IsVisitUnscheduled"",
fcs.MultipleEntryAllowed
FROM FormCollectionSchedule fcs
My end query will be more complex, but I wanted to confirm if this AliasToBean method can return mapped domain objects as well as basic field values from tables retrieved via sql.
the query execution looks like the following:
var result = session.CreateQuery(hqlQuery.ToString())
.SetResultTransformer(NHibernate.Transform.Transformers.AliasToBean(typeof (VisitFormCollectionResult)))
.List<VisitFormCollectionResult>();
note: the VisitFormCollectionResult DTO has more properties, but I wanted to know if I could populate the domain object properties matching the names
update found my problem! I have to explicitly alias each of the fields. once I added an alias, even though the member property on the class matched my DTO's property name, the hydration of the object worked correctly.
The answer to my own question was that each of the individual fields in the select needed an explicit alias matching the property, regardless if the field name already matched the property name of the DTO object:
SELECT
fcs.MeasurementPoint as "MeasurementPoint",
fcs.Form as "Form",
fcs.MeasurementPoint.IsUnscheduled as "IsVisitUnscheduled",
fcs.MultipleEntryAllowed as "MultipleEntryAllowed"
FROM FormCollectionSchedule fcs
This isn't really a serious OOP question, just want to get an opinion on the best way to take for my program.
Simple really: Let's say I have an employee class, and that class has the variables and methods that make up an employee.
My question is how would I store an 'employee data'(Data, not Object); It IS SIMPLE, I could just make a JOHN class that extends EMPLOYEE and add data there.
But I've read(actually not sure where) storing simple data in classes is not good?? Because if you extend a class, you should also add other functions in it.
Is there a disadvantage in the solution I proposed? Or is there a better way to 'store' data. NOTE: Assume I cannot open external files and I must add whatever Data I have in the code.
OK:
1) A "class" is a "template" for creating "objects".
A class doesn't contain any data - a class instance (a.k.a. an "object") contains data.
2) An instance of "Employee" might be an object with a member name (member data) of "John".
You wouldn't "extend" Employee to create "John"; you'd create an "object" with the name "John".
3) You might, however, extend employee for a "Manager" class.
4) To answer your original question, of course a "class" can be designed to hold "data". And every object of that class will contain that data.
This might be an odd question, but it has actually caused me some headache.
In Object oriented programming, there are accepted names for key concepts. In our model, we have classes with methods and fields. Now, going to the data world:
An instance of a class is called an object.
An instance of a field is called... what?
A value? Isn't the term value a little broad for this? I have been offered "property" as well, but isn't property also part of the model and not the data?
(This is not purely academic, I am actually coding these concepts.)
Updated: Let me take an example. I have a class "Person" with a field "age". If I create 20 Person instances, each such instance is called an object. So far so good. But let's say I take Person "Igor", and set his age to 20. What is the storage location that contains the number 20 now called? Is it a field, or a value, or something else?
Another update: A quote from Pavel Feldman in this related question describes in different words what I tried to describe above:
"I'd say that in class-based OOP field belongs to class and does not have a value. It is so when you look at reflection in c# or java - class has fields, field has type, name, etc. And you can get value of the field from object. You declare field once, in class. You have many objects with same fields but different values."
A field can't be instantiated. A field can only contain a value. The value can be either a primitive/native type or a reference/pointer to an object instance.
As per your update: if the object represents a real world entitiy, then it's often called property. With a "real world entity" I mean something personal/human, e.g. Person, Product, Order, Car, etc. If the object does not represent something personal/human, e.g. List, String, Map, then it's more often called field. That's just what I've observed as far.
Agree with BalusC. However I think what you are asking is what to call the field of an instantiated object. Remember that an object contains both state (data) and operations (methods) you could refer to an object field as state
A field is a field weather you talk about it in the context of a class, or in the context of an object.
class C {
int i; // i is a field
}
and
obj = new C();
obj.i = 7; // obj.i is a field
As opposed to parameter vs argument there is no distinction in terminology for "instantiated" an "uninstantiated" fields.
An instance of a class is an object, a class may contain fields that point to other instantiated objects (or a null pointer). It makes no sense to say an instance of a field, but rather you might talk about the object to which a particular field points to, which may be different for different instances. Or you may talk about the type of a field (which class it belongs to)
Isn't the answer basically that we have no name for values of fields of an instance of a class (or object)?
It's like giving a name to the value returned by a method of an instance of a class...
I guess "state" is the best answer anyway as suggested "BalusC".