I'm writing a method to compare two objects of the same class. The second object is passed in as an argument. The method starts by calling a private method CalcValue on the current object, that if neccessary (only need to do it once) calculates the numerical value of it and puts it in it's private variable value.
How can I do the same thing for the object sent in as an argument? How do I access that object's private CalcValue method, and later access it's private value variable? Should I make the method public and write a public access method for the variable?
I don't know which object-oriented framework you used, so I assume [incr Tcl]. You will need to make the CalcValue method public if you want the second object to access it. Below is an overly simplified example that illustrate how to access your method:
package require Itcl
itcl::class Thing {
method CalcValue {} { return 999 }
method compare {otherThing} {
set myValue [CalcValue]
set otherValue [$otherThing CalcValue]
# Do something
}
}
# -------- MAIN: Create two instances and compare --------
Thing thing1
Thing thing2
thing1 compare thing2
If CalcValue is private, then the call $otherThing CalcValue will fail.
Related
I have a class with a public method that takes a couple of parameters, like this:
The Process method needs to call different private methods to actually process the data. Is it better to pass all the parameters down the road or should I use a field to provide the information to the private methods?
// Variant 1: Parameters
public void Process(string param1, string param2, int param3)
{
processStep1(param1, param2, param3);
processStep2(param1, param2);
processStep3(param1, param2, param3);
}
// Variant 2: Fields
public void Process(string param1, string param2, int param3)
{
m_Param1 = param1;
m_Param2 = param2;
m_Param3 = param3;
processStep1();
processStep2();
processStep3();
}
In my eyes the variant 1 has the advantage of being free of side-effects (methods cannot change the value of a field). It mighthave advantages if it comes to unit testing because it's easier to test a specific function.
Variant 2 looks much more clear to me. You don't have to pass any parameters around and it's possible to change the contents of the fields if neccessary.
Is there a clear winner? Are both approaches valid and when to use which one?
From the description of your question I'd say Variant 1 is a clear winner, since, as you correctly identified, has more advantages than Variant 2. Side effects and testability are huge factors.
I'd add that Variant 2 is a form of a global state and unnecessary. Why would you want to have member variables used by a method which aren't needed in the object? What kind of object is it? Do you have other methods using these member variables?
Variant 1 has a clear interface for each step and you don't fall into the trap of accessing other state not really available from the parameters.
I'd only choose Variant 2 if the constructor initializes the member variables that are needed for the function process and is only used for this Process method.
In Swift, what is the conventional way to define the common pattern where a property is to be externally readonly, but modifiable internally by the class (and subclasses) that own it.
In Objective-C, there are the following options:
Declare the property as readonly in the interface and use a class extension to access the property internally. This is message-based access, hence it works nicely with KVO, atomicity, etc.
Declare the property as readonly in the interface, but access the backing ivar internally. As the default access for an ivar is protected, this works nicely in a class hierarchy, where subclasses will also be able to modify the value, but the field is otherwise readonly.
In Java the convention is:
Declare a protected field, and implement a public, read-only getter (method).
What is the idiom for Swift?
Given a class property, you can specify a different access level by prefixing the property declaration with the access modifier followed by get or set between parenthesis. For example, a class property with a public getter and a private setter will be declared as:
private(set) public var readonlyProperty: Int
Suggested reading: Getters and Setters
Martin's considerations about accessibility level are still valid - i.e. there's no protected modifier, internal restricts access to the module only, private to the current file only, and public with no restrictions.
Swift 3 notes
2 new access modifiers, fileprivate and open have been added to the language, while private and public have been slightly modified:
open applies to class and class members only: it's used to allow a class to be subclassed or a member to be overridden outside of the module where they are defined. public instead makes the class or the member publicly accessible, but not inheritable or overridable
private now makes a member visible and accessible from the enclosing declaration only, whereas fileprivate to the entire file where it is contained
More details here.
As per #Antonio, we can use a single property to access as the readOnly property value publicly and readWrite privately. Below is my illustration:
class MyClass {
private(set) public var publicReadOnly: Int = 10
//as below, we can modify the value within same class which is private access
func increment() {
publicReadOnly += 1
}
func decrement() {
publicReadOnly -= 1
}
}
let object = MyClass()
print("Initial valule: \(object.publicReadOnly)")
//For below line we get the compile error saying : "Left side of mutating operator isn't mutable: 'publicReadOnly' setter is inaccessible"
//object.publicReadOnly += 1
object.increment()
print("After increment method call: \(object.publicReadOnly)")
object.decrement()
print("After decrement method call: \(object.publicReadOnly)")
And here is the output:
Initial valule: 10
After increment method call: 11
After decrement method call: 10
I have a groovy class that looks up a method reference and then invokes it. The method being invoked is a private method. When the actual class is an instance of the child class, it throws an error that it cannot find the private method, even though it is the public method in the parent that actually calls it.
In this case, I could obviously just call pMethod2() directly and that works, but I'm trying to understand why this doesn't work as written and if there's a way to correct it so it works.
class Parent {
def pMethod1() {
def m = this.&pMethod2
m() // this call fails if the calling class is of type Child
}
private def pMethod2() {}
public static void main(String[] args) {
new Child().pMethod1();
}
}
class Child extends Parent {}
It is a bit confusing, especially if you're used to C / C++. What you get when using the ".&" operator in Groovy is not an address, but an instance of MethodClosure.
The MethodClosure object contains an owner and a delegate object, which is used when resolving the method to call. In your example, the owner and delegate object will be "this", which is an instance of Child. The method to call is simply stored as a string.
So, the assignment
m = this.&pMethod2
is just a shorthand way of writing
m = new MethodClosure(this, "pMethod2")
When you invoke the m() closure, it will try to resolve (at runtime) the method by looking for methods named "pMethod2" in the owner and the delegate objects respectively. Since the owner and delegate is an instance of Child, it will not find private methods located in Parent.
To make your example work you must make sure that the method is visible to the owner and/or delegate of the closure.
This can be done several ways, for instance by changing the access modifier of pMethod2 to protected, or by creating the closure with an instance of Parent; something like this:
m = new Parent().&pMethod2
Note that is is irrelevant that you created the MethodClosure instance in a method where pMethod2 is actually visible. It is also irrelevant that you invoke the closure in a method where it is visible. The method is not visible to the owner or delegate of the MethodClosure, which is what is being used when resolving the method.
I have an EggSac object which contains references to >100 000 Egg objects. Some variables in the Eggs have to be maintained to be consistent with EggSac, so I want to make these only changeable by EggSac. However EggSac passes references to its Eggs all over the application, so if I use public methods then any other code could modify the secure parts of the Eggs by accident.
What's a proper OO way to make sure only the EggSac object can call the "secure" methods of the Eggs, but still make the "safe" methods available to everyone?
My idea is to split Egg's class into a base class containing only safe methods and a derived class containing the secure methods that only EggSac should have access to. Then EggSac has members of the type of the derived class, but it casts them to their base class whenever something else wants one.
Have EggSack hold references to EggImpl, which implements all the necessary methods. Then pass around wrappers over the impl (the Egg class) which only call the "safe" methods on the impl.
When you say security, do you mean avoiding accidental code modification?
A structured way can be something like below.
If you want to make it really 'secure', then you can modify the code to store a string*HashCode* inside the calling class and only if it's matched (inside called ) in Egg, modification is allowed.
Interface ISecureModifier
{
String GetSecureModifierKEY();
String GetSecureModifierVALUE();
}
class Egg
{
Dictionary Secure_ata;
public secureDataModifier( ISecureModifier modifyingObject)//note the interface being used
{
//Here, try a cast (if your compiler still allowed other type objects not implementing ISecureModifier ) and throw exception stating not authorized to modify.
modifyingObject.GetSecureModifierKEY
modifyingObject.GetSecureModifierValue
/*Now write the code to modify Dictionary*/
}
}
class EggSac:ISecureModifier//implements interface
{
private string SecureModifierKEY;
private string SecureModifierVALUE
String GetSecureModifierKEY()//inteface impl
{
return SecureModifierKEY;
}
String GetSecureModifierVALUE();//interface impl
{
return SecureModifierVALUE;
}
ModifySecureData(Egg egg, string key, string value)
{
egg.secureDataModifier(this);//passing own reference
}
}
You may call like this
objEggSack.ModifySecureData(objEgg101, "firstKey","NewValue")
Can a class return an object of itself.
In my example I have a class called "Change" which represents a change to the system, and I am wondering if it is in anyway against design principles to return an object of type Change or an ArrayList which is populated with all the recent Change objects.
Yes, a class can have a method that returns an instance of itself. This is quite a common scenario.
In C#, an example might be:
public class Change
{
public int ChangeID { get; set; }
private Change(int changeId)
{
ChangeID = changeId;
LoadFromDatabase();
}
private void LoadFromDatabase()
{
// TODO Perform Database load here.
}
public static Change GetChange(int changeId)
{
return new Change(changeId);
}
}
Yes it can. In fact, that's exactly what a singleton class does. The first time you call its class-level getInstance() method, it constructs an instance of itself and returns that. Then subsequent calls to getInstance() return the already-constructed instance.
Your particular case could use a similar method but you need some way of deciding the list of recent changes. As such it will need to maintain its own list of such changes. You could do this with a static array or list of the changes. Just be certain that the underlying information in the list doesn't disappear - this could happen in C++ (for example) if you maintained pointers to the objects and those objects were freed by your clients.
Less of an issue in an automatic garbage collection environment like Java since the object wouldn't disappear whilst there was still a reference to it.
However, you don't have to use this method. My preference with what you describe would be to have two clases, changelist and change. When you create an instance of the change class, pass a changelist object (null if you don't want it associated with a changelist) with the constructor and add the change to that list before returning it.
Alternatively, have a changelist method which creates a change itself and returns it, remembering the change for its own purposes.
Then you can query the changelist to get recent changes (however you define recent). That would be more flexible since it allows multiple lists.
You could even go overboard and allow a change to be associated with multiple changelists if so desired.
Another reason to return this is so that you can do function chaining:
class foo
{
private int x;
public foo()
{
this.x = 0;
}
public foo Add(int a)
{
this.x += a;
return this;
}
public foo Subtract(int a)
{
this.x -= a;
return this;
}
public int Value
{
get { return this.x; }
}
public static void Main()
{
foo f = new foo();
f.Add(10).Add(20).Subtract(1);
System.Console.WriteLine(f.Value);
}
}
$ ./foo.exe
29
There's a time and a place to do function chaining, and it's not "anytime and everywhere." But, LINQ is a good example of a place that hugely benefits from function chaining.
A class will often return an instance of itself from what is sometimes called a "factory" method. In Java or C++ (etc) this would usually be a public static method, e.g. you would call it directly on the class rather than on an instance of a class.
In your case, in Java, it might look something like this:
List<Change> changes = Change.getRecentChanges();
This assumes that the Change class itself knows how to track changes itself, rather than that job being the responsibility of some other object in the system.
A class can also return an instance of itself in the singleton pattern, where you want to ensure that only one instance of a class exists in the world:
Foo foo = Foo.getInstance();
The fluent interface methods work on the principal of returning an instance of itself, e.g.
StringBuilder sb = new StringBuilder("123");
sb.Append("456").Append("789");
You need to think about what you're trying to model. In your case, I would have a ChangeList class that contains one or more Change objects.
On the other hand, if you were modeling a hierarchical structure where a class can reference other instances of the class, then what you're doing makes sense. E.g. a tree node, which can contain other tree nodes.
Another common scenario is having the class implement a static method which returns an instance of it. That should be used when creating a new instance of the class.
I don't know of any design rule that says that's bad. So if in your model a single change can be composed of multiple changes go for it.