Search Results

Search found 3321 results on 133 pages for 'patterns'.

Page 30/133 | < Previous Page | 26 27 28 29 30 31 32 33 34 35 36 37  | Next Page >

• Implenting ActiveRecord with inheritance?

  - by King

  I recently converted an old application that was using XML files as the data store to use SQL instead. To avoid a lot of changes I basically created ActiveRecord style classes that inherited from the original business objects. For example SomeClassRecord :SomeClass //ID Property //Save method I then used this new class in place of the other one, because of polymorphism I didn't need to change any methods that took SomeClass as a parameter. Would this be considered 'Bad'? What would be a better alternative?

  Read the article

• What Design Pattern is seperating transform converters

  - by RevMoon

  For converting a Java object model into XML I am using the following design: For different types of objects (e.g. primitive types, collections, null, etc.) I define each its own converter, which acts appropriate with respect to the given type. This way it can easily extended without adding code to a huge if-else-then construct. The converters are chosen by a method which tests whether the object is convertable at all and by using a priority ordering. The priority ordering is important so let's say a List is not converted by the POJO converter, even though it is convertable as such it would be more appropriate to use the collection converter. What design pattern is that? I can only think of a similarity to the command pattern.

  Read the article

• Client-server application design issue

  - by user2547823

  I have a collection of clients on server's side. And there are some objects that need to work with that collection - adding and removing clients, sending message to them, updating connection settings and so on. They should perform these actions simultaneously, so mutex or another synchronization primitive is required. I want to share one instance of collection between these objects, but all of them require access to private fields of collection. I hope that code sample makes it more clear[C++]: class Collection { std::vector< Client* > clients; Mutex mLock; ... } class ClientNotifier { void sendMessage() { mLock.lock(); // loop over clients and send message to each of them } } class ConnectionSettingsUpdater { void changeSettings( const std::string& name ) { mLock.lock(); // if client with this name is inside collection, change its settings } } As you can see, all these classes require direct access to Collection's private fields. Can you give me an advice about how to implement such behaviour correctly, i.e. keeping Collection's interface simple without it knowing about its users?

  Read the article

• Best practice to collect information from child objects

  - by Markus

  I'm regularly seeing the following pattern: public abstract class BaseItem { BaseItem[] children; // ... public void DoSomethingWithStuff() { StuffCollection collection = new StuffCollection(); foreach(child c : children) c.AddRequiredStuff(collection); // do something with the collection ... } public abstract void AddRequiredStuff(StuffCollection collection); } public class ConcreteItem : BaseItem { // ... public override void AddRequiredStuff(StuffCollection collection) { Stuff stuff; // ... collection.Add(stuff); } } Where I would use something like this, for better information hiding: public abstract class BaseItem { BaseItem[] children; // ... public void DoSomethingWithStuff() { StuffCollection collection = new StuffCollection(); foreach(child c : children) collection.AddRange(c.RequiredStuff()); // do something with the collection ... } public abstract StuffCollection RequiredStuff(); } public class ConcreteItem : BaseItem { // ... public override StuffCollection RequiredStuff() { StuffCollection stuffCollection; Stuff stuff; // ... stuffCollection.Add(stuff); return stuffCollection; } } What are pros and cons of each solution? For me, giving the implementation access to parent's information is some how disconcerting. On the other hand, initializing a new list, just to collect the items is a useless overhead ... What is the better design? How would it change, if DoSomethingWithStuff wouldn't be part of BaseItem but a third class? PS: there might be missing semicolons, or typos; sorry for that! The above code is not meant to be executed, but just for illustration.

  Read the article

• Correct way to inject dependencies in Business logic service?

  - by Sri Harsha Velicheti

  Currently the structure of my application is as below Web App -- WCF Service (just a facade) -- Business Logic Services -- Repository - Entity Framework Datacontext Now each of my Business logic service is dependent on more than 5 repositories ( I have interfaces defined for all the repos) and I am doing a Constructor injection right now(poor mans DI instead of using a proper IOC as it was determined that it would be a overkill for our project). Repositories have references to EF datacontexts. Now some of the methods in the Business logic service require only one of the 5 repositories, so If I need to call that method I would end up instantiating a Service which will instatiate all 5 repositories which is a waste. An example: public class SomeService : ISomeService { public(IFirstRepository repo1, ISecondRepository repo2, IThirdRepository repo3) {} // My DoSomething method depends only on repo1 and doesn't use repo2 and repo3 public DoSomething() { //uses repo1 to do some stuff, doesn't use repo2 and repo3 } public DoSomething2() { //uses repo2 and repo3 to do something, doesn't require repo1 } public DoSomething3() { //uses repo3 to do something, doesn't require repo1 and repo2 } } Now if my I have to use DoSomething method on SomeService I end up creating both IFirstRepository,ISecondRepository and IThirdRepository but using only IFirstRepository, now this is bugging me, I can seem to accept that I am un-necessarily creating repositories and not using them. Is this a correct design? Are there any better alternatives? Should I be looking at Lazy instantiation Lazy<T> ?

  Read the article

• Can observer pattern be represented by cars and traffic lights?

  - by eeerahul

  I wanted to verify with all of you, if I have a correct Observer Pattern analogy. The scenario is as follows: Consider, at a junction, there is a traffic signal, having red, yellow and green lights respectively. There are vehicles facing the traffic signal post. When it shows red, the vehicles stop, when it shows green, the vehicles move on. In case, it is yellow, the driver must decide whether to go or to stop, depending on whether he/she has crossed the stop line or not. At the same time, there are vehicles that do not care about the signal. They would do as they like. The similarities are that, the Traffic Signal happens to be the subject, notifying its states by glowing the appropriate lights. Those looking at it and following the signal are the ones subscribed to it, and behave according to the state of the subject. Those who do not care about it, are sort-of un-subscribed from the traffic signal. Please tell me, if you think this is a correct analogy or not?

  Read the article

• Where we should put validation for domain model

  - by adisembiring

  I still looking best practice for domain model validation. Is that good to put the validation in constructor of domain model ? my domain model validation example as follows: public class Order { private readonly List<OrderLine> _lineItems; public virtual Customer Customer { get; private set; } public virtual DateTime OrderDate { get; private set; } public virtual decimal OrderTotal { get; private set; } public Order (Customer customer) { if (customer == null) throw new ArgumentException("Customer name must be defined"); Customer = customer; OrderDate = DateTime.Now; _lineItems = new List<LineItem>(); } public void AddOderLine //.... public IEnumerable<OrderLine> AddOderLine { get {return _lineItems;} } } public class OrderLine { public virtual Order Order { get; set; } public virtual Product Product { get; set; } public virtual int Quantity { get; set; } public virtual decimal UnitPrice { get; set; } public OrderLine(Order order, int quantity, Product product) { if (order == null) throw new ArgumentException("Order name must be defined"); if (quantity <= 0) throw new ArgumentException("Quantity must be greater than zero"); if (product == null) throw new ArgumentException("Product name must be defined"); Order = order; Quantity = quantity; Product = product; } } Thanks for all of your suggestion.

  Read the article

• Lazy Processing of Streams

  - by Giorgio

  I have the following problem scenario: I have a text file and I have to read it and split it into lines. Some lines might need to be dropped (according to criteria that are not fixed). The lines that are not dropped must be parsed into some predefined records. Records that are not valid must be dropped. Duplicate records may exist and, in such a case, they are consecutive. If duplicate / multiple records exist, only one item should be kept. The remaining records should be grouped according to the value contained in one field; all records belonging to the same group appear one after another (e.g. AAAABBBBCCDEEEFF and so on). The records of each group should be numbered (1, 2, 3, 4, ...). For each group the numbering starts from 1. The records must then be saved somewhere / consumed in the same order as they were produced. I have to implement this in Java or C++. My first idea was to define functions / methods like: One method to get all the lines from the file. One method to filter out the unwanted lines. One method to parse the filtered lines into valid records. One method to remove duplicate records. One method to group records and number them. The problem is that the data I am going to read can be too big and might not fit into main memory: so I cannot just construct all these lists and apply my functions one after the other. On the other hand, I think I do not need to fit all the data in main memory at once because once a record has been consumed all its underlying data (basically the lines of text between the previous record and the current record, and the record itself) can be disposed of. With the little knowledge I have of Haskell I have immediately thought about some kind of lazy evaluation, in which instead of applying functions to lists that have been completely computed, I have different streams of data that are built on top of each other and, at each moment, only the needed portion of each stream is materialized in main memory. But I have to implement this in Java or C++. So my question is which design pattern or other technique can allow me to implement this lazy processing of streams in one of these languages.

  Read the article

• Is "convention over configuration" not violating basic programming principles?

  - by Geerten

  I was looking at the WPF MVVM framework Caliburn.Micro and read that a lot of standard things are based on naming conventions. For example, automatic binding of properties in the View to properties in the ViewModel. Although this seems to be convenient (removes some boilerplate code), my first instinct reaction is that it isn't completely obvious to a new programmer that will read this code. In other words, the functionality of the application is not completely explained by its own code, but also by the documentation of the framework. EDIT: So this approach is called convention over configuration. Since I could not find any questions concerning this, I altered my question: My question is: Is convention over configuration a correct way of simplifying things, or is it violating some programming principles (and if so, which ones)?

  Read the article

• Why avoid Java Inheritance "Extends"

  - by newbie

  Good day! Jame Gosling said “You should avoid implementation inheritance whenever possible.” and instead, use interface inheritance. But why? How can we avoid inheriting the structure of an object using the keyword "extends", and at the same time make our code Object Oriented? Could someone please give an Object Oriented example illustrating this concept in a scenario like "ordering a book in a bookstore?" Thank you in advance.

  Read the article

• Using packages (gems, eggs, etc.) to create decoupled architectures

  - by Juan Carlos Coto

  The main issue Seeing the good support most modern programming platforms have for package management (think gem, npm, pip, etc), does it make sense to design an application or system be composed of internally developed packages, so as to promote and create a loosely coupled architecture? Example An example of this would be to create packages for database access, as well as for authentication and other components of the system. These, of course, use external packages as well. Then, your system imports and uses these packages - instead of including their code within its own code base. Considerations To me, it seems that this would promote code decoupling and help maintainability, almost in a Web-based-vs.-desktop-application kind of way (updates are applied almost automatically, single code base for single functionality, etc.). Does this seem like a rational and sane design concept? Is this actually used as a standard way of structuring applications today? Thanks very much!

  Read the article

• Flags with deferred use

  - by Trenton Maki

  Let's say I have a system. In this system I have a number of operations I can do but all of these operations have to happen as a batch at a certain time, while calls to activate and deactivate these operations can come in at any time. To implement this, I could use flags like doOperation1 and doOperation2 but this seems like it would become difficult to maintain. Is there a design pattern, or something similar, that addresses this situation?

  Read the article

• Motivation for service layer (instead of just copying dlls)?

  - by BornToCode

  I'm creating an application which has 2 different UIs so I'm making it with a service layer which I understood is appropriate for such case. However I found myself just creating web methods for every single method I have in the BL layer, so the services basically built from methods that looks like this: return customers_bl.Get_Customer_Prices(customer_id); I understood that a main point of the service layer is to prevent duplication of code so I asked myself - well, why not just import the BL.dll (and the DAL.dll) to the other UI, and whenever making a change re-copy the dll files, it might not be so 'neat', but is the all purpose of the service layer to prevent this? {I know something is wrong in my approach, I'm probably missing the importance of service layer, I'd like to get more motivation to create another layer, especially because as it is I found that many of my BL functions ALREADY looks like: return customers_dal.Get_Customer_Prices(cust_id) which led me to ask: was it really necessary to create the BL just because on several functions I actually have LOGIC inside the BL?} so I'm looking for more motivation to creating ONE MORE layer, I'm sure it's not just to make it more convenient that I won't have to re-copy the dlls on changes? Am I grasping it wrong? Any simple guidelines on how to design service layer (corresponding to all the BL layer functions or not? any simple example?) any enlightenment on the subject?

  Read the article

• How to choose between using a Domain Event, or letting the application layer orchestrate everything

  - by Mr Happy

  I'm setting my first steps into domain driven design, bought the blue book and all, and I find myself seeing three ways to implement a certain solution. For the record: I'm not using CQRS or Event Sourcing. Let's say a user request comes into the application service layer. The business logic for that request is (for whatever reason) separated into a method on an entity, and a method on a domain service. How should I go about calling those methods? The options I have gathered so far are: Let the application service call both methods Use method injection/double dispatch to inject the domain service into the entity, letting the entity do it's thing and then let it call the method of the domain service (or the other way around, letting the domain service call the method on the entity) Raise a domain event in the entity method, a handler of which calls the domain service. (The kind of domain events I'm talking about are: http://www.udidahan.com/2009/06/14/domain-events-salvation/) I think these are all viable, but I'm unable to choose between them. I've been thinking about this a long time and I've come to a point where I no longer see the semantic differences between the three. Do you know of some guidelines when to use what?

  Read the article

• What is the best book for the preparation of MCPD Exam 70-564 (Designing and Developing ASP.NET 3.5 Applications)?

  - by Steve Johnson

  Hi all, I have seen a couple of questions like this one and scanned through the answers but somehow the replies were not satisfactory or practical. So i wondered maybe people who have gone through it and may suggest a better approach for the preparation of this exam. Goal: My goal is actually NOT merely to pass that exam. I intend to actually master the skill. I have been into asp.net web development for approximately 1.5 years and I want to study something that really improves "Design and Development Skills" in Web Development in general and asp.net to be specific which i can put to use and build upon that. Please suggest a book that teaches professional Asp.Net design and development skills and approaches to quality development by taking through practice design scenarios and their solutions and through various case studies that involve design problems and their implemented solutions. Edit: I have found the Micorosoft training kits to be fairly interesting and helpful as these tend to increase knowledge. I have utilized a lot of things after getting a good explanation of things from the training kits. However, as far as Microsoft Training Kit for 70-564 is concerned, there are not a lot of good reviews about it. What i have read and searched on the net , the reviews on amazon and various forums, stack-exchange and experts-exchange, were more inclined to the conclusion that "Microsoft Training Kit for Exam 70-564 is not good. Its is not good as compared to other kits from Microsoft, like as compared to the training kit of Exam 70-562 or others." So i was looking for a proper book containing examples from practical world scenarios and case studies from which i can not only learn but also master the skills before wasting money of Microsoft Training Kit for Exam 70-564. Waiting for experts to provide a suitable advice.

  Read the article

• I know of three ways in which SRP helps reduce coupling. Are there even more? [closed]

  - by user1483278

  I'd like to figure all the possible ways SRP helps us reduce coupling. Thus far I can think of three: 1) If class A has more than one responsibility, these responsibilities become coupled and as such changes to one of these responsibilities may require changes to other of A's responsibilities. 2) Related functionality usually needs to be changed for the same reason and by grouping it togerther in a single class, the changes can be made in as few places as possible ( at best changes only need be made to the class which groups together these functionalities) 3) Assuming class A performs two tasks ( thus may change for two reasons ), then number of classes utilising A will be greater than if A performed just a single task ( reason being that some classes will need A to perform first task, other will need A for second task, and still others will utilise it for both tasks ).This also means that when A breaks, the number of classes ( utilising A ) being impaired will be greater than if A performed just a single task. Can SRP also help reduce coupling in any other way, not described above? Thank you

  Read the article

• Structuring Access Control In Hierarchical Object Graph

  - by SB2055

  I have a Folder entity that can be Moderated by users. Folders can contain other folders. So I may have a structure like this: Folder 1 Folder 2 Folder 3 Folder 4 I have to decide how to implement Moderation for this entity. I've come up with two options: Option 1 When the user is given moderation privileges to Folder 1, define a moderator relationship between Folder 1 and User 1. No other relationships are added to the db. To determine if the user can moderate Folder 3, I check and see if User 1 is the moderator of any parent folders. This seems to alleviate some of the complexity of handling updates / moved entities / additions under Folder 1 after the relationship has been defined, and reverting the relationship means I only have to deal with one entity. Option 2 When the user is given moderation privileges to Folder 1, define a new relationship between User 1 and Folder 1, and all child entities down to the grandest of grandchildren when the relationship is created, and if it's ever removed, iterate back down the graph to remove the relationship. If I add something under Folder 2 after this relationship has been made, I just copy all Moderators into the new Entity. But when I need to show only the top-level Folders that a user is Moderating, I need to query all folders that have a parent folder that the user does not moderate, as opposed to option 1, where I just query any items that the user is moderating. Thoughts I think it comes down to determining if users will be querying for all parent items more than they'll be querying child items... if so, then option 1 seems better. But I'm not sure. Is either approach better than the other? Why? Or is there another approach that's better than both? I'm using Entity Framework in case it matters.

  Read the article

• Entity and pattern validation vs DB constraint

  - by Joerg

  When it comes to performance: What is the better way to validate the user input? If you think about a phone number and you only want numbers in the database, but it could begin with a 0, so you will use varchar: Is it better to check it via the entity model like this: @Size(min = 10, max = 12) @Digits(fraction = 0, integer = 12) @Column(name = "phone_number") private String phoneNumber; Or is it better to use on the database side a CHECK (and no checking in the entity model) for the same feature?

  Read the article

• How can you tell whether to use Composite Pattern or a Tree Structure, or a third implementation?

  - by Aske B.

  I have two client types, an "Observer"-type and a "Subject"-type. They're both associated with a hierarchy of groups. The Observer will receive (calendar) data from the groups it is associated with throughout the different hierarchies. This data is calculated by combining data from 'parent' groups of the group trying to collect data (each group can have only one parent). The Subject will be able to create the data (that the Observers will receive) in the groups they're associated with. When data is created in a group, all 'children' of the group will have the data as well, and they will be able to make their own version of a specific area of the data, but still linked to the original data created (in my specific implementation, the original data will contain time-period(s) and headline, while the subgroups specify the rest of the data for the receivers directly linked to their respective groups). However, when the Subject creates data, it has to check if all affected Observers have any data that conflicts with this, which means a huge recursive function, as far as I can understand. So I think this can be summed up to the fact that I need to be able to have a hierarchy that you can go up and down in, and some places be able to treat them as a whole (recursion, basically). Also, I'm not just aiming at a solution that works. I'm hoping to find a solution that is relatively easy to understand (architecture-wise at least) and also flexible enough to be able to easily receive additional functionality in the future. Is there a design pattern, or a good practice to go by, to solve this problem or similar hierarchy problems? EDIT: Here's the design I have: The "Phoenix"-class is named that way because I didn't think of an appropriate name yet. But besides this I need to be able to hide specific activities for specific observers, even though they are attached to them through the groups. A little Off-topic: Personally, I feel that I should be able to chop this problem down to smaller problems, but it escapes me how. I think it's because it involves multiple recursive functionalities that aren't associated with each other and different client types that needs to get information in different ways. I can't really wrap my head around it. If anyone can guide me in a direction of how to become better at encapsulating hierarchy problems, I'd be very glad to receive that as well.

  Read the article

• How should I implement the repository pattern for complex object models?

  - by Eric Falsken

  Our data model has almost 200 classes that can be separated out into about a dozen functional areas. It would have been nice to use domains, but the separation isn't that clean and we can't change it. We're redesigning our DAL to use Entity Framework and most of the recommendations that I've seen suggest using a Repository pattern. However, none of the samples really deal with complex object models. Some implementations that I've found suggest the use of a repository-per-entity. This seems ridiculous and un-maintainable for large, complex models. Is it really necessary to create a UnitOfWork for each operation, and a Repository for each entity? I could end up with thousands of classes. I know this is unreasonable, but I've found very little guidance implementing Repository, Unit Of Work, and Entity Framework over complex models and realistic business applications.

  Read the article

• Motivation for a service layer (instead of just copying dlls)?

  - by BornToCode

  I'm creating an application which has 2 different UIs so I'm making it with a service layer which I understood is appropriate for such scenario. However I found myself just creating web methods for every single method I have in the BL layer, so the services basically built from methods that looks like this: return customers_bl.Get_Customer_Prices(customer_id); I understood that a main point of the service layer is to prevent duplication of code so I asked myself - why not just import the BL.DLL (and the dal.dll) to the other UI, and whenever making a change re-copy the dlls, it might not be so 'neat', but still less hassle than one more layer? {I know something is wrong in my approach, I'm probably missing the importance of service layer, I'd like to get more motivation to create another layer, especially because as it is I found that many of my BL functions ALREADY looks like: return customers_dal.Get_Customer_Prices(cust_id) which led me to ask: was it really necessary to create the BL just because on several functions I actually have LOGIC inside the BL?} so I'm looking for more motivation to creating ONE MORE layer, I'm sure it's not just to make it more convenient that I won't have to re-copy the dlls on changes? Am I grasping it wrong? Any simple guidelines on how to design service layer (corresponding to all the BL layer functions or not? any simple example?) any enlightenment on the subject?

  Read the article

• Many ui panels needs interaction with same object

  - by user877329

  I am developing a tool for simulating systems like the Gray-Scott model (That is systems where spatial distribution depends on time). The actual model is loaded from a DLL or shared object and the simulation is performed by a Simulation object. There are at least two situations when the simulation needs to be destroyed: The user loads a new model The user changes the size of the domain To make sure nothing goes wrong, the current Model, Simulation, and rendering Thread are all managed by an ApplicationState object. But the two cases above are initiated from two different UI objects. Is it then ok to distribute a reference to the ApplicationState object to all panels that need to access at least one method on the ApplicationState object? Another solution would be to use aggregation so that the panel from which the user chooses model knows the simulation parameter panel. Also, the ApplicationState class seems somewhat clumsy, so I would like to have something else

  Read the article

• Help with MVC design pattern?

  - by user3681240

  I am trying to build a java program for user login but I am not sure if my MVC design is accurate. I have the following classes: LoginControl - servlet LoginBean - data holder java class with private variables getters and setters LoginDAO - concrete java class where I am running my SQL queries and doing rest of the logical work. Connection class - java class just to connect to the database view - jsp to display the results html - used for form Is this how you design a java program based on MVC design pattern? Please provide some suggestions?

  Read the article

• Is it dangerous for me to give some of my Model classes Control-like methods?

  - by Pureferret

  In my personal project I have tried to stick to MVC, but I've also been made aware that sticking to MVC too tightly can be a bad thing as it makes writing awkward and forces the flow of the program in odd ways (i.e. some simple functions can be performed by something that normally wouldn't, and avoid MVC related overheads). So I'm beginning to feel justified in this compromise: I have some 'manager programs' that 'own' data and have some way to manipulate it, as such I think they'd count as both part of the model, and part of the control, and to me this feels more natural than keepingthem separate. For instance: One of my Managers is the PlayerCharacterManager that has these methods: void buySkill(PlayerCharacter playerCharacter, Skill skill); void changeName(); void changeRole(); void restatCharacter(); void addCharacterToGame(); void createNewCharacter(); PlayerCharacter getPlayerCharacter(); List<PlayerCharacter> getPlayersCharacter(Player player); List<PlayerCharacter> getAllCharacters(); I hope the mothod names are transparent enough that they don't all need explaining. I've called it a manager because it will help manage all of the PlayerCharacter 'model' objects the code creates, and create and keep a map of these. I may also get it to store other information in the future. I plan to have another two similar classes for this sort of control, but I will orchestrate when and how this happens, and what to do with the returned data via a pure controller class. This splitting up control between informed managers and the controller, as opposed to operating just through a controller seems like it will simplify my code and make it flow more. My question is, is this a dangerous choice, in terms of making the code harder to follow/test/fix? Is this somethign established as good or bad or neutral? I oculdn't find anything similar except the idea of Actors but that's not quite why I'm trying to do. Edit: Perhaps an example is needed; I'm using the Controller to update the view and access the data, so when I click the 'Add new character to a player button' it'll call methods in the controller that then go and tell the PlayerCharacterManager class to create a new character instance, it'll call the PlayerManager class to add that new character to the player-character map, and then it'll add this information to the database, and tell the view to update any GUIs effected. That is the sort of 'control sequence' I'm hoping to create with these manager classes.

  Read the article

• Interfaces on an abstract class

  - by insta

  My coworker and I have different opinions on the relationship between base classes and interfaces. I'm of the belief that a class should not implement an interface unless that class can be used when an implementation of the interface is required. In other words, I like to see code like this: interface IFooWorker { void Work(); } abstract class BaseWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker, IFooWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } The DbWorker is what gets the IFooWorker interface, because it is an instantiatable implementation of the interface. It completely fulfills the contract. My coworker prefers the nearly identical: interface IFooWorker { void Work(); } abstract class BaseWorker : IFooWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } Where the base class gets the interface, and by virtue of this all inheritors of the base class are of that interface as well. This bugs me but I can't come up with concrete reasons why, outside of "the base class cannot stand on its own as an implementation of the interface". What are the pros & cons of his method vs. mine, and why should one be used over another?

  Read the article

< Previous Page | 26 27 28 29 30 31 32 33 34 35 36 37  | Next Page >