Been doing objective-c for 5 years, so please bear with me.
I'm struggling to find documentation that clearly explains why you would want to nest a class definition, inside of another.
If I had two classes like the following, it makes sense to me that they are declared above and below each other. You may even want to have a nested property that references the other.
class DataImporter {
}
class DataGenerator {
}
But I don't understand why a nested arrangement like the following would be useful.
class DataImporter {
class DataGenerator {
} }
You would do that for Namespacing. This way you can have the classes with the same name (like DataGenerator). But for different purposes. This one would be DataImporter.DataGenerator class, but you could have another OtherClass.DataGenerator class which would be a totally different one.
Like in Objective-C when you had 2 or 3 letters before the name of the class (ex: UIView). But when you created your own, it would be like SSView
You can also declare the inner class private and use it just in that file.
Related
I missed a few CS classes, namely the ones going over topics such as polymorphism, inheritence, and abstract classes. I'm not asking you to do my homework but I have no idea where to even start to get further guidance, so giving me a skeleton or something would help me greatly, I'm so confused.
So the problem is to create an employee abstract class with two subclasses, permanentEmployee and TempEmployee.I must store information such as name,department,and salary in these subclasses and then order them according to how the user wants them ordered. I know I start out like this
public abstract class Employee
{
}
public class TempEmployee extends Employee
{
\\variables such as name, salary, etc, here?
}
public class PermEmployee extends Employee
{
\\here too?
}
but I have no idea how to store variables in there much less access them later for ordering and displaying,. Please guidance.
If all you're looking for is an example of class-level data members in Java, this should help:
public class SomeClass {
private int someInt;
public int getSomeInt() {
return this.someInt;
}
public void setSomeInt(int someInt) {
this.someInt = someInt;
}
}
Regarding polymorphism, be aware that methods are polymorphic, but values are not. As you place values and methods (getters and setters) in your base class and derived classes, I encourage you to experiment with these concepts thoroughly. Try moving the entire value/getter/setter to the base class, try moving just the value but not the getter/setter, try putting the value in both and the getter/setter in both, etc. See how it behaves.
Make sure that any value/method/etc. that you put in your base class is applicable to all derived classes. If there's ever an exception to that rule, then you would need to move that member out of the base class and into only derived classes where it applies. Note that you can have a complex hierarchy of base classes to accommodate this if needed.
When it comes time to access these members for sorting/display/etc., consuming code would use the getters/setters. For example:
SomeClass myInstance = new SomeClass();
myInstance.setSomeInt(2);
System.out.println(myInstance.getSomeInt());
I am not sure which language you working with, but as it has "extends" I am sure you are not working with c# or CSharp, it can be Java. So I would recommend you to go for TutorialsPoint. This particular article has abstraction described here.
Just to make it easy for you, in Interface and abstraction we always create a structure or the base, it has all the common things defined or declared (Obviously interface has only methods and no variables can be declared inside it).
So as said, in above example, EmployeeId, EmployeeName, EmployeeAddress ...etc should be defined in the base class that is Abstract Base class Employee, But in TempEmployee you can have a criteria such as EmpTermPeriod, EmpContractRenewalDate, EmpExternalPayrollCompanyName (Have made names long and self descriptive) and PermEmployee to have fields like EmpJoiningDate, EmpConfirmationDate, EmpGraduityDate...etc.
I hope it helps.
The documentation says
Abstract classes are essential to support Object Orientation without the typical spamming of the database with always empty auto-created clusters.
But it also says
A class that can't have instances
However, I would like to embed a list class B in class A, not have class A inherit from the abstract class B. Is this allowed?
Example:
enter code here
propVal {
locType : ""
eleName : ""
...
values :[valueStamp]
}
valueStamp {
value : any,
stamp : actionStamp
}
actionStamp{
// various attributes that say who, when, where change was made
}
Is used in many classes keeping track of changes to various fields.
They will never be used stand alone, but can't inherit because they can be used more than once in a class
Sample parent class
classA{
helperAId:"",
helperAProps : embeddedList of PropVals,
helperBId : "",
helperBProps : embeddedList of PropVals
}
Important: The class hierarchy supported by OrientDB is similar to OO principles as implemented by popular languages like Java. However, it is not the same, so there are important differences!
Yes you can embed a (list of) class(es) of type B in a class type A. This is perfectly valid and a much used construct. This is done using the EMBEDDED type.
OrientDB does not support the concept of interfaces or mixin's, just classes and abstract classes. So a class can only inherent (extend) a single parent class. In your use case I would create an abstract ActionStamp class (or whatever you name it) and let your other classes extend it.The B and A classes can both extend this ActionStamp class
So, using your example:
CREATE ABSTRACT CLASS propVal
...
CREATE CLASS A
CREATE PROPERTY A.helperAProps EMBEDDEDLIST propVal
...
Is it considered poor technique to create multiple classes in one swift file, or is it best to create a separate swift file for each class?
For example, which is better:
A. Multiple classes in ViewController.swift:
1. alpha.swift:
class alpha: UIViewController { ... }
class beta: UIWebView { ... }
class gamma: UINavigationController { ... }
B. Separate .swift files for each class:
1. In alpha.swift:
class alpha: UIViewController { ... }
2. In beta.swift:
class beta: UIWebView { ... }
3. In gamma.swift:
class gamma: UINavigationController { ... }
Short answer: it depends.
Long answer:
If you have small short classes that are strongly binded together, it's correct to put the in the same file.
If you have long, unrelated classes, then you better put them in different files.
It's not a poor technique, IF the classes are connected.
To decide if they are connected, ask: Can one class be used without the other?
If yes, then you should have two different files, since you might need to use just one of the two.
For example, in C++, collections have an inner class for their iterators. (I know it's a C++ example, but the question isn't really language related).
Though if the classes have nothing to do with each other (being on the same view doesn't count), then they should each have their separate classes.
I have different answer for this question based on painful debugging and searching in the internet for last few days. I'm c++ dev with more than 15 years experience. Coming from this language I'm familiar with few design techniques which needs protected access. Since Swift doesn't support it and as it turns out they won't support it in near future, I've start using private access and write few classes in the same file. That way I've workaround the missing protected modifier (private functions are visible in the same file, so they will be visible for all classes in the same file, and if these classes are derived classes the private is actually working as protected). Well everything is fine and I was happy before found out that my application crashed with EXC_BAD_ACCESS code=1 ... The exceptions was not because of my code, it was because it layout of the members were somehow wrong. For example if i called one function a() from the derived class through instance variable the func b() was called. The b() was also member of the same class and was define before the a(). That is why some functions thrown bad access exception. Instance pointer was corrupt. After I moved all 3 classes to independent files everything looked fine.
Not sure that this was the actual reason or I've done something wrong, but not 100% of cases when you define multiple classes in the same file will be with defined behaviour. May be that is compiler problem, Swift is young language and even that I'm testing with Gold Master studio which is supposed to be stable, there are still a lot of bugs.
I have an inherited class which i would like to point to from the base class. Example below
class Base
{
inherited* test;
};
class inherited: Base
{
};
the purpose of this is so that the base class (a character) contains a linked list of the inherited class (items)
ps apologies for any mistakes, i'm new to this site
It might be possible to trick the compiler into accomplishing this, but it's most certainly bad OOP design. If all you want to do is be able to store an instance of the inherited class but can treat it like the base class, then you can simply make inherited* test a base* test and it will accept pointers to either inherited or base (or any other subclass of base).
If you actually want base to treat that instance as inherited, you need to rethink your class hierarchy because you don't actually have an inheritance tree here.
I'm a new to scala, here's a question:
object Models {
class A1 { // some methods }
class A2 { // some methods }
}
This code works and Models seems to be treated as some sort of a scoping unit - I can import it wherever I need to. Is this a normal practice? Can I use this as a way to scope parts of a package? There also seems to be a package object, which I guess behaves similarly. Are there any problems with this method that I should know about?
It's normal practice and can be used as needed. You can group some things that you might not normally be able to just inside a file (Consts for example).
val DefaultKey="12345" //not legal inside a file outside of a class or object
class A (key:String) {
}
Legal version:
package com.mytest
object KeyExchange {
val DefaultKey="12345" //now legal
class A (key:String) {
}
}
use:
object Test extends App { //extending App is like a main method
import com.mytest.KeyExchange._ //can use import statement here, bringing in class A and the const.
val myA = new A(DefaultKey)
}
The package object is kind of like this concept, except the things placed inside of it become available to the classes and traits defined as part of that package (com.mytest for example.) This is the place you might put const items that the classes will frequently use, or more importantly implicit functions and objects. You could just place all of those things in a separate file, and object, but then you'd have to import them explicitly each time. You don't have to use package objects. My understanding is that this should be used sparingly, for items you're certain most classes can make use of.
reference:
http://www.scala-lang.org/docu/files/packageobjects/packageobjects.html