I was wondering how to get a variable equivalent from another .cs file with "using" statement.
Like
using (namespace here)
Output(A, 8);
and the file with (namespace here) would have
A = 3
would I be able to directly refer to the variable, or would I need to locate it some other way?
If you just want to define a bunch of constant values in one location that can be used elsewhere this is the standard pattern you would follow:
namespace MyNameSpace
{
public static class Constants
{
public const int MyFavoriteNumber = 3;
}
}
Then somewhere else you can have:
using MyNameSpace;
namespace MyOtherNameSpace
{
public class MyClass
{
public void Method()
{
Console.WriteLine(Constants.MyFavoriteNumber);
}
}
}
You can't dynamically change the scope of a code like that. What an identifier is, is determined at compile time, so you can't change what it means at runtime.
Make a class or an interface that specifies what it is that you want to use from the different files, then inherit the class or implement the interface to make different implementations in different files. When you use one of the implementations you get the values from that file.
Example:
public interface ICommon {
int A { get; }
}
public class File1 : ICommon {
public int A { get { return 42; } }
}
public class File2 : ICommon {
private int _value = 1;
public int A { get { return _value; } }
}
Now you can use different objects:
ICommon x;
if (something) {
x = new File1();
} else {
x = new File2();
}
Output(x.A, 8);
.CS files contains classes, not variables. If the .CS file contains a class that has a static property A you would just reference that static property:
Output(ClassName.A, 8);
Otherwise you need to provide more context as to what you have and what you're trying to do.
Related
I'm new to OSGI framework and I'm trying to access the 'Derived' Class variable 'publicVariable' from another class 'Derived2' like "Derived.publicVariable" but publicVariable is always shows null. I really appreciate if someone can help me out with this.
Thanks
Manifest file - Derived2
Require-Bundle:com.xxxxxx.Derived1
Java code
abstract class Base {
protected Vector <String> supportedCommands = new Vector <String> ();
protected abstract void initialiseCommands();
}
class Derived extends Base {
private static Derived derivedPlugin = null;
public Derived()
{
derivedPlugin = this;
}
public static Derived getPlugin()
{
return derivedPlugin;
}
public String publicVariable = null;
protected void initialiseCommands()
{
publicVariable = "someData";
System.out.println("Derived" + publicVariable);
}
}
class Derived2 extends Base {
protected void initialiseCommands()
{
supportedCommands.add(Derived.getPlugin().publicVariable);
System.out.println("IMRSAUtilitiesPlugin" +supportedCommands);
}
Also referred below link, which is a similar issue but i'm not using any static variable, it is just a public variable.
how use Singleton object in different class loader....?
The code in the question will not compile. You are trying to access an instance field (publicVariable in class Derived) in a static way, i.e. Derived.publicVariable.
OSGi does not change the semantics of the Java language, and if you cannot even compile your code then OSGi will certainly not be able to run it.
I'm writing an Ocean plugin for Petrel and need to persist some custom domain objects, and everything seems to point to using a structured archive data source. I've created a common class to hold a lot of the standard domain object stuff (droid, name, color, image, comments, history, etc), to avoid rewriting it for every domain object I create. The Ocean development guide only has simple examples of classes with no inheritance, but given that everything has a version number, I foresee a potential problem when the base class version is different than the version of inherited-class-1 which is different than inherited-class-2, and then I update something in the base class.
Is it possible to use a structured archive with the common base class? Are there any special considerations for versioning, or anything else I need to be aware of?
ETA: A simple class diagram showing the relationships and some stuff I've tried
public abstract class ClassA
|
-----------------------------------
| |
public class ClassB : ClassA public classC : ClassA
public class ClassD
{
private List<ClassA> _myClassAObjects;
}
All classes are marked Archivable, and in ClassD, _myClassAObjects is marked Archived. Everything saves OK, but when I load, I get an InvalidCastException, as it tries to cast the List<ClassB> to a List<ClassA>. The casting should work, since ClassB inherits from ClassA, should it not?
Got an answer from Schlumberger. It is possible, by doing something like this:
[Archivable]
public abstract class Abstract CDO
{
[ArchivableContextInject]
protected StructuredArchiveDataSource DataSourceCore;
[Archived(Name = "Name")]
private string _name;
private AbstractCDO _parent;
[Archived(Name="ParentDroid")]
private Droid _parentDroid;
[Archived(Name = "Droid")]
protected Droid DroidCore
{
get { return _droid; }
set
{
if (_droid != value)
{
DataSourceCore.IsDirty = true;
_droid = value;
}
}
}
public Droid ParentDroid
{
get { return _parentDroid; }
set
{
if (_parentDroid != value)
{
DataSourceCore.IsDirty = true;
_parentDroid = value;
}
}
}
public AbstractCDO Parent
{
get { return _parent; }
set
{
if (_parent != value)
{
DataSourceCore.IsDirty = true;
_parent = value;
_parentDroid = _parent.Droid;
}
}
}
protected AbstractCDO(string name)
{
_name = name;
DataSourceCore = Factory.Get();
_droid = DataSourceCore.GenerateDroid();
DataSourceCore.AddItem(_droid, this);
}
}
[Archivable]
public abstract class AbstractCDOCollection : AbstractCDO, IObservableElementList
{
[Archived]
private List<AbstractCDO> _children;
protected AbstractCDO(string name) : base(name) { }
public List<AbstractCDO> Children
{
get { return _children; }
}
}
[Archivable]
public class ConcreteObject : AbstractCDO
{
public ConcreteObject(string name) : base(name)
{
// other stuff
}
}
The DataSource property needs to be protected since the injection had a bug which was fixed in Petrel 2013.3 / 2014.1.
I have a class that only have main which read in some txt and do the algorithms.
my class is look like:
class doThejob{
public static void main(String args[]){
//*****start part A******
//do the reading from text file, and tokenize it
// process into the form I need,
//about 10-30 lines of codes
//******End of part A*****
//then run the algorithms
algorithm alg=new aglorithm();
Object output = alg.x(input);
//****Part B**** output to txt, about 10~40 lines
}
}
class algorithm{
private void a(Object x){
//do something
return (Object)result;
}
}
Can anyone tell me should I extract those part A and part B to a new class ,and then setup them as a public method .like below
class Io{
public Object readFromTxt(String path){
}
public void outputToTxt(String path){
}
}
And if I setup them , and then use it like below, is that more OOP?
class doThejob{
public static void main(String args[]){
Io dataProcess= new Io();
Object input = dataProcess.readFromTxt(args[0]);
algorithm alg=new aglorithm();
Object output =alg.x(input);
dataProcess.readFromTxt(args[1],output);
}
}
class algorithm{
private Object a(Object x){
//do something
}
}
Do it the way you fill is more readable.
Separating this in another class is according to the Single Responsability Principle. It will help making the code more readable and easy to change later on.
If you want to expand more on this, you could create an interface (eg.: IIO) for input and output. This way you can implement this interface in the IO class, renaming it to FileIO. Anytime you want to create another form of IO, like database access, you just have to create a DatabaseIO class that implements this interface and change the instance in the main method for this new type:
public interface IIO
{
string Read();
void Write(string text);
}
public class FileIO : IIO
{
string path;
public FileIO(string filePath)
{
path = filePath;
}
public string Read()
{
// read from file and return contents
}
public void Write(string text)
{
// write to file
}
}
public class SqlServerIO : IIO
{
SqlConnection conn;
public SqlServerIO(string connectionStringName)
{
// create the connection
}
public string Read()
{
// read from database
}
public void Write(string text)
{
// write to database
}
}
Extracting interfaces makes the code more maintenable by alowing to switch implementations anytime without messing with working code. It also facilitates unit testing.
I wonder how to add state to the chain of decorators that will be available to the consumer. Given this simplified model:
abstract class AbstractPizza
{
public abstract print(...);
}
class Pizza : AbstractPizza
{
public int Size { get; set; }
public print(...);
}
abstract class AbstractPizzaDecorator
{
public Pizza:AbstractPizza;
public abstract print();
}
class HotPizzaDecorator : AbstractPizzaDecorator
{
public int Hotness { get; set; }
public print(...);
}
class CheesyPizzaDecorator : AbstractPizzaDecorator
{
public string Cheese { get; set; }
public print(...);
}
void Main()
{
BigPizza = new Pizza();
BigPizza.Size = 36;
HotBigPizza = new HotPizzaDecorator();
HotBigPizza.Pizza = BigPizza;
HotBigPizza.Hotness = 3;
HotBigCheesyPizza = new CheesyPizzaDecorator();
HotBigCheesyPizza.Pizza = HotBigPizza;
HotBigCheesyPizza.Cheese = "Blue";
HotBigCheesyPizza.print();
HotBigCheesyPizza.size = 28; // ERRRRRR !
}
Now if they all implement the print method and propagate that though the chain, it's all good. But how does that work for the state? I can't access the size property on the HotBigCheesyPizza.
What's the part that I'm missing? Wrong pattern?
Thanks for helping!
Cheers
The decorator pattern is for adding additional behavior to the decorated class without the client needing to adjust. Thus it is not intended for adding a new interface (e.g. hotness, cheese) to the thing being decorated.
A somewhat bad example of what it might be used for is where you want to change how size is calculated: you could create a MetricSizePizzaDecorator that converts the size to/from English/metric units. The client would not know the pizza has been decorated - it just calls getSize() and does whatever it needs to do with the result (for example, to calculate the price).
I would probably not use the decorator in my example, but the point is: it does not alter the interface. In fact, nearly all design patterns come down to that - adding variability to a design without changing interfaces.
one way of adding state is by using a self referential data structure (a list). but this uses the visitor pattern and does more than you probably want. this code is rewritten from A little Java, a few patterns
// a self referential data structure with different types of nodes
abstract class Pie
{
abstract Object accept(PieVisitor ask);
}
class Bottom extends Pie
{
Object accept(PieVisitor ask) { return ask.forBottom(this); }
public String toString() { return "crust"; }
}
class Topping extends Pie
{
Object topping;
Pie rest;
Topping(Object topping,Pie rest) { this.topping=topping; this.rest=rest; }
Object accept(PieVisitor ask) { return ask.forTopping(this); }
public String toString() { return topping+" "+rest.toString(); }
}
//a class to manage the data structure
interface PieManager
{
int addTopping(Object t);
int removeTopping(Object t);
int substituteTopping(Object n,Object o);
int occursTopping(Object o);
}
class APieManager implements PieManager
{
Pie p=new Bottom();
// note: any object that implements a rational version of equal() will work
public int addTopping(Object t)
{
p=new Topping(t,p);
return occursTopping(t);
}
public int removeTopping(Object t)
{
p=(Pie)p.accept(new RemoveVisitor(t));
return occursTopping(t);
}
public int substituteTopping(Object n,Object o)
{
p=(Pie)p.accept(new SubstituteVisitor(n,o));
return occursTopping(n);
}
public int occursTopping(Object o)
{
return ((Integer)p.accept(new OccursVisitor(o))).intValue();
}
public String toString() { return p.toString(); }
}
//these are the visitors
interface PieVisitor
{
Object forBottom(Bottom that);
Object forTopping(Topping that);
}
class OccursVisitor implements PieVisitor
{
Object a;
OccursVisitor(Object a) { this.a=a; }
public Object forBottom(Bottom that) { return new Integer(0); }
public Object forTopping(Topping that)
{
if(that.topping.equals(a))
return new Integer(((Integer)(that.rest.accept(this))).intValue()+1);
else return that.rest.accept(this);
}
}
class SubstituteVisitor implements PieVisitor
{
Object n,o;
SubstituteVisitor(Object n,Object o) { this.n=n; this.o=o; }
public Object forBottom(Bottom that) { return that; }
public Object forTopping(Topping that)
{
if(o.equals(that.topping))
that.topping=n;
that.rest.accept(this);
return that;
}
}
class RemoveVisitor implements PieVisitor
{
Object o;
RemoveVisitor(Object o) { this.o=o; }
public Object forBottom(Bottom that) { return new Bottom(); }
public Object forTopping(Topping that)
{
if(o.equals(that.topping))
return that.rest.accept(this);
else return new Topping(that.topping,(Pie)that.rest.accept(this));
}
}
public class TestVisitor
{
public static void main(String[] args)
{
// make a PieManager
PieManager pieManager=new APieManager();
// add some toppings
pieManager.addTopping(new Float(1.2));
pieManager.addTopping(new String("cheese"));
pieManager.addTopping(new String("onions"));
pieManager.addTopping(new String("cheese"));
pieManager.addTopping(new String("onions"));
pieManager.addTopping(new String("peperoni"));
System.out.println("pieManager="+pieManager);
// substitute anchovies for onions
int n=pieManager.substituteTopping(new String("anchovies"),new String("onions"));
System.out.println(n+" pieManager="+pieManager);
// remove the 1.2's
n=pieManager.removeTopping(new Float(1.2));
System.out.println(n+" pieManager="+pieManager);
// how many anchovies do we have?
System.out.println(pieManager.occursTopping(new String("anchovies"))+" anchovies");
}
}
I believe your component Pizza and your abstract decorator PizzaDecorator are supposed to share the same interface, that way each instance of the decorator is capable of the same operations as the core component Pizza.
I have a class, say Provider, that exposes its funcationality to the above service layers of the system. It has a public method, say GetX(). Now, there are two ways to get the X : XML way and non-XML way. Two "Library" classes implement these two ways, one for each.
Thus, the structure that happens is something as follows :
public class Provider
{
private XmlLib _xmlLib;
private NonXmlLib _nonXmlLib;
public X GetX( // parameters )
{
// validate the parameters
if ( // some condition)
X = _xmlLib.GetX();
else
X = _nonXmlLib.GetX();
return X;
}
// several other such methods
}
internal class XmlLib
{
public X GetX()
{
// Xml way to get X.
}
// several such things to get/send in XML way.
}
internal class NonXmlLib
{
public X GetX()
{
// NonXml way to get X.
}
// several such methods to get/send thing in non-XML way.
}
So its like, the Provider class becomes a sort of a dumb wrapper, which only validates the arguments, and based on one condition, decides which lib to call.
Is this a good implementation? Any better way to implement this?
Let the GetX method be in an interface. from that point on you can have as many classes that you want that implement the interface.
public interface ISomeInterface { X GetX(); }
Now build a class that will implement the factory design pattern (read about it if you do not know it) and let this class accept the condition which will enable it to decide which class that implements the above interface to return.
here's what I said through code:
public class XmlWay : ISomeInterface
{
public X GetX()
{
//your implementation
}
}
public class NonXmlWay : ISomeInterface
{
public X GetX()
{
// Another implementation
}
}
and finally the factory class
public class MyXFactory
{
public static ISomeInterface GetXImplementation(bool someCondition)
{
if (someCondition)
return new XmlWay();
else
return new NonXmlWay();
}
Now see how elegent your code will look:
ISomeInterface xGen = MyXFactory.GetXImplementation(true);
xGen.GetX();
Hope this helps.