Say I have an class which has three states: full screen, windowed, and minimized. The state of my object is stored as an enumerated type,
typedef enum {
StateFullScreen,
StateWindowed,
StateMinimized
} State;
If every time I change the State, I am calling two methods: setState: and showState:, should I couple these actions into one? For example, override the normal synthesized setState: method and have it depending on the state call the proper showState: method? Or should I do it the other way around having showState: call setState:?
Are either of these good programming practice when it comes to object-oriented design?
Have you considered creating a ChangeState(...) method?
It would be simple enough to create a first pass refactoring that calls the other two methods. I'd then work through further refactorings to clean it up fully.
In my opinion it would be better to do all the work in setState, this is what someone using your class would expect.
I have a session class, which has statusses connecting, disconnecting, online and offline. If I call setStatus it will also call a delegate method and disconnect the session if the new status is equalto disconnecting or offline.
Related
All I know about the difference between them is in the image below.
scrypto101 explanantion of function and method
I am unable to pinpoint the difference between two of them with complete clarity.
Especially, I am unable to see scrypto code and point out that which one is a function and which one is a method.
I read that a method causes change in state where as a function does not.
What is a state ?
What does it change in state exactly mean ?
e.g. If I have to just make some changes to a nfs's metadata etc, should that be categorised as a function or a method ? (I think method)
A guideline about distinguishing a code tasks as a function or a method will help me a lot.
I am a beginner in DeFi and blockchain technology, any explanation of above with an real life example for identifying change vs no change in state or code snippet will help me a lot.
You can think of functions and methods just like in Object Oriented Programming where you have Classes and Objects. Classes offer functions and the instantiated objects offer methods. Since functions are called on the class itself, it doesn't have any state to view/update. Methods are called on individual objects instantiated from a class and it has access to the values stored on the state of the object.
Concretely, in Scrypto, the difference is in the first argument of the function/method. If you put &self as the first argument, it will be a method rather than a function since you have access to the variables of the component through this &self argument.
I have a handful of classes that manage some data. They all sync with a server, and the sync is started by one method called startSync. I want the super method to do some checking if the sync is even necessary, and if it isn't to stop the sync before the child method kicks off the sync.
I have thought of a few options, but not sure which one is the best way to implement it. I'm working in Objective-C so that adds a few variables to consider.
A) Make the method return a boolean value and have the child implementation call the super implementation and check the boolean, returning false if it is false. But someone writing a subclass and implementing the method won't always know what to do with that.
B) Make a doSync abstract method that the super class calls from the startSync method that one would call from outside the class. This has the side effect of not knowing which method to call and accidentially overriding the wrong method.
C) Same as B but the "doSync" method is protected by using an "internal" header. This has the side effect of accidentally overriding the wrong method because they don't know about the internal header, but outside classes don't know about the doCall method to skip the check.
What I'm looking for is input on if one of these is the most appropriate or if there is a better option.
I am designing a game with several levels. I have a CCLayer defined as a singleton (called MasterScene) where I handle the pause page, transition page, player's score banner,... all the things common to all levels.
So in each level, when the user pushes the pause button, a call is made to the singleton to display the CClayer corresponding to the pause page. My problem is that I want to know who called the singleton (which level) t. Is there a way of doing that ?
Thanks
Without knowing more about your application's architecture, I'd suggest three possible approaches:
Pass the level number (or pointer to the level object, or whatever) as a parameter to the singleton's methods.
Have the object keep track of which level is the current one, so that it already knows. (Obviously, this assumes that only the current level can be calling these methods. But I'm not sure why multiple levels would have available pause buttons.)
Don't make this object a singleton at all. Create an instance for each level. Is there really application-global state that this object needs to track? If you're using the MasterScene to encapsulate the behavior, but not global state, then have multiple instances of that class around doesn't really hurt anything (or consume much in devices resources).
There's no general way to locate the source of a message the way you are asking for.
There are however alternative architectures for your app which might solve this problem and I encourage you to consider them. What you're describing sounds like a mess of interdependent classes. All of your levels are aware of and use this MasterScene singleton and now you're trying to make the singleton aware of every level as well? Every piece of your applications shouldn't need to be aware of every other.
You can pass it in as an argument, e.g.
#implementation Level30
-(void) pause;
{
[[MasterScene getSingleton] pauseWithLevel:self];
}
#end
Example:
// access fields directly
private void doThis()
{
return doSomeWork(this.data);
}
// receive data as an argument
private void doThis(data)
{
return doSomeWork(data);
}
The first option is coupled to the value in this.data while the second option avoids this coupling. I feel like the second option is always better. It promotes loose coupling WITHIN the class. Accessing global class data willy-nilly throughout just seems like a bad idea. Obviously this class data needs to be accessed directly at some point. However, if accesses, to this global class data can be eliminated by parameter passing, it seems that this is always preferable.
The second example has the advantage of working with any data of the proper type, whereas the first is bound to working with the just class data. Even if you don't NEED the additional flexibility, it seems nice to leave it as an option.
I just don't see any advantage in accessing member data directly from private methods as in the first example. Whats the best practice here? I've referenced code complete, but was not able to find anything on this particular issue.
if the data is part of the object's state, private/protected is just fine. option 1 - good.
i noticed some developers like to create private/protected vars just to pass parameters between methods in a class so that they dun have to pass them in the method call. they are not really to store the model/state of an object. ...then, option 1 - NOT good.
Why option 1 not good in this case...
expose only as much as you need (var scoping). so, pass the data in. do not create a private/protected var just to pass data between 2 methods.
private methods that figures out everything internally makes it very easy to understand. keep it this way, unless its unavoidable.
private/protected vars make it harder to refactor as your method is not 'self encompassing', it depends on external vars that might be used elsewhere.
my 2 cents! :-)
In class global data are not a problem IMHO. Classes are used to couple state, behaviour and identity. So such a coupling is not a problem. The argument suggests, that you can call that method with data from other objects, even of other classes and I think that should be more considered than coupling inside class.
They are both instance methods, therefore #1 makes more sense unless you have a situation involving threads (but depending on the language and scenario, even then you can simply lock/mark the data method as syncronized - my Java knowledge is rusty).
The second technique is more reminiscent of procedural programming.
Instead of using an interface like this:
public interface IStartable
{
void Start();
void Stop();
}
I usually just make the constructor of an object run the Start() code, and implement IDisposable so that the dispose method runs the Stop() code.
Is it just a matter of style? Or am I missing something important by not having something like IStartable? All I see is extra complexity, because you have to maintain it's started/stopped state.
What are the pros and cons of using start/stop vs using ctor/dispose, especially in the context of an IoC/DI container?
EDIT: Great answers, you've convinced me to use an interface for startable objects. I can't decide who's answer is the best so I'll accept whoever has the most up votes after 24 hours.
The general advantage to using an interface is that they're self-describing and self-advertising. If there's no interface, you don't have a way to ask an object, "can you be started and stopped?" If you do use an interface, by contrast, you can query objects to see which of them will respond to those kinds of messages. Then you can be safely guaranteed that such objects have implemented the functionality encapsulated by the interface.
in general, constructors should produce a properly-initialized object
and nothing more!
It could possibly depend on what, specifically, you mean to be happening when you say Start(). But in general, mixing object initialization with routine execution (especially stateful and/or long-running execution!) violates SoC.
It also leaves a great deal of ambiguity. To a consumer, for a given object how do we know it is "starting" when we invoke the ctor? "For this given object, which implements no contract, I must leave it to hope in the author that it conforms to my expectations"? An interface makes the presence and availability of the action explicit.