design-patterns

问题 I'm confused about the patterns: ViewModelLocator , ServiceLocator , Dependency Injection . The latest conclusion are as follows: ViewModelLocator . The place to connect View and ViewModel . public ViewModelLocator() { SimpleIoc.Default.Register<MainViewModel>(); SimpleIoc.Default.Register<SettingViewModel>(); } public MainViewModel MainViewModel => SimpleIoc.Default.GetInstance<MainViewModel>(); public SettingViewModel SettingViewModel => SimpleIoc.Default.GetInstance<SettingViewModel>(); //

问题 I have classes that extend an abstract class and I don't want to put @Builder on top of the all child classes. Is there any way to implement Lombok @Builder for an abstract class? 回答1: Not possible at all. The builder is generated into the super class during compiling and it can not have any knowledge of the possible sub classes that will eventually implement it. For example, the sub class could have constructors that have to be used for the instance to have a valid state and Lombok can not

问题 I'm trying to implement the Chain of Responsibility design pattern in Rust: pub trait Policeman<'a> { fn set_next(&'a mut self, next: &'a Policeman<'a>); } pub struct Officer<'a> { deduction: u8, next: Option<&'a Policeman<'a>>, } impl<'a> Officer<'a> { pub fn new(deduction: u8) -> Officer<'a> { Officer {deduction, next: None} } } impl<'a> Policeman<'a> for Officer<'a> { fn set_next(&'a mut self, next: &'a Policeman<'a>) { self.next = Some(next); } } fn main() { let vincent = Officer::new(8);

问题 I'm trying to implement the Chain of Responsibility design pattern in Rust: pub trait Policeman<'a> { fn set_next(&'a mut self, next: &'a Policeman<'a>); } pub struct Officer<'a> { deduction: u8, next: Option<&'a Policeman<'a>>, } impl<'a> Officer<'a> { pub fn new(deduction: u8) -> Officer<'a> { Officer {deduction, next: None} } } impl<'a> Policeman<'a> for Officer<'a> { fn set_next(&'a mut self, next: &'a Policeman<'a>) { self.next = Some(next); } } fn main() { let vincent = Officer::new(8);

问题 I am trying to follow SOLID principles when writing new classes and code. My question is about ASP.NET classes that extend the Page class i.e. ASPX files. If I had a page class that has a page_load event that creates instances of multiple objects e.g. Person class, Sport class etc then I believe this page class is tightly coupled with these classes. Is this the case or am I missing something obvious? Could it be that all classes should expose interfaces and the client (aspx pages) should use

问题 I am trying to follow SOLID principles when writing new classes and code. My question is about ASP.NET classes that extend the Page class i.e. ASPX files. If I had a page class that has a page_load event that creates instances of multiple objects e.g. Person class, Sport class etc then I believe this page class is tightly coupled with these classes. Is this the case or am I missing something obvious? Could it be that all classes should expose interfaces and the client (aspx pages) should use

问题 I am trying to follow SOLID principles when writing new classes and code. My question is about ASP.NET classes that extend the Page class i.e. ASPX files. If I had a page class that has a page_load event that creates instances of multiple objects e.g. Person class, Sport class etc then I believe this page class is tightly coupled with these classes. Is this the case or am I missing something obvious? Could it be that all classes should expose interfaces and the client (aspx pages) should use

问题 I am trying to follow SOLID principles when writing new classes and code. My question is about ASP.NET classes that extend the Page class i.e. ASPX files. If I had a page class that has a page_load event that creates instances of multiple objects e.g. Person class, Sport class etc then I believe this page class is tightly coupled with these classes. Is this the case or am I missing something obvious? Could it be that all classes should expose interfaces and the client (aspx pages) should use

问题 Is there a design pattern for managing a queue or a stack? For example, we are looking to manage a list of tasks. These tasks will be added to a group queue, users will then be able to pull off the queue and add them to their personal queue. 回答1: Design patterns can use queues and stacks, but the queues and stacks themselves don't really implement a design pattern, they implement an interface. Queues are typically FIFO while stacks are LIFO. Since many users might be using the data structures

问题 Is there a design pattern for managing a queue or a stack? For example, we are looking to manage a list of tasks. These tasks will be added to a group queue, users will then be able to pull off the queue and add them to their personal queue. 回答1: Design patterns can use queues and stacks, but the queues and stacks themselves don't really implement a design pattern, they implement an interface. Queues are typically FIFO while stacks are LIFO. Since many users might be using the data structures