solid-principles

问题 The Open/Closed Principle states that software entities (classes, modules, etc.) should be open for extension, but closed for modification. What does this mean, and why is it an important principle of good object-oriented design? 回答1: Specifically, it is about a "Holy Grail" of design in OOP of making an entity extensible enough (through its individual design or through its participation in the architecture) to support future unforseen changes without rewriting its code (and sometimes even

问题 I have an existing bank application classes as shown below. The banks account can be of SavingsBankAccount or FixedBankAccount. There is an operation called IssueLumpSumInterest. For FixedBankAccount, the balance need to be updated only if the owner of the account has no other account. This demands the FixedBankAccount object to know about other accounts of the account owner. How to do this by following SOLID /DDD/GRASP/Information Expert pattern? namespace ApplicationServiceForBank { public

问题 The Wikipedia page (as of today 2013-02-27) for the Open-Closed Principle says that it's realized via inheritance. The name Open/Closed Principle has been used in two ways. Both ways use inheritance to resolve the apparent dilemma, but the goals, techniques, and results are different. The "two ways" refers to Meyer's implementation inheritance and the more common Polymorphic extensions. Anyway, my question is about the Façade pattern, which does not use inheritance. Since it defines an

问题 How can I have a plain php object from a third party package inherit all the goodness of Laravels Eloquent models? see below: The model class below is from a third-party package . It is framework and ORM agnostic , written in plain PHP . I cannot change it, only extend it. (example only) class APlainPHPModelFromLibrary { protected $someAttribute; protected $someOtherAttribute; //... public function someFunction() { // ... } } And here is my Laravel Eloquent version of this model class. I need

问题 I am reading about SOLID principles and I stopped here on " Dependency inversion principle" which means the objects should passed already instantiated to anther object, which means composition cannot be applied with Dependency inversion principle am right? or there is something I miss? UPDATE ************************************************** suppose you have a class and this class has an attribute which is reference to anther object, we have 2 solution(for me): Create the object outside the

问题 Suppose we are designing a UserServiceImpl class which does CRUD (Create, Read, Update, and Delete) operations. In my view Create, Read, Update, and Delete are four reasons for a class to change. Does this class violates Single Responsibility Principle? If it violates, then should we have four classes like CreateUserServiceImpl , ReadUserServiceImpl , UpdateUserServiceImpl , and DeleteUserServiceImpl . Isn't it an overkill to have lots of classes? Suppose I define 4 interfaces each for create

问题 Is there a specific design pattern that describes the scenario where a non-abstract default implementation is provided that implements all or some of the methods on the interface with empty, NO-OP implementations. This being done with the intent of alleviating subclasses with the burden of implementing methods that they themselves may not need/use: public interface MyInterface { public void doThis(); public void doThat(); public void done(); } public class MyClass implements MyInterface {

问题 As per this Wikipedia article: Implementing Dependency Inversion Principle can be done in two ways: Having an abstraction of a low level component in a separate package upon which both high level and low level components depend. Having the abstraction of the low level component reside in the same package of the high level component. The following illustration depicts the dependencies before and after DIP using the two approaches: Before DIP: The repository resides in a separate maven module

问题 This question already has answers here : What is an example of the Liskov Substitution Principle? (29 answers) Closed 7 months ago . As I've read the substitution of objects of a concrete type by instances of a subclass of that concrete type must preserve a program's correctness, a program's invariants. I'd like to know what exactly is meant by correctness and invariants of a program? 回答1: Let's say you have a class Animal and someone asks you what it's supposed to do, what it can be used for

问题 Say an application in ruby when started has two modes : commandline mode and filemode When given a parameter ruby myprogram input.txt output.txt , it generates an output based on some commands in input file. also when not provided with any parameter it presents us with a command prompt. with following commands. create_class_with_capacity 40 create_student_with_marks Alex 70 create_student_with_marks Mathew 30 create_student_with_marks John 55 .. create_student_with_marks Sylvia 70 etc... fail