Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I had built several programs using C# like simple web browser with logic for addresses bar, status bar, some scripting. Simple program which I cannot explain it correctly in english, so instead of explaining I will tell pseudocode:
Get Values and Variables from CSV file which contains many Variables from old language
3x class for each specified variables to make list
From lists generate excel file
Simple games in unity 3D from tutorials and some other simple programs from tutorials.
And I'm looking for a project in which I will learn interfaces, abstract class, polymorphism, inheritance, encapsulation in a practical way. All the tutorials tells the theory of it, I can understand most of them but I couldn't imagine the usage of them.
http://www.codeproject.com/Articles/572738/Building-an-application-using-design-patterns-and?fid=1829944&df=90&mpp=25&prof=False&sort=Position&view=Normal&spc=Relaxed&fr=26#xx0xx
This article propably is good but there is no practical data, there isn't any items on which we could work. Therefor I cannot understand why we use interfaces etc.
I have found two tutorials:
https://www.youtube.com/watch?v=YxewTI4H2mY
youtube com/watch?v=QORB9qbsC8M
(sorry but without 10 reputation I cannot post more than 2 links)
Do you think that any of that Is a good way to learn OOP? Could you go to the last minutes of that programs and tell if that programs have good OOP code?
I love to hear any sugestions, help etc. By this time I have to say thanks to all of you who passed through this awful english question and try to answer me!
One concept that lends itself to Object orientation is any sort of database of hierarchical objects. My suggestion would be a zoo.
In a zoo, you can have a main abstract class Animal. This would have basic properties that any animal has, such as the name of the animal and its date of birth. Every animal needs to eat, so an abstract function like eat() would be appropriate.
Inheriting Animal, you can have for example abstract classes Reptile, Bird, Mammal, Insect
A reptile might then contain extra information that is only valid for a reptile.
Inheriting Reptile, you can have for example non-abstract classes Crocodile, Snake, Frog, etc.
A Crocodile could then have more properties and functions that only apply to a crocodile, such as DoDeathRoll().
For the actual animals in the zoo, you then create an instance of the lowest tier of classes. So Crocodile Humphrey = new Crocodile("Humphrey");
Regarding interfaces, you could consider interfaces such as Pettable, Flying (both birds and bats can fly, even though they don't share any other inheritance than Animal) to make functions such as ReactToPetting() or Fly() visible.
Creating a system like this will get you very much used to working with inheritance and polymorphism.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
We all know that interfaces and abstract classes are needed for many design principles, and were told to be "the best practice" of programming, both for maintenance and expansion purposes.
But I also heard people saying, "Do NOT overuse interfaces or abstract classes"!
So then, how do I "draw the line"?
I know the difference between interface and abstract class (kind of).
So I'm not interested in "when to use which?", I'm interested in "when is too much"?
For example, the example given by r/PiggyChu620 from this post is clearly "overengineering" the interfaces, as r/AlarmedSlide1 down below puts it.
So to avoid the same mistake r/PiggyChu620 did, is there any "borderline guideline" as to "when should I use interface/abstract class and when should I not"?
Thank you very much for your help!
It's actually pretty easy.
If you can delete an interface from your code (maybe replace it with a specific class when it's used as a parameter) and your code still works, it wasn't needed.
As with every tool, the answer to the question "when should I use it" is "when you need too". If you use it "just because", then you probably make your program simpler (and therefor more maintainable) when you don't use it at all.
Interfaces, Base classes and OOP are important because you are solving problems with it. If you find yourself doing it without solving an actual problem with it, I would consider it "overused".
Interfaces are contracts that are signed between classes, and all classes that use it are bound by the rules of the interface.
This type of design makes it easier to reuse and increases maintenance.
Suppose you create a vehicle interface. All vehicles must implement this interface, including bicycles, motorcycles, cars, etc.
This style of design creates blood and creates a beautiful and principled architecture for your program
So if you have classes that behave similarly, you can use interfaces or abstract classes.
You can refer to this link to compare abstract classes and interfaces
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
My teacher kept saying that interfaces are not there so one could use them as a way to achieve multiple inheritance in c#.
Why is that? What are they for then? Noone could explain this to me easily yet, I'm so confused.
I read a few articles and books that described interfaces and it seems that all of them are suggesting to use interfaces as a workaround to implement multiple inheritance..
In a statically typed language, or when using static typing in a language that has both dynamic and static typing (such as C#), then inheritance consists of two pieces. The interface, and the implementation. The interface is a contract that says that it will fulfill a specific set of methods or properties. The implementation is the code that actually does it. Code implements an interface.
Interfaces are used to guarantee that an object implements specific contracts. This can be a single contract, or multiple ones. This is not multiple inheritance, which inherits both the interface and the implementation.
Yes, some people try to simulate multiple inheritance with multiple interfaces, but that's not its purpose, and that simulation is very poor anyways.
Multiple interfaces says that an object supports multiple contracts. Multiple inheritance says that an object re-uses multiple implementations. Again, inheritance requires both interface and implementation. Interface implementation is just the interface.
Interfaces form a contract (they say what an object can do), but don't provide implementation.
Why bother? Defining the contract is extra work, why not just create a class?
For example, let's say you want to develop a drawing app. You may come up with few objects like Circle, Triangle, Square, etc. then you start adding methods and add something like Draw(). That is something you could add to the interface that all shapes implement. In C#, by convention it would be named something like IDrawable.
But why not a class?
Let's imagine you are extending the app and adding a support for grouping shapes, to create more complex patterns. The groups can also be drawn, so they also have Draw() method. Now, if you only want to draw the "thing", you do not need to know if it is a shape or a group, or something else you haven't invented yet.
But why not a class?
Because there could be more capabilities, like Move(), Serialize(), etc, and C# doesn't allow you to inherit from multiple classes.
Why not?
It is not a technical limitation, but a choice made by C# language designers. Some languages, like C++ allow it, but it brings few technical problems, most famously the diamond problem. It also makes the compiler more complicated and it's been decided it is not worth it. It also
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Sorry for the noob question but I've always had a hard time distinguishing situations when it's good to create a function or a class. For some of the smaller programs I write at work, I write a whole bunch of functions to carry out specific tasks. The programs all work as intended. However, when I have some of my more senior developers take a look to give me their critique, they rewrite a lot of my functions completely over as a class. These are my coworkers so I don't want to look completely incompetent (I just started this job as a junior developer) by asking them why they did that. What do you guys think?
That is too broad question and you really have to understand the concept of the Object Oriented Programming and when you should use it.
Note: Bellow you will find my personal opinions (some of them borrowed from great books' authors and experienced programmers), and for sure the things highlighted bellow, does not reflect the entire power of the Object Oriented thinking and design. These will be gained throughout experience and feedback.
0. A use case of a class
There are many applications, on where to use an internal class to your C# code.
Data Transfer Object (DTO)
One application (of really many) and is used many times in software, is when you are transmitting data from database to your application for processing.
What better than writing an internal class that will store your data, implement useful and re-usable methods that can be used later in your application logic (e.g isAdministrator) and so on.
1. Object-Oriented Design Patterns
I will recommend you reading a book about Object-Oriented Design Patterns.
Books like that, describe some problems scenarios that can be implemented with a class using a pattern. Once you have read about these patterns and possible scenarios on where can be used, you will be able to get the book, find the pattern and solve your problem.
A co-worker of mine, state something really useful. When you are facing a problem, you should ask yourself:
"Does this problem solved again using a design pattern?"
If the answer is yes, then you go back to your reference book to find your design pattern, that will solve your problem, without re-inventing the wheel.
This approach, will teach you how and when you should use a separate class; but will also help you to maintain a communication language between you and your co-workers, that is, if you are talking about your code to a co-worker, you will be able to state the design-pattern and you will be immediately understood (given that, your co-worker know about the specific design-pattern).
2. Don't be afraid creating more than one internal classes
Another note, don't afraid to create multiple internal classes. Implement as much as possible, don't try to implement one internal class and mix responsibilities. Your class should be for a specific purpose, and should not do more than one thing (i.e responsibilities, if you are writing a class that is about transmitting data from your database to your application logic, should not - ideally - doing something else, like adding data to your database).
Consider learn more about Polymorphism, Inheritance, Encapsulation and Abstraction.
These four fundamental principles of Object Oriented Programming can also help you to learn how to structure your code object-oriented.
3. General Notes
As a Junior-Developer and not only as a Junior but as a Developer in general, you should always willing to learn from the more experience guys, by asking for feedback. Is not a shame is the law of learning and improve your code.
Another powerful source of learning, is books, consider buy some for the area you are interested in. (e.g Object Oriented Programming, Design Patterns etc).
As others noted in comments, this is really too broad and slightly opinionated, but big picture, use a class when:
You maintain state over time, and apply functions to this state.
You have a set of functions that share a common goal or deal with a common usage, data type or otherwise "obvious shared idea". That's particularly relevant when these functions can be reused in other places.
But really, to get a deeper understanding, get a book :-)
BTW, in C#, you can't put any functionality outside of a class, so the question should really be "how to divide my monolith class to smaller classes"
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been developing web apps using .net and c# from last 1 year, but there is some confusion going on in my mind regarding OOP principals implementation.
1) What i learned from the object oriented books was that every class should have its specific methods, but when i came across the code of a senior developer, i saw that the developer has created a separate business layer with a business layer class containing all the methods of all the classes.
Is this approach of using separate business class containing all the methods being used in our app is justified by any design pattern or by any other resource, or it is just an awful design?
Please elaborate your answer in detail as this can also helps other newbies out there...
Architecture is an art not a science. There are good architectures and bad architectures, but there is not a single correct architecture.
For example your Senior developer may have created a Facade (design pattern) on top of your more complicated data access layer to simplify data access. For instance you could have a dozen entities for ordering a product, and you would like to create a facade for everything you need to do while ordering a product.
Just look at the architecture and try to analyze yourself if you think it could be better. The more architecture you know the better your judgment will be, but architecture is rarely black and white.
Also, just because someone is senior it doesn't necessarily mean that they know what they are doing or that they don't make mistakes.
Also, Inheritance can be done in EF:
Inheritance in EF
there is no single architecture one can follow, for example when building strictly SOA systems it is VERY common to have model classes that are only data, no methods whatsoever. Whereas all the business logic classes exist in a different namespace. Furthermore when you send your domain classes over the wire you will typically create dedicated classes for that purpose in a different assembly dedicated to the SOA.
The architecture I describe above is directly from the Microsoft Architecture Guidance package for VS.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
After seeing the 13th Floor back in the day I have been obsessed to a degree with writing a simulator like that.
I have written several simulations with a human base class that have a male and female subclass. They have a routine called runYear and they interact. They date, work, die, have kids, get sad, commit suicide, divorce, etc.
It will run for thousands of "years" and depending on seed parameters grow very large or die off.
My question is: I have really maxed out what I can do with this and I am looking to rewrite this from the ground up, but I want to have a foundation going forward. Are there any good books or articles anyone can point me to that would help me better understand how I need to design this or what key foundations I should include?
On a technical point:
should I look at using a Object Oriented database to store this information?
I was planning on writing this in C#(For comfort reasons), would learning LISP be better?
Are there any other opensource simulators anyone has run across like this I can maybe get some ideas from
Any other ideas/suggestions would be be awesome.
Erik
Most complex thing about this kind of simulators is not how to implement it, but how you model your creatures, and their interactions with each other and environment.
Just use those tools that you are most comfortable with. I wouldn't most likely use any kind of database in the beginning, I would use datastructures that my programming language uses and maybe write and read the datastructures to plain files when persistance is needed.
Here are few links about this kind of simulations. Most of them are not human level, instead they work on a bit "lower" level, think of insects, bacteria and DNA.
Wikipedia: Artificial Life
Wikipedia: Life Simulation Game
Wikipedia: Multi-agent Systems
A couple of examples about existing systems:
Breve - 3d life simulator
Darwinbots
Creatures, a commercial artificial life game
Swarm
First, you need to start off with creating a World class. Your World class would encompass everything that a world can do. You will want to incorporate Gravity, Air, Ground, Walls, etc.. You will probably want to start off by giving the sky a limit, as you wouldn't want someone to just leave your world and go do his own thing in memory somewhere.
Once you got your World setup, create yourself an Abstract Human class. This class will have basic human abilities. You can specify stuff like height, weight, age, etc...
From there, you inherit the Human class, and create Woman and Man classes, each with their specialized attributes. Woman class can have BreastSize, CookingSkill, SexualPrownessLevel, Etc... The Man class will be mostly for keeping track of who is bald.
From there, you can go even further and split into ethnic classes, such as Asian, Indian, etc.. Each ethnic class would have its own traits as well.
Once you got all that out of the way, you can start working on the fun stuff. You can create objects to wreck havoc into their lives, such as Diseases, Religion, Money, Crime, Poverty, Starvation, Floods, Tornadoes etc..
I think the first step is to first be able to describe your problem in a descriptive way.
I like to think of it as a System-of-Systems problem. For that, take a look at SysML. That way, you can start at a high level, and then add more and more fidelity as your system evolves.
You should look at discrete event simulation frameworks (there's link to the list at the end). I only know SimPy for Python, but there are others, open source and commercial. Basic framework is also pretty simple, so it should be easy "programming exercise".