Software Design Patterns

[QueenSvetlana]

Why is it so hard to agree on certain design patterns? Why are there various opinions? I'll give you an example.

Not too long ago I was doing a hobby project in Java, and the topic of encapsulation came up. If you were to do a search, you'll find several forums/threads that are divided when it comes to this topic. Some say getters/setters are evil and should be avoided, that the object should perform the calculation/behavior, and give you the result. Now, I believe that getters/setter don't break encapsulation, they enforce it. I favor creating immutable classes, so I don't use setters, but I use getters to display my data.

Why is this topic and several others hard to define an answer for? I don't work professionally as a programmer, so forgive me if my questions sounds a little foolish.

Side Note: I didn't place this question in the programming forum because it's about design patterns, and it will have various answers with different opinions. I don't want to take attention away from someone who has a problem with code.

 

[carnageX]

Why is it so hard to agree on certain design patterns? Why are there various opinions? I'll give you an example.

Not too long ago I was doing a hobby project in Java, and the topic of encapsulation came up. If you were to do a search, you'll find several forums/threads that are divided when it comes to this topic. Some say getters/setters are evil and should be avoided, that the object should perform the calculation/behavior, and give you the result. Now, I believe that getters/setter don't break encapsulation, they enforce it. I favor creating immutable classes, so I don't use setters, but I use getters to display my data.

Why is this topic and several others hard to define an answer for? I don't work professionally as a programmer, so forgive me if my questions sounds a little foolish.

Side Note: I didn't place this question in the programming forum because it's about design patterns, and it will have various answers with different opinions. I don't want to take attention away from someone who has a problem with code.

Mostly because there's a lot of different ways to do it, and even then varying "industry standards" depending on where you look. There's basic core principles that are shared, but then a lot of varying methodologies to get to the same outcome. Mostly depends on business need, and partially skillset or even just personal preference of the developer.

I personally use MVVM/MVC methodologies, and thus use getters/setters - however I don't do much calculation in the models. The only time I do any type of logic in the getters, is for read-only properties that are just display properties or combinations of multiple properties; for example: you have a class with FirstName and LastName properties - I might make a getter called FullName that just combines those other 2 properties in a specific format for my application to use.

Extending on that, I don't like putting business logic in the models. To me it's too messy - nearly all my business logic goes in a Service layer, which is separate from the UI and Data Access layers. Minimal logic in the DAL as well, as I just use that to do the pure data/CRUD operations.

 

[QueenSvetlana]

Given that you use getters/setters, would you consider getters/setters in an interface, code smell? I only ask because I came across this post about encapsulation, and it had me questioning if what I was doing is bad practice.

 

[carnageX]

I don't know much Java, but are Java interfaces like C# interfaces? I guess I'm not sure if that'd be a code smell / bad practice or not... I personally only use interfaces with dependency injection with my applications. Interfaces should just be treated as "contracts" where a class implementing that interface promises to implement the methods outlined in the interface in some way (which is why interfaces are different from abstract / virtual classes).

 

[QueenSvetlana]

I don't know much Java, but are Java interfaces like C# interfaces? I guess I'm not sure if that'd be a code smell / bad practice or not... I personally only use interfaces with dependency injection with my applications. Interfaces should just be treated as "contracts" where a class implementing that interface promises to implement the methods outlined in the interface in some way (which is why interfaces are different from abstract / virtual classes).

Yes, the principals are the same. So logically, if I supplied a getter in my interface, it's a promise that any class implementing that interface would have that getter.

Give that you use it for dependence injection, that would mean you at least supply a setter in an interface, correct?

 

[carnageX]

Yes, the principals are the same. So logically, if I supplied a getter in my interface, it's a promise that any class implementing that interface would have that getter.

Give that you use it for dependence injection, that would mean you at least supply a setter in an interface, correct?

No, my interfaces only consist of method signature declarations. And then when I wish to use an instance of that class, I use a private field to instantiate my interface inside the constructor, and use something like Ninject to actually map my interface to my implementing class.

Edit: might be easier to show an example of what I'm talking about...

//define our interface, with our method signatures as "contracts"
public interface IMyService
{
	public int GetInt();
	public void DoSomething();
}

//implement the IMyService interface 
public class MyService : IMyService
{
	//implement both methods explicitly in some way 
	public int GetInt()
	{
		return 1;
	}
	
	public void DoSomething()
	{
		//do some kind of operation
	}
}

public class ClassA
{
	//create a variable of the interface type to use for dependency injection & accessing the interface methods
	private IMyService _myService;
	
	public ClassA(IMyService myService)
	{
		//assign the injected instance to our class instance 
		
		//the Ninject library i mentioned would take care of giving us an actual class instance 
		//of MyService when we request the IMyService interface automatically 
		_myService = myService;
	}
	
	public void MyMethod()
	{
		//call the methods that our service interface contains 
		var i = _myService.GetInt();
		_myService.DoSomething();
	}
}