Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Your question actually has two meanings. </p> <blockquote> <p>that has to be reused many times in many classes</p> </blockquote> <p>It can be a context of design pattern (reusable component) or memory cost (class instantiation). Talking from two different perspective:</p> <h2><strong>Memory Cost</strong> (I had little experience on this, but let me share my experience)</h2> <p>This section actually only cover 2 kind of instantiation.</p> <p><strong>First is static (or DI instantiation in composition root)</strong> </p> <ul> <li>Eager instantiation, means all class will be instantiated when application start</li> <li>One time instantiation only</li> </ul> <p><strong>Non-static</strong></p> <ul> <li>Lazy instantiation, means class will only be instantiated when needed</li> <li>One time instantiation every use</li> </ul> <p>In short, static will cost high if the class is many, and non-static will cost high if the request is high (inside for loop, for example). But it should not make your application heavy. Most operation in java / csharp are creates objects though.</p> <h2><strong>Class Reusability</strong></h2> <p><strong>1 - mega monolithic code (one god class able to do almost everything)</strong></p> <p>Advantages:</p> <ol> <li>Easy to search for code (still depends though), you know that every logic lies there so you just need to look at that big class</li> <li>If it is static, you can just call it anywhere without worrying about the instantiation</li> </ol> <p>Disadvantages:</p> <ol> <li>Any modification for one method creates risk for error in other places</li> <li>Violates SRP, means this class can be changed by various reason, not only one</li> <li>Especially in versioning, it is harder to merge if modification happen in separated branches, resulting effort in synchronize code</li> </ol> <p><strong>1a / static class / singleton pattern</strong> </p> <p>Advantages:</p> <ol> <li>Easy to use</li> <li>Can be used anywhere (just reference and call, and done)</li> <li>Not need to instantiate object</li> </ol> <p>Disadvantages:</p> <ol> <li>Hard to unit test (it is hard to mock, and at latter time, you will find it is taking time to prepare the test environment. Especially with data</li> <li>If stateful (has state), it is hard to determine current state, during debugging. Moreover, it is hard to determine which function changes the state, in can be changed from everywhere</li> <li>Tend to have much parameters (maybe around 5-11)</li> </ol> <p>Some point about static class: <a href="https://stackoverflow.com/questions/1333690/static-classes-in-c-whats-the-pros-cons">see this question</a></p> <p><strong>2 strategy pattern</strong></p> <p>Actually this has the same design with 3 or <code>composition over inheritance</code>.</p> <p><strong>3 dependency injection</strong></p> <p>Advantages:</p> <ul> <li>Easy to mock and unit test</li> <li><code>Must be stateless</code>. It is easier to debug and unit test if the class is stateless</li> <li>Support to be refactored</li> </ul> <p>The disadvantage:</p> <ul> <li>Hard to debug for those who does not familiar with interfaces (everytime you redirect to the method, it goes to interface's)</li> <li>Creates layering which will resulting to mapping</li> </ul> <h2>State / Stateless</h2> <p>I think states plays important rules in your application design. Usually developers try to avoid having states in business logic code, such as:</p> <pre><code>// get data if(request.IsDraft){ // step 1 // step 2 } else{ // step 1 // step 3 } </code></pre> <p>Developers tend to put the logic in other <code>stateless</code> class, or at least methods such as:</p> <pre><code>// get data if(request.IsDraft){ draftRequestHandler.Modify(request); } else{ publishedRequestHandler.Modify(request); } </code></pre> <p>It will provide in better readability, and easier for modification and unit tests. There is one design pattern <code>state pattern or hierarchial state machine pattern</code> too, especially to handle some cases like this.</p> <h2>Single Responsibility Principle</h2> <p>IMHO, this principle is has the most benefit if followed. The advantages are:</p> <ol> <li>In versioning, the changes are clear about which class has been modified and why</li> <li>In DI, several smaller classes can be wired up, creating flexibility in both usage and unit test</li> <li>Increase modularity, low coupling and high cohesion</li> </ol> <h2>TDD (Test Driven Development)</h2> <p>This design does not guarantee your code free of bugs. In cons of costing time at design phase and layering effort, it has the benefit of:</p> <ol> <li>Easy to mock object for unit test</li> <li>Easier to refactor because of unit test and modularity</li> <li>Easier to maintain / extend</li> </ol> <h2>Some useful sources</h2> <p><a href="http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern" rel="nofollow">Service Locator Anti Pattern</a></p> <p><a href="https://cuttingedge.it/blogs/steven/pivot/entry.php?id=91" rel="nofollow">Using Decorator for cross-cutting concern</a></p> <p>My 2 cents:</p> <p><a href="https://stackoverflow.com/questions/16930374/bank-system-interface-design-interview/16930778#16930778">The benefit of using interface (also apply for composition ofer inheritance)</a></p> <p><a href="https://stackoverflow.com/questions/16638873/how-to-practice-solid-principle-of-oop-design/16641778#16641778">Doing top down design / DI design</a></p> <h2>Final Thoughts</h2> <p>Those designs and strategies are not the key which will determine your application structure. It still the architect who will determine it. I prefer to follow some principles such as SOLID, KISS and GRASP, rather than deciding what is the best structure. It is said that Dependency Injection follow the most of those principles, but too much abstraction and incorrect components design will resulting the same with the misuse of singleton pattern.</p>
    singulars
    1. This table or related slice is empty.
    1. POcode reuse in Methods.class vs strategy pattern and dependency injection
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSteven
    1. USFendy
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POcode reuse in Methods.class vs strategy pattern and dependency injection
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO+1 Great, I am very very thankful for the lovely answer! Your answer is **perfect** for acceptance, But I am hoping my points be explained further by someone as this is very deep.
      singulars
      1. PO
      1. USMasood Ahmad
    2. COPlease put some more elaboration if you want/can/have time to
      singulars
      1. PO
      1. USMasood Ahmad
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload