Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Is there any situation when I need to declare the class data members as public?
Are there any chances of errors with such declarations?
Need to? No.
Any data access can be done through getters and setters:
(the truth of the above statement may depend on the language)
private member
public getMember()
return member
public setMember(newValue)
member = newValue
Instead of
public member
Errors? No. Well, apart from having to change your code to use the getters and setters instead.
Want to? Possibly.
The main disadvantage of using getters and setters is how pretty your code looks - how readable it is and code bloating.
See this for advantages of using getters and setters.
If using getters and setters classifies as similar to making the member public for you, then there are many scenario's where you need this at one of these kinds of access. Consider an artificial example of having a Car class. There would be many reasons why you'd want to get the windscreen member variable.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 4 months ago.
Improve this question
i am new to scala and cant seem to notice any issue here. As mentioned in code comments, if(enableXMLMessageLog(method)) is evaluating to false without executing the method enableXMLMessageLog . Once i add private to this method, it starts to work as expected and returns true on evaluation.
The methods are member of an abstract class.
Any idea what is happening here and why is it only getting called after adding private ?
i think i got it . the method was being called from a unit test class and only the logBookingMessage method was set to when(messageLogger.logBookingMessage(any[LoggingMethod])).thenCallRealMethod() hence it was not able to call the method enableXMLMessageLog as it was being mocked and thus returning false.
On adding private to the method, mocking framework does not mock and call the actual implementation of the method hence returning true.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
What is a named constructor, the private constructor in Flutter?
in what scenario these are used in Flutter?
The main idea behind having named constructors in Dart is so that you can define multiple constructors for one class. You can only define one unnamed constructor, which is used like this:
Foo(...);
But what if you want alternative ways of instantiating Foo? A named constructor lets you do this:
Foo.bar(...);
Foo.baz(...);
Let's use the Border class in Flutter as an example. Border provides four constructors (one unnamed and three named).
Border // unnamed
Border.all // named
Border.fromBorderSide // named
Border.symmetric // named
Each constructor provides an easier way to customize the Border. For example, the Border.all constructor applies the one set arguments to the entire set of borders of another widget (left border, top border, right border, and bottom border). So, in the case of the Border class, these constructors provide a more specific and lightweight way of creating a border.
We can then consider an example of when we might need to use named constructors over the unnamed version. Let's say we have data that represents a news story that we are going to display inside of a widget:
The unnamed constructor could look something like this:
Story({
this.headline,
this.publisher,
this.publicationDateTime,
});
This works for general purposes, but what if you want to also be able to pass it a JSON response from an API? We might want to consider using a named constructor for this so that it can handle both parsed and unparsed data.
Story.fromJSON(this.jsonData);
You can read about factory constructors in Official Documentation and here.
In your case, createInstance is a private constructor that can only be using inside DatabaseHelper class. Named constructors may be used for return created (cached) instances (performance).
Also, Google team created guides for introduction to Dart other platform developers. You can find tutorials like Intro to Dart for Java Developers on this page.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
When I use protocols with structural patterns such as MVP, or VIPER I usually add protocol and class conforming to the protocol in the same file.
For example, in MVP for the View component:
file: ListViewController.swift
protocol ListView {}
class ListViewController: ListView {}
and for the Presenter component:
file: ListPresenter.swift
protocol ListPresenter {}
class MainListPresenter : ListPresenter {}
1) is adding protocols and classes (when there is only one class conforming to it) in the same file, a good practice?
2) is ok to name the file containing the view controller with its name?
3) can I name the presenter file with the protocol name or do I lack of consistency?
How would you name filenames and classes in this example?
thanks
1) is adding protocols and classes (when there is only one class conforming to it) in the same file, a good practice?
If there's only one class conforming to a protocol, I would strongly argue that you're misusing protocols. If your pattern encourages this, then I would strongly question the value of the pattern.
But putting them in the same file is fine. Placing closely related types in a single file is good.
2) is ok to name the file containing the view controller with its name?
Sure.
3) can I name the presenter file with the protocol name or do I lack of consistency?
Sure...but again, if you have a protocol that has exactly one implementation, then something is likely wrong, and you should be digging into improving that rather than filenames.
This question already has answers here:
Difference between static function and singleton class in swift [closed]
(3 answers)
Closed 6 years ago.
I have made a class that will contain all the utility methods. So, instead of making it as a singleton, I have marked the methods as static and accessing those methods by the ClassName.methodName without the need for instantiation.
Is this approach OK?
Just consider that a singleton is used in order to ensure that only one instance exists for a given class, and that there’s a global access point to that instance.
I believe that having all utility functions marked as static within a class is a good approach since, as you have stated, you will need to use ClassName.methodName in order to use them.
In addition, based on what you want to achieve and the information provided by this link, I would reassert that having a class with static methods is the best alternative.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was wondering why you cant use the static keyword in a class.
I know that you can use it in a struct but not in a class
Does anyone know why they choose for this?
And if so are there any advantages for letting static away?
It is a terminological bêtise. What Apple did was decide that you use static in an enum or struct and class in a class. In my view this was a very foolish decision, as they are exactly parallel to one another. Many people have posted on the dev forums suggesting that they just call them all static.
The outcome is a candidate for Occam's Razor: two phrases, e.g. static property and class property, or static method and class method, that mean exactly the same thing. And then they try to cover their tracks in the documentation by adding a third term as an umbrella, "type property" (meaning a static-or-class property) or "type method" (meaning a static-or-class method), which just makes the situation even worse.
The badness of the situation is also revealed by what you have to do in protocols: you declare a class property in a protocol and then if a struct adopts it, it calls that a static property. Same thing with a class method in a protocol; an adopting struct must call that a static method. You'd think that this alone would have told them they'd done a bad thing.
Edit: The more I think about it, the more I like the proposal put forth by newacct in a comment below. If Apple had simply used the umbrella keyword type here as part of the language, the whole problem would have been solved. We could have declarations type var, type let, type func, and this would work equally in enums, structs, classes, and protocols across the board.
From the Swift Language Guide on Methods, Apple has chosen to differentiate the syntax used, based upon the fundamental Type that you're building.
Classes declare "Type Methods" with the keyword Class. Example:
class MyClass {
class func myFunc(){ ... }
}
Structs declare "Type Methods" with the keyword Static. Example:
struct MyStruct {
static func myFunc(){ ... }
}
In both cases, crating a Type Method allows you to invoke the method without first creating an instance of the class or struct.
Whereas a non class/static function would require something like
let instance = MyClass()
instance.myFunc()
... declaring the variable as a Type Method allows something like
MyClass.myFunc()