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 6 years ago.
Improve this question
I have a class which will contain list of two dependent classes inside it.
example
Class ActivityHolder{
private ArrayList activityList;
private ArrayList promiseList;
}
My question is how do i name the ActivityHolder class.
[Edit]
I have a class structure as above.And not the wallet and coin scenario.
Like Richard and amal pointed, the class name must be something related to its function.
If it represents a bunch of activities, so it is okay to name it Activities.
Class Activities {
private List activities; // backlog, planned, other better name (more specific)
private List promises;
}
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I'm new to Rust and a frequent user of MongoDB. I usually use node.js + Mongoose ODM.
Is there any MongoDB ODM in RUST that implements a custom schema and business logic hooks like Mongoose ODM ? Or do I need to implement it myself inside the Rust's type system?
This is an example from Mongoose
const schema = kittySchema = new Schema(..);
// they implement the 'meow' method in the Kitty Schema
schema.method('meow', function () {
console.log('meeeeeoooooooooooow');
})
// so anytime a Kitty schema instance is created
const Kitty = mongoose.model('Kitty', schema);
const fizz = new Kitty;
// fizz as the instance of Kitty Schema automatically has meow() method
fizz.meow(); // outputs: meeeeeooooooooooooow
As far as I know.. mongodm-rs doesn't do that
nor Wither nor Avocado
You may not need an ODM. With serde (which is used by all those ODMs), the "schema" is implemented on the struct itself, so you can add any methods you want with an impl block. It would look something like this:
use serde::{Deserialize, Serialize};
// Deriving from serde's Serialize and Deserialize, meaning this struct can be converted to and from BSON for storage and retrieval in MongoDB:
#[derive(Serialize, Deserialize, Debug)]
struct Kitty {
name: String,
}
impl Kitty {
fn meow(&self) {
println!("{} says 'meeeeeoooooooooooow'", &self.name);
}
}
let fizz = Kitty {
name: String::from("Fizz"),
};
fizz.meow();
This struct can be stored in MongoDB (because it derives Serialize and Deserialize) - to see how, check out my blog post Up and Running with Rust and MongoDB. There's some more up-to-date details about how to use serde with MongoDB in my colleague Isabelle's post.
This question already has answers here:
Subclass a class that extends StatelessWidget or StatefulWidget class
(5 answers)
Closed 1 year ago.
Some places on internet, i read RaisedButton uses composition like text widget that contain other properties to set Text? My question is what does it mean?What happens if use inheritence instead of composition?
Here is code:
RaisedButton(
child: Text("Decrement Counter"),
onPressed: () => _decrementCounter(),),
Flutter prefer composition over inheritance because it is easy to manage since it represent "" has a " relationship. Consider this
Class person{
String name;
Address add;
}
In above scenario , it is better practice to make separate class for address because it contain multiple information like house no,city,country postal code etc.if you place all the information inside person class this should work but not in a better way.
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 2 years ago.
Improve this question
Background
When developing an application, my approach (rightly or wrongly) is to separate the logic into a Framework (Kit)
The reason(s) for this are fairly straight forward ..
• I like being able to test the logic in isolation
• I like that it forces me to forget about the UI and any UI assumptions
• I like that I am free to create the app using a separate UI .. depending on device (iPhone, Watch .. Apple TV .. Command Line Utility)
The Problem
because I like the logic in a separate framework .. I have introduced a complexity in terms of access modifiers (Public, Internal, Private) for classes, structs, enums, methods, properties.
What I have most trouble with is properties (and properties of Entities in particular)
I prefer not to expose the setter to the consumer of the Framework (i.e. the UI Application)
Within a Module I would typically use the.
private(set) var nameOfProperty
approach.
However this isn’t an option to me in entities of a framework.
So for a framework, I would much rather return a Protocol describing the interface of an Entity
.. i.e. it’s writable properties, it’s read-only properties and it’s accessible methods
We (Swift Developers) have been encouraged down the route of naming Protocols according to a behaviour .. however,
.. for example, a Football/Soccer Team Selection framework I wouldn’t want to be passing back and forth something that conforms to ‘Player-able’, ‘Manager-able’, ‘Fixture-able’
.. I want to pass back and forth a ‘Player’, ‘Manager’, ‘Fixture’ (as the consumer would rightfully expect)
Question
What should I be naming my Entity (assuming it conforms to a commonly known as Protocol) ?
Understandably, we can not have a Protocol called protocol Player and class Player
Some Suggested Ideas
Idea 1: Use underscoring within the framework (my most likely approach)
e.g.
public protocol Player {
public var name: String { get }
}
public class _Player: Player {
..
}
Idea 2: Don’t use protocols, but use computed properties instead (not preferred)
e.g.
public class Player {
private var _name: String
public var name: String {
get {
return _name
}
}
Idea 3: Don’t use protocols, because you're the only consumer then trust yourself and make everything public 🤪
e.g.
public class Player {
public var name: String
}
Idea 4: Use a substitute name within the framework (a bit like underscoring)
e.g.
public protocol Player {
public var name: String { get }
}
public class PlayerEntity: Player {
..
}
or
public class PlayerImpl: Player {
..
}
or
public class PlayerObj: Player {
..
}
Personally, I'd go with Player: PlayerProtocol, unless you are going to be using the protocol much more often. There are some examples of this in the standard library, such as StringProtocol and IteratorProtocol.
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 does this line means "Swift doesn’t require you to create separate interface and implementation files for custom structures and classes."
link
It is referring to the old C-style way of separating interfaces and implementations in separate .h and .c (.m for ObjC/.mm for ObjC++) files.
In Swift, you no longer need to deal with this - interfaces are generated by the compiler.
For example:
public class Loader {
private let resource: URL
init(resource: URL) { self.resource = resource }
public func load {
//..
}
}
Generates an interface (effectively, an API) with only the public members exposed:
public class Loader {
init(resource: URL)
public func load()
}
The key here is, that there no longer needs to be a separate file maintained by the developer. The interfaces are generated (or not) based on the access control levels defined on your types.
In objective C you have different files for interface called .h file and for implementation of that interface you have .m file
but in swift you have .swift file in which you implement the functionality so you don't need to create two separate files in swift
thats what docs are referring to ... hope it helps
happy coding =)
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
I have a few classes i.e. User, Settings... that I use in most of my ViewControllers. Because I use them often, is it better if I have only one instance of them to use globally, or a new instance for each class?
In AppDelegate:
let user = User()
class AppDelegate: UIResponder, UIApplicationDelegate {
...
vs.
In each class:
class TimerViewController: UIViewController {
private let user = User()
For the current state being globally is better
let user = User()
but it's much better to make it a singleton
class Service {
static let shared = Service()
let user = User()
}
so not to confuse other developers when read the code won't know whether this global var is local/instance/global , so being singleton will sort this
My two cents
It is always better to declare it where you actually need instead of declaring it globally. It is good practice to limit the scope the variables that we use so that it gets deallocated and cleared from memory when its job is over. Here, it is clear that there is only one owner for that instance.
Declaring global objects will lead to maintaining global state for the instance properties and since it is open to all classes, it will not be clear which class is changing what.Here, everyone is like owner of this instance.So, It is always better to avoid it.