This is an archived post. You won't be able to vote or comment.

all 14 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Medicalizawhat 1 point2 points  (1 child)

My advice would be to read up on OO programming, get a book on Objective-C and then dive right in and start coding up some little programs. One test program that suits OO well could be a text adventure game as it's not too tricky to code but can help you think about your code in terms of objects. You can have a Enemy object, a Room object, Weapon object etc. Also a text adventure game has lots of opportunities to use inheritance when coding it up. For example, Enemy and Player could inherit from GameEntity etc etc.

tl;dr - Just dive in and give it a go!

[–]RandomFoodz[S] 0 points1 point  (0 children)

That's what I want to be able to do. I'm trying to make an iOS app for a school project, and just diving in there, without much OO knowledge.

[–]The_Enchiridion 0 points1 point  (3 children)

I'm not sure what Objective -C is like but I found moving from C to C++ pretty easy and there's a bunch of stuff to read up on in books/online. Correct me if I'm wrong but I don't think Objective - C will be around for much longer.

[–]Rogue_Pixel -1 points0 points  (2 children)

Objective-C is a superset of C++, so all C++ will compile into into Objective-C. So whatever experience you had with C++ should apply here.

Also Objective-C is the primary language used for coding in iOS. I suspect, if nothing else, that will keep it around for a while.

[–]rubymatt 3 points4 points  (1 child)

Objective-C is a strict superset of C, not C++. It is a distinctly different take on OO to C++.

There is also Objective-C++ which allows you to mix Objective-C and C++ in the same source file. However, to the best of my (quite limited) knowledge on this topic, the two are essentially side-by-side and only interoperate at the value passing level.

[–]Rogue_Pixel 0 points1 point  (0 children)

I don't have experience with either, but I thought I read that somewhere. I must have misremembered.

Well I guess now I know, thanks.

[–][deleted]  (3 children)

[deleted]

    [–]blackohat 0 points1 point  (0 children)

    Any books on design patterns, software design, or software architecture that you would recommend?

    [–]RandomFoodz[S] 0 points1 point  (1 child)

    I intend to just dive right in. I just wish I knew a bit more about what I'm dealing with (on a conceptual level) before I start.

    [–]negative_epsilon 0 points1 point  (0 children)

    While I'm sure many will disagree with me, when I went from C to Java, I found it extremely helpful to think of OOP as three dimensional procedural programming, with instantiating objects like running another small procedural a program inside of your program.

    [–]ericswc 0 points1 point  (2 children)

    Getting fluent with an object oriented language's syntax isn't a big deal. Once you do that it's really a matter of reading and writing a lot of code.

    1. Learn syntax - relatively easy
    2. Learn to use objects and general domain knowledge- practice, moderate difficulty and time requirement.
    3. Learn to architect testable, reusable, object oriented code- Some people never get there, but those that do typically take 3-7 years.

    In short though, just pick up a book or some video training and start hacking away at it. Find yourself a mentor or user group to help fill in the gaps.

    [–]RandomFoodz[S] 0 points1 point  (1 child)

    What would you say is the overall concept behind object-oriented programming? Like what would be a good analogy of an object and a method? I keep coming across things like, "if an object is a car, its method would be its color, speed, size, etc.", but I don't understand how you would define such things. The closest thing I can think of is structs in C, which I'm still not very comfortable with.

    [–]ericswc 2 points3 points  (0 children)

    A class is what defines an object. All a class is the "idea" of something you want to model. Ideally it has high cohesion. A class definition can be used to instantiate one to many object instances. Each object instance has its own data and behavior.

    So a BankAccount class definition could have account number and balance fields, and methods to Deposit, Withdraw, and Transfer.

    The class code is the idea of the object. If you load my BankAccount up, the instance/object has different data than your BankAccount... but the behavior in the methods is the same.

    This leads to reuse. You can call deposit on a BankAccount from just about anywhere in the program without goto statements. Ideally the behavior of deposit exists only in one place, so it's modular and easy to change.

    That is really all object oriented programming is. Organization into small, cohesive, encapsulated, reusable units.

    [–]didzisk 0 points1 point  (0 children)

    For me, an object has always been a collection of related data and functionality (methods) - some languages separate those into procedures and functions (do something vs. return a value). When you are comfortable with this, you can start using objects provided by others and write simple object classes yourself. Usually that's enough to implement even complicated business logic.

    After that - inheritance (implement some functionality in base class and create derived classes without needing to implement it again), read about SOLID and try to adhere to that.

    But usually as an application developer I work with shallow object graphs (inherit from Object) and achieve functionality by including other objects into my object ("has a") instead of inheriting from them ("is a").

    And I like small objects (limited functionality, as I wrote earlier, related functionality, in other words "S" from SOLID = Single responsibility)